|
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
