|
..that is the obscenely verbose, and imponderably obtuse world of M$ programming. Much of what I scanned in that doc is common sense design, why do net/wpf programmers need to fix a fancy frame around a heap of complex jargon for every axiomatic bit of fluff, I will never understand, (engineering envy perhaps?)
|
|
|
|
|
Steppenwolfe wrote: obscenely verbose, and imponderably obtuse world of M$ programming
You should try see Java.
|
|
|
|
|
yeah java sucks, ergo no one wants to use it.. but I think the wpf framework stuff is way over the top. It's like reading Nietzsche, you get the point on the first page, but then it sails off into an orgy of complexity, as if to prove the merit of the arguement by the weight of its involution.. puts me to sleep every time.
|
|
|
|
|
It's easy. It's only to have a common language. Just like design patterns are about having a common language to describe generic solutions to recurring problems. Yes, it's usually basic design principle that everyone should know. However, it's important to be able to communicate them with the people you work with. It even help you understand what you know.
I agree however that SOLID might be a bit hardcore on Jargon. Check GRASP for example.. it's slightly less hardcore IMO. BTW.. it has nothing to do about Microsoft (using M$ is so 1995 don't you think?) or WPF. As you said, it's about design and you can do design or architecture in any language.
Cheer up.
|
|
|
|
|
Steppenwolfe wrote: why do net/wpf programmers need to fix a fancy frame around a heap of complex jargon for every axiomatic bit of fluff
telling people how to write code is easier than writing code yourself!
|
|
|
|
|
Single responsibility principle: yup, the tire had the single responsibility of rotating evenly, and it failed
open/closed principle: yup, the tire is definitely open, and closed to patching
Liskov substitution principle: yup, I can certainly replace the primary function of the tire with my own two feet, at least for short distances
Interface segregation principle: yeah, the flat tire is my scooter, fortunately I have legs, a car, friends, etc.
Dependency inversion principle: sticking my thumb out while walking home is a good example dependency inversion.
Hell, what I am I talking about again???
Marc
|
|
|
|
|
I agree.
Why is it that everyone wants to replace the "common sense approach" with some new "acronym of the day approach"? People with too much time on their hands I guess. Must be the "those who can do, those who can't teach" crowd. 
|
|
|
|
|
Currently, my only goal is to keep cohesion AS HIGH AS POSSIBLE.
If I have to edit a piece of code, I'll try to make as few change as possible, document them well and make sure nothing was too drastically change. If I have to add a class, I'll copy over another one that already work. Keeping cohesion is paramount in my case. If I ever need to create something new, then, it's another thing entirely.
I personnally, prefer reffering to GRASP, not SOLID.
General Responsibility Assignment Software Patterns (see wikipedia)
|
|
|
|
|
Do you intend "you" to mean me as an individual, or to mean the company/organization/team I work for/with?
If me individually, I fall into the category of "never heard of it but usually do it anyway."
If you mean my company, of course not.
Grim
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
(0 row(s) affected)
|
|
|
|
|
Programming isn't about doing it "that" way to be perfect.
So I actually use some or all the SOLID parts wherever I need them.
One thing I never actually use on a "real" project was Dependency Injection... never felt the need for it.
Anyway, SOLID is just an acronym, nothing more...
|
|
|
|
|
AlexCode wrote: One thing I never actually use on a "real" project was Dependency Injection... never felt the need for it.
That's because you're not using a Unit Test framework.
Try writing a few Unit Tests with NUnit and the joys of DI will magically reveal themselves.
-Rd
Hit any user to continue.
|
|
|
|
|
Usually the survey mentions the name of the member who suggested the poll. This time I observe that the site admins have decided to protect him/her by keeping it anonymous lest he/she dies of shame at their having suggested this being public information 
|
|
|
|
|
|
It was me. I confess.
But I'll also confess to being stunned by the results. Absolutely stunned.
I hate a buzzword as much as the next but the principles involved are ... (mustn't use the word...) a great foundation for a lot of code. And completely unnecessary for other types.
What truly amazes me is the antagonism and lack of understanding (and this coming from a web developer of all things. The shame!)
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: What truly amazes me is the antagonism and lack of understanding
Pretty sure most of it was in humor, Chris
That said, the expansion does sound reaaalllly buzzword-ish.
|
|
|
|
|
|
5! 
|
|
|
|
|
I get the impression that I could spend all my days working to various principles with various patterns and never really get much done.
|
|
|
|
|
Totally agree
Principles are important, but getting things done on time is more important 
VladovsoftSoftware products for management and control of warehouses, shops, hotels, gyms and health clubs.
|
|
|
|
|
I had a dodgy curry last night but I'm still on SOLIDs.
|
|
|
|
|
|
Last year I was lucky enough to have a software review by an external you really knew a lot about OO principles. I would add DRY (Don't Repeat Yourself) as one of the key principles to apply when coding.
Here's a short summary I made of these principles, I hope it helps...
Great suggestion for a survey, not enough programmers know and understand these principles....
SRP The Single Responsibility Principle: A class should have one, and only one, reason to change.
OCP The Open Closed Principle: You should be able to extend a classes behavior, without modifying it.
LSP The Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
ISP The Interface Segregation Principle: Make fine grained interfaces that are client specific.
DIP The Dependency Inversion Principle: Depend on abstractions, not on concretions.
The Liskov Substitution Principle (LSP)
Any function that uses a base class must not be confused when a derived class is substituted for the base class
The Dependency Inversion Principle
1. High level modules should not depend upon low level modules. Both should depend upon abstractions
2. Abstractions should not depend upon details. Details should depend upon abstractions
|
|
|
|
|
I'd also add KISS (Keep It Simple Stupid), especially to "DRY" - don't make the code and archtecture more complicated than it needs to be.
Also
YAGNI (You Ain't Gonna Need It) is one all (and especially good)developers are all tempted to break: don't add a feature until you know you need it, kind of a subset of KISS.
|
|
|
|
|
Bingo, sounds like you make the playing cards for buzzword bingo.
|
|
|
|
|
Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion
Holy moly!  That sounds too complicated already.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
