|
I use the underlying principles, but not that acronym.
I like to make up my own acronyms, so I remember what they mean, and make other people think I'm smart, since they don't know what my acronyms mean. 
- S
50 cups of coffee and you know it's on!
Code, follow, or get out of the way.
|
|
|
|
|
if it is solid, I eat, but if liquid I drink.
easy.
|
|
|
|
|
Stones? acid? 
luisnike19
|
|
|
|
|
|
haha
Learn from yesterday, live for today, hope for tomorrow
|
|
|
|
|
EACS stands for Experience And Common Sense. Hey have I coined another acronym, perhaps I should write a book, describe myself as a guru and make a fortune telling everyone what they already know. On second thoughts I like being an Engineer and would not want to be a consultant beter known as either sharks or parasites.
|
|
|
|
|
There's nothing worst than getting helped by someone and when you ask for explanation on something he tell you, he just claim it's EACS. He simply can't explain what it is. It's frustrating and don't help anyone.
But I agree, most of this stuff is common sense design. It can be interesting to dig a little big however, sometime, we can be surprised and learn something... you know... new, from outside our experience. Just saying.
|
|
|
|
|
While EACS may work well for some, I have found that common sense is all too uncommon. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Its the E (Experience) that really counts. I have seen so many methodologies over the past 25 years that I have been earning my living cutting code all with fancy sounding titles and a different way to say the same thing. I despair when someone else says much the same that Fred Brooks, Rumbaugh and Lorenson talked about. The same thing the three amigos said, the same stuff that SSADM, UML, DSDM, The Capability Maturity Model and all the others were supposed to solve. Pick any one and use it properly and many of the problems that SOLID is supposed to address go away.
The trick is in using it properly and not being sidetracked by some new scheme with a different set of initials.
|
|
|
|
|
|
Code Project has been coded using the Eeeeks methodology since Chris found a hamster sized whip.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
Paul Darlington wrote: On second thoughts I like being an Engineer and would not want to be a consultant better known as either sharks or parasites.
Two things we as a profession do not possess in great quantities are experience and common sense.
The good programmers quite often move into management rather than re-skill with new development tools.
AS they begin managing people who use tools that they never used they feel less able to offer the benefit
of their experience (even though it is probably still very valid).
One definition of experience is making the same mistakes that other people have made.
And that's just dumb if it can be avoided. You can always make more money but you can't make
more time, so any chance you can get to exchange money for time you should grab.
Sometimes those acronyms and books seem to cover common sense stuff that "everybody knows" but
if you pick 100 samples of code at random from production systems I think you'd do well to find
10-15 that were robust, readable, easily maintainable.
So common sense isn't nearly common enough.
It says a lot that 50% of people on a Coding website have never even heard of the SOLID principles.
It's rare for me to find programmers who read books. That's shocking but genuinely unless I go to
a Conference or a developers group meet up I generally don't meet programmers who read books or even
websites except to look up a specific solution.
That's not to say that after a few years of trial and error that some programmers don't figure out 2
or 3 of the SOLID principles themselves, but why waste all that time when you can read and understand them
and start applying some of them immediately.
A classic example is Fowler's Refactoring book. So often when I manage to get someone to read even part
of that book, they look at me funny because it's all common sense.
Well why aren't they bloody coding this way then?
Or they read one of the refactorings think it sounds cool, so they go through their entire code base trying to
apply it everywhere they can just because they can. Missing the point entirely.
Or best of all they find two refactorings that contradict each other and think Fowler is an idiot.
Those are my favourites.
-Richard
Hit any user to continue.
|
|
|
|
|
Gotta get some solid food as well.
mmm Steak 'n Veg pie ....yumm
|
|
|
|
|
There's a saying I wrote down from somewhere, and it's a better principal:
"If you can't find the time to do it right the first time . . .
How are you going to find the time to do it again?"
Just presume (as I learned to do) that I'm going to have to live with whatever it is I'm making and that changes will be necessary.
Some of what was mentioned in the link's 4 principals are the result of experience.
To start out in more successful paths more of the time, and avoid the nightmares of the past.
Just do it right - no need to codify coding.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek dissappointment. If you are searching for perfection in yourself, then you seek failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
..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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
