|
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.
|
|
|
|
|
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
