|
leppie wrote: That sounds too complicated already
And sounds like a another load of bullshit tech.
|
|
|
|
|
Yeah, with that sort of acronym/expansion, it does lose a bit of credibility out of the box!
|
|
|
|
|
It's like design patterns we've been using them for years and never got around to giving them names/monikers untill a group of 4 smart arses did that for us.
|
|
|
|
|
Nishant Sivakumar wrote: Yeah, with that sort of acronym/expansion, it does lose a bit of credibility out of the box!
Which of the principles do you disagree with?
* Do you like making classes do more than one thing?
* Do you like modifying classes after they've been deployed?
* Do you think it should be ok to create derived classes that can not be substituted for their base class?
* Do you think it's better to have one big interface that handles lots of responsibilities, rather than split those responsibilities
into many interfaces so that classes can implement the responsibilities selectively?
* Do you think it's better to have classes instantiate their own dependencies rather than code against interfaces and have the implementation of those dependencies supplied to the class?
I'm asking genuinely here because there are arguments for and against some of the principles to greater and lesser extent. E.g. Single Responsibility and Interface Segregation and kinda no brainers, Dependency Injection you might be able to live happily without. The Open/Closed principle can be a struggle sometimes.
The point is, if a programmer wants to dismiss Solid as lacking credibility, they need to back that up by saying which aspects of it lack credibility.
Just because something is captured in a mnemonic doesn't meen it becomes invalid. Particularly in an industry that by and large seems to struggle to produce it's product in a consistantly professional manner.
-Rd
Hit any user to continue.
|
|
|
|
|
Richard A. Dalton wrote: Which of the principles do you disagree with?
None I guess. I meant its expansion:
Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion
Seriously, that is bizarre!
|
|
|
|
|
I've been using these for principles for years, but didn't know there was an Acronym for them. Strictly I fall into the first and last options....
|
|
|
|
|
I'm with you on the "don't know what it is but use it anyway" option.
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
Yeah - I was using them in 1990 - before there was a fancy acronym to describe them. Of course, the reality of a real-worl project is that nothing is concrete, and you almost never have time to "go back and refactor your code". In fact, the only time I can honestly say I've had that opportunity is when an application is being rewritte in a different language or, to a lesser extent, for a different platform.
It's all just theory, and the real world can crush a good theory like a fly under an anvil.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
