|
I don't think this is a reflection on SOLID, rather it's a reflection on people who try to appear cleverer than they are. Sometimes it's an experience thing - it takes a lot of hard work to get to the point where you write less code to solve a problem. Experience brings you an arsenal of tricks that you can use to simplify your code.
This space for rent
|
|
|
|
|
That's the problem. People are abusing how to do things and they blame on the principle.
|
|
|
|
|
It's taking me a lot of hard work to figure out who's really SOLID, and who's just cleverly impersonating SOLID. But, if there's anybody who's SOLID around here, I am sure it is Pete O'Hanlon. Pete O'Hanlon wrote: a lot of hard work to get to the point where you write less code to solve a problem Amen to that ! And, I think that to some extent "serendipity" come into play with that: in the original tale of the "Princes of Serendip" from which that word comes, an essential ingredient was that the Princes were actively looking for something, and they had the quality of "sagacity," the ability to recognize that fortuitious moment of discovery as being as important as it was.
Unfortunately, "serendipity" has now become mis-used to mean "weird stuff just happens," or refer to various mystical manifestations of whatever.
«In art as in science there is no delight without the detail ... Let me repeat that unless these are thoroughly understood and remembered, all “general ideas” (so easily acquired, so profitably resold) must necessarily remain but worn passports allowing their bearers short cuts from one area of ignorance to another.» Vladimir Nabokov, commentary on translation of “Eugene Onegin.”
|
|
|
|
|
This really has nothing at all to do with the SOLID principles. Imposing multi-layered architectures where they don't add any value is just poor design. In fact Joel Spolsky famously refers to these types as "Architecture Astronauts". They are just too far removed from the problem as to make any real contribution.
The SOLID principles are well worth understanding and mastering. Your applications will be all the better for doing so.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: Architecture Astronauts
Love it!
Must be that!
|
|
|
|
|
I guess if you value simplicity first (in other words, do more with less while making the code more readable for others) and those principles give you some inspiration for going further down that road.. then I am all for it!
also you should check with your colleague if they find it more simple... (since you will be biased towards you own creation) there is a really good marker for it. If you do something and they start copying you furiously, you obviously did something right! if They keep pestering about it.. you are going the wrong way...
also have a look back at it one year later... another marker
|
|
|
|
|
Super Lloyd wrote: you should check with your colleague if they find it more simple We do peer-reviews of ALL code before it gets checked in, so we're constantly checking each others work. Simplicity should be inherent in any solution - if your code isn't as simple as the job demands, we're probably going to knock you back. Sometimes code isn't simple just because the task isn't simple - but it should be as simple as possible. Saying that, I put my money where my mouth is here - when I write articles now, I try to demonstrate SOLID in my code, and keep it simple. Done well, SOLID is incredibly elegant.
This space for rent
|
|
|
|
|
Prebuilt stacks offer a handy shortcut, but sometimes the shortcut leads to a longer journey. Except for that new one. It will solve all the problems.
|
|
|
|
|
Interesting that he left out the most common issue: after you've gone through, scoured the source, and modded as much as you need, it won't scale.
The full-stack solutions I've worked with have so much going on to cover the one-size-fits-all paradigm that they do not scale. At all.
|
|
|
|
|
In May 1969, while passing over the far side of the Moon, the crew of Apollo 10 heard something strange. Cut off from contact with Houston back on Earth, the three of them were alone, listening to what they described as “outer-space type music.” It was, "The Great Gig In The Sky" wasn't it?
|
|
|
|
|
|
Obviously
|
|
|
|
|
|
If you think the moon is 2000 light years away, you need to retake astronomy 101.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Who says he was talking about our moon? Certainly there is a moon 2000 light years away!
Decrease the belief in God, and you increase the numbers of those who wish to play at being God by being “society’s supervisors,” who deny the existence of divine standards, but are very serious about imposing their own standards on society.-Neal A. Maxwell
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
As with most things in software development the ultimate currency for comments is time. /*Does something here*/
|
|
|
|
|
This afternoon I spent some time wrestling with an SSIS component I downloaded from Codeplex -- the comments are not in English.
|
|
|
|
|
I've seen A LOT of comments and all of them were utterly useless.
int i = 42;
customer.Save();
product.Save();
void FeatureFullyImplemented()
{
}
string helper = null;
int i = That's real life stuff.
Most programmers can't even write decent code let alone decent comments.
I go as far as to say comments are completely and utterly useless.
I've learned to hate and delete them
If I'll ever write my own language comments won't be a feature nuisance
|
|
|
|
|
Sander Rossel wrote: If I'll ever write my own language comments won't be a feature nuisance There'll be an unusual amount of unused string constants
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Curious to see which group most devs fit into, we recently polled nearly 900 software developers on CodeProject and asked them to tell us which of the four personality types they identify with most when it comes to dealing with internal and external expectations. Really?
|
|
|
|
|
Rubin's Framework is missing a type, I have no expectations whatsoever.
I call it the realist-never-to-be-disappointed type
|
|
|
|
|
That would make you the "Rebel" type.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Questionner for sure.
When I see how often specs are self contradicting, I wonder how it can be otherwise.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
ppolymorphe wrote: When I see how often specs are self contradicting
You work with specs? Lucky you. I get to work with fly by the seat of your pants, agile catastrophe, management wants a shiny new UI every 3 months, I can't even query the server for simple data out of the database because the guy in charge of the back end refuses to document the Django abortion he's using, and of course there's no docs on the third party database tech he's using, nobody heard of an acceptance test plan until I created one and then it sat on the shelf getting mouldy for months, and they expect me to take calls at 2 AM from the casino where some drunken gambler jammed his credit card into the ATM.
Uh, I'll go quietly back into my hole now.
Marc
|
|
|
|
|
What I call 'specs' is the talk with my boss. And usually it involve things self contradict or getting information where I would need some magic to get the answer.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|