The latest dull fad - SOLID
-
Simply rewrite the method, or add another one. If you're writing an extensible framework which other's are going to use I wouldn't argue with that, but most people aren't. Both solutions will work just fine which is what it's all about at the end of the day.
Regards, Rob Philpott.
For simple systems that works fine. I agree. The problem I've run across when things are done as you suggest is that every object has to implement the persistence and some get it wrong or do it differently enough to be problematic.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
They create the acronym first and then try to get words to fit after, hence they can often be pointless.
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
PHS241 wrote:
They create the acronym first and then try to get words to fit after
Which is why we introduced a system whereby no software could be released without the following documents; Technical spec User manual Requirements Design Sign off
“I believe that there is an equality to all humanity. We all suck.” Bill Hicks
-
Well, he said simple object, so I assume simple or small system. So maybe interfaces or wide-ranging oop is overkill.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert EinsteinThe lack of size or complexity of something you're developing doesn't justify abandoning everything you've learnt over the years to help you make better software. For a start, how do you discern between small and large, simple and complex? That's such a subjective thing - I'm sure if you asked ten different developers you'd get ten different answers. My personal opinion is that there's no excuse for not doing things the right way the first time. Up to date developers should be au fait with interfaces, unit testing, mocking etc. so it's not like it would take any more time, particularly with tools like Resharper that make extracting interfaces and refactoring such a breeze.
-
The lack of size or complexity of something you're developing doesn't justify abandoning everything you've learnt over the years to help you make better software. For a start, how do you discern between small and large, simple and complex? That's such a subjective thing - I'm sure if you asked ten different developers you'd get ten different answers. My personal opinion is that there's no excuse for not doing things the right way the first time. Up to date developers should be au fait with interfaces, unit testing, mocking etc. so it's not like it would take any more time, particularly with tools like Resharper that make extracting interfaces and refactoring such a breeze.
I hear you and agree. I just think you use the right tools for the job. Some design "principles" and "patterns" might be used to make a calculator but that doesn't mean they should be used or that it's better if they are. Sometimes you can over-design and over-engineer for the problem space.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
I’ve noticed the acronym SOLID rearing its ugly head more and more lately. I first heard of it about a year ago but I think it’s probably about ten years old, and this is despite the fact I’ve been writing OOD code daily for the last 22 years. I’m not sure whether it qualifies as a design pattern, but it’s got the attributes of one – someone else’s opinion on how things should be done, stupid sounding names ‘Liskov substitution’, ‘Dependency inversion’, some self-righteousness about it – that sort of thing. When I learned C++ in 1990 there were 4 OOD aspects – Inheritance, Polymorphism, Encapsulation and Abstraction, but now according to SOLID there are five. I actually think the original four sum it up quite nicely, even to this day. The ‘S’ in SOLID is for Single Responsibility or ‘a class should only have one reason to change’. Indeed, usually because it’s not correct. This is a good principle but is far too rigid. The worst abuse I’ve seen is a system I worked on where they’d put all the logic into dialog box code, so that if you wanted the logic it necessitated instantiating GUI objects. It did make me shiver, but what about a simple object that has a method to persist itself to disc? That breaks the ‘S’ because you might change the persistence mechanism. So one 'should' create a separate type that does this. In practice this means what was one object is now two, and if I change the first I have to change the second. My project size doubles. If the persistence does change I still have to modify the second object or create a third. The same amount of work, but more spread out. It becomes less clear when I change my object which other classes need to be changed to reflect this, and the amount of information I need to hold in my head to make the change increases. There are advantages I wouldn’t argue with that, but there are also advantages, great advantages, to keeping things simple. If an object wants to persist itself to disc then let it and SOLID can bugger off. That's the 'S', don't get me started on the 'OLID'.
Regards, Rob Philpott.
I prefer things that run. Well, most things -- I'll avoid delving into toilet humour.
I wanna be a eunuchs developer! Pass me a bread knife!
-
The lack of size or complexity of something you're developing doesn't justify abandoning everything you've learnt over the years to help you make better software. For a start, how do you discern between small and large, simple and complex? That's such a subjective thing - I'm sure if you asked ten different developers you'd get ten different answers. My personal opinion is that there's no excuse for not doing things the right way the first time. Up to date developers should be au fait with interfaces, unit testing, mocking etc. so it's not like it would take any more time, particularly with tools like Resharper that make extracting interfaces and refactoring such a breeze.
-
I’ve noticed the acronym SOLID rearing its ugly head more and more lately. I first heard of it about a year ago but I think it’s probably about ten years old, and this is despite the fact I’ve been writing OOD code daily for the last 22 years. I’m not sure whether it qualifies as a design pattern, but it’s got the attributes of one – someone else’s opinion on how things should be done, stupid sounding names ‘Liskov substitution’, ‘Dependency inversion’, some self-righteousness about it – that sort of thing. When I learned C++ in 1990 there were 4 OOD aspects – Inheritance, Polymorphism, Encapsulation and Abstraction, but now according to SOLID there are five. I actually think the original four sum it up quite nicely, even to this day. The ‘S’ in SOLID is for Single Responsibility or ‘a class should only have one reason to change’. Indeed, usually because it’s not correct. This is a good principle but is far too rigid. The worst abuse I’ve seen is a system I worked on where they’d put all the logic into dialog box code, so that if you wanted the logic it necessitated instantiating GUI objects. It did make me shiver, but what about a simple object that has a method to persist itself to disc? That breaks the ‘S’ because you might change the persistence mechanism. So one 'should' create a separate type that does this. In practice this means what was one object is now two, and if I change the first I have to change the second. My project size doubles. If the persistence does change I still have to modify the second object or create a third. The same amount of work, but more spread out. It becomes less clear when I change my object which other classes need to be changed to reflect this, and the amount of information I need to hold in my head to make the change increases. There are advantages I wouldn’t argue with that, but there are also advantages, great advantages, to keeping things simple. If an object wants to persist itself to disc then let it and SOLID can bugger off. That's the 'S', don't get me started on the 'OLID'.
Regards, Rob Philpott.
Rob Philpott wrote:
When I learned C++ in 1990
When I learned OOP in the late 80s there were only three aspects: Inheritance, Polymorphism, Encapsulation . Where did Abstraction come from? Isn't it part of Encapsulation? Such concepts as SOLID and Design Patterns are training wheels for newbies; if you have real-world experience, you don't need them.
-
-
Rob Philpott wrote:
When I learned C++ in 1990
When I learned OOP in the late 80s there were only three aspects: Inheritance, Polymorphism, Encapsulation . Where did Abstraction come from? Isn't it part of Encapsulation? Such concepts as SOLID and Design Patterns are training wheels for newbies; if you have real-world experience, you don't need them.
For me, abstraction is about where you draw the boundaries between your objects. You know when you get it right because everything fits together neatly. So not really I don't think its part of encapsulation, but they have similar themes.
Regards, Rob Philpott.
-
I’ve noticed the acronym SOLID rearing its ugly head more and more lately. I first heard of it about a year ago but I think it’s probably about ten years old, and this is despite the fact I’ve been writing OOD code daily for the last 22 years. I’m not sure whether it qualifies as a design pattern, but it’s got the attributes of one – someone else’s opinion on how things should be done, stupid sounding names ‘Liskov substitution’, ‘Dependency inversion’, some self-righteousness about it – that sort of thing. When I learned C++ in 1990 there were 4 OOD aspects – Inheritance, Polymorphism, Encapsulation and Abstraction, but now according to SOLID there are five. I actually think the original four sum it up quite nicely, even to this day. The ‘S’ in SOLID is for Single Responsibility or ‘a class should only have one reason to change’. Indeed, usually because it’s not correct. This is a good principle but is far too rigid. The worst abuse I’ve seen is a system I worked on where they’d put all the logic into dialog box code, so that if you wanted the logic it necessitated instantiating GUI objects. It did make me shiver, but what about a simple object that has a method to persist itself to disc? That breaks the ‘S’ because you might change the persistence mechanism. So one 'should' create a separate type that does this. In practice this means what was one object is now two, and if I change the first I have to change the second. My project size doubles. If the persistence does change I still have to modify the second object or create a third. The same amount of work, but more spread out. It becomes less clear when I change my object which other classes need to be changed to reflect this, and the amount of information I need to hold in my head to make the change increases. There are advantages I wouldn’t argue with that, but there are also advantages, great advantages, to keeping things simple. If an object wants to persist itself to disc then let it and SOLID can bugger off. That's the 'S', don't get me started on the 'OLID'.
Regards, Rob Philpott.
Inheritance, Polymorphism, Encapsulation, Abstraction, Design Patterns, SOLID... Whatever you call them they simply seem like best practices to me. Practices you should know and understand and keep in the back of your head while programming in an OO language. I work at a company that did not understand ANY of that and I've seen some disaster code... I then introduced these terms and then I've seen some more disaster code. A whole lot of classes each with one method because 'a class should be responsible for one thing only' and all those classes had the same constructor and method signature (remember, there only is one method per class) with some parameters that were used in only two or three of those classes because 'the classes would be interchangeable' (like some kind of sick, twisted and perverted inheritance/polymorphism scheme). I'm not sure what's worse. That kind of programming or a Windows Form with thousands of lines of code (accessing the database, making calculations etc. etc.). I'm a big fan of all those 'fads', it's just to bad they are misinterpreted and abused. That's the fault of the programmers though, not the theory.
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
PHS241 wrote:
They create the acronym first and then try to get words to fit after
Which is why we introduced a system whereby no software could be released without the following documents; Technical spec User manual Requirements Design Sign off
“I believe that there is an equality to all humanity. We all suck.” Bill Hicks
-
I’ve noticed the acronym SOLID rearing its ugly head more and more lately. I first heard of it about a year ago but I think it’s probably about ten years old, and this is despite the fact I’ve been writing OOD code daily for the last 22 years. I’m not sure whether it qualifies as a design pattern, but it’s got the attributes of one – someone else’s opinion on how things should be done, stupid sounding names ‘Liskov substitution’, ‘Dependency inversion’, some self-righteousness about it – that sort of thing. When I learned C++ in 1990 there were 4 OOD aspects – Inheritance, Polymorphism, Encapsulation and Abstraction, but now according to SOLID there are five. I actually think the original four sum it up quite nicely, even to this day. The ‘S’ in SOLID is for Single Responsibility or ‘a class should only have one reason to change’. Indeed, usually because it’s not correct. This is a good principle but is far too rigid. The worst abuse I’ve seen is a system I worked on where they’d put all the logic into dialog box code, so that if you wanted the logic it necessitated instantiating GUI objects. It did make me shiver, but what about a simple object that has a method to persist itself to disc? That breaks the ‘S’ because you might change the persistence mechanism. So one 'should' create a separate type that does this. In practice this means what was one object is now two, and if I change the first I have to change the second. My project size doubles. If the persistence does change I still have to modify the second object or create a third. The same amount of work, but more spread out. It becomes less clear when I change my object which other classes need to be changed to reflect this, and the amount of information I need to hold in my head to make the change increases. There are advantages I wouldn’t argue with that, but there are also advantages, great advantages, to keeping things simple. If an object wants to persist itself to disc then let it and SOLID can bugger off. That's the 'S', don't get me started on the 'OLID'.
Regards, Rob Philpott.
I dropped the O few days ago A Call To Drop "The Open Closed Principle" From The SOLID Design Principles[^]. So, you are dropping the S and I'm dropping the O, what is left? The LID principles? :) I think the S is an advice to try to give a class the least responsibities rather than a single responsibility, take a good design pattern like MVC, the controller has two responsibilities.
Make it simple, as simple as possible, but not simpler.
-
Do you not think that using an interface for single implementations is useful at all? If I've already coded to an interface it's code in the bank - should another implementation come along I'm ready for it, and with an interface I can mock out all my dependencies and write proper unit tests. I'd choose to inject dependencies through the constructor as that signature defines the contract for the object's dependencies, another thing I can write tests against. Then when our Delphisaurs make a quick change without bothering to run the tests locally I can see exactly how and where they've broken the code once it gets checked in and Jenkins goes all red.
In this case your mocks are the second implementation and you need the interfaces. If you didn't mock, then "you aren't gonna need it".
jim lahey wrote:
and with an interface I can mock out all my dependencies and write proper unit tests
-
I dropped the O few days ago A Call To Drop "The Open Closed Principle" From The SOLID Design Principles[^]. So, you are dropping the S and I'm dropping the O, what is left? The LID principles? :) I think the S is an advice to try to give a class the least responsibities rather than a single responsibility, take a good design pattern like MVC, the controller has two responsibilities.
Make it simple, as simple as possible, but not simpler.
Actually, I'd like to drop the whole thing and bury it deep somewhere in a lead-lined coffin. I'm not saying the principles are bad or wrong, just that there is a lot more to developing OOD than SOLID. And I resent the way that I'd be judged on my OOD expertise based upon the appallingly abstract writings of someone who goes by the name of 'Uncle Bob'. Read your article - agree. You could spend far more time designing things with extensibility in mind, but that'll take a long time and may not be used, and to my mind goes completely against the idea of refactoring etc. When I start to write a bit of code, I just stick functionality anywhere - I really don't know what I'm doing. But as time goes on, and the architecture starts to reveal itself I continually move stuff around. I know when I've got it right when everything just starts to fit together very tidily. And unless its some sort of code which is there to be extended, I don't worry about extensibility. People can tell me that's wrong, but it isn't 99% of the time. Not great in that 1%, but for the most part that makes things simpler, smaller and more concise. Rant ends. *plink*
Regards, Rob Philpott.
-
Actually, I'd like to drop the whole thing and bury it deep somewhere in a lead-lined coffin. I'm not saying the principles are bad or wrong, just that there is a lot more to developing OOD than SOLID. And I resent the way that I'd be judged on my OOD expertise based upon the appallingly abstract writings of someone who goes by the name of 'Uncle Bob'. Read your article - agree. You could spend far more time designing things with extensibility in mind, but that'll take a long time and may not be used, and to my mind goes completely against the idea of refactoring etc. When I start to write a bit of code, I just stick functionality anywhere - I really don't know what I'm doing. But as time goes on, and the architecture starts to reveal itself I continually move stuff around. I know when I've got it right when everything just starts to fit together very tidily. And unless its some sort of code which is there to be extended, I don't worry about extensibility. People can tell me that's wrong, but it isn't 99% of the time. Not great in that 1%, but for the most part that makes things simpler, smaller and more concise. Rant ends. *plink*
Regards, Rob Philpott.
And following this kind of development model, if you check your code at the end, you'll find that most of the times it will follow the SOLID principles, without doing any kind of prior design work. Maybe you can think about SOLID as a quality check for the end result, rather than some principles to follow from the start. You can also think that SOLID are some pretty subjective principles and it's your job to decide to use them or to use something which suits the current job better. SOLID are just some general OOD principles, and of course there are some others, and as you can see right on the SOLID wikipedia page[^], there are other OOD principles You aren't gonna need it[^], KISS principle[^], which are somehow in contradiction with SOLID. So in conclusion, if you are a good programmer you don't have to think about the OOD principles and design patterns before you start to code. You will just know when your code is nice (starts to fit together very tidily). Then, you can bet that your code follows the best OOD principles. And if you search, you will also find some implementations of different design patterns (if I think back I implemented the factory pattern many times before reading about design patterns).
If you can't explain something to a six year old, you really don't understand it yourself. (Albert Einstein)
-
And following this kind of development model, if you check your code at the end, you'll find that most of the times it will follow the SOLID principles, without doing any kind of prior design work. Maybe you can think about SOLID as a quality check for the end result, rather than some principles to follow from the start. You can also think that SOLID are some pretty subjective principles and it's your job to decide to use them or to use something which suits the current job better. SOLID are just some general OOD principles, and of course there are some others, and as you can see right on the SOLID wikipedia page[^], there are other OOD principles You aren't gonna need it[^], KISS principle[^], which are somehow in contradiction with SOLID. So in conclusion, if you are a good programmer you don't have to think about the OOD principles and design patterns before you start to code. You will just know when your code is nice (starts to fit together very tidily). Then, you can bet that your code follows the best OOD principles. And if you search, you will also find some implementations of different design patterns (if I think back I implemented the factory pattern many times before reading about design patterns).
If you can't explain something to a six year old, you really don't understand it yourself. (Albert Einstein)
Yes, I'd agree with that. For me, KISS is the most important thing of all and any system which is unduly complex isn't a good system in my book. I'm the same, obviously things like factories and singletons have always been there. (How can you deserialize something without a factory?), but things like the 'builder pattern' well to me that's just some lines of code. Sometimes you initialise things in stages - SO WHAT?? It doesn't to me marit a chapter in a book or even a title. Having names for common patterns is useful, but the way the world looks at these things is warped. If you're a cook you don't need a recipe book and my dislike of patterns stems from people's attitudes that design comes from them. Someone wrote something on this site once about when they start out developing code the first thing they do is get out their Gang of Four book and go from there. Heaven help the company that employs him.
Regards, Rob Philpott.
-
I’ve noticed the acronym SOLID rearing its ugly head more and more lately. I first heard of it about a year ago but I think it’s probably about ten years old, and this is despite the fact I’ve been writing OOD code daily for the last 22 years. I’m not sure whether it qualifies as a design pattern, but it’s got the attributes of one – someone else’s opinion on how things should be done, stupid sounding names ‘Liskov substitution’, ‘Dependency inversion’, some self-righteousness about it – that sort of thing. When I learned C++ in 1990 there were 4 OOD aspects – Inheritance, Polymorphism, Encapsulation and Abstraction, but now according to SOLID there are five. I actually think the original four sum it up quite nicely, even to this day. The ‘S’ in SOLID is for Single Responsibility or ‘a class should only have one reason to change’. Indeed, usually because it’s not correct. This is a good principle but is far too rigid. The worst abuse I’ve seen is a system I worked on where they’d put all the logic into dialog box code, so that if you wanted the logic it necessitated instantiating GUI objects. It did make me shiver, but what about a simple object that has a method to persist itself to disc? That breaks the ‘S’ because you might change the persistence mechanism. So one 'should' create a separate type that does this. In practice this means what was one object is now two, and if I change the first I have to change the second. My project size doubles. If the persistence does change I still have to modify the second object or create a third. The same amount of work, but more spread out. It becomes less clear when I change my object which other classes need to be changed to reflect this, and the amount of information I need to hold in my head to make the change increases. There are advantages I wouldn’t argue with that, but there are also advantages, great advantages, to keeping things simple. If an object wants to persist itself to disc then let it and SOLID can bugger off. That's the 'S', don't get me started on the 'OLID'.
Regards, Rob Philpott.
I believe that there is no black/white when it comes to any kind of programming. For example if I am the ONLY programmer on a very small project to write a directory scanner that looks for patterns of text within our code and I know for a fact this will be written once, uses only by a few members and never "re-used" then you bet I'm gonna make some classes that don't fit the SOLID guideline. On the other hand I'm involved in a 10 person large project at the moment. Here I'll be much more careful to follow the guideline because I know my code will get used in places I never expected it to be used. In this group I know I must follow as close as possible to the other OLID items or there will be issues. But already this product has a HUGE number of files each with sometimes a single list of enums or a very small class with the interface in yet another file. It makes it easy to understand each file but makes the project file count rather large.
-
I’ve noticed the acronym SOLID rearing its ugly head more and more lately. I first heard of it about a year ago but I think it’s probably about ten years old, and this is despite the fact I’ve been writing OOD code daily for the last 22 years. I’m not sure whether it qualifies as a design pattern, but it’s got the attributes of one – someone else’s opinion on how things should be done, stupid sounding names ‘Liskov substitution’, ‘Dependency inversion’, some self-righteousness about it – that sort of thing. When I learned C++ in 1990 there were 4 OOD aspects – Inheritance, Polymorphism, Encapsulation and Abstraction, but now according to SOLID there are five. I actually think the original four sum it up quite nicely, even to this day. The ‘S’ in SOLID is for Single Responsibility or ‘a class should only have one reason to change’. Indeed, usually because it’s not correct. This is a good principle but is far too rigid. The worst abuse I’ve seen is a system I worked on where they’d put all the logic into dialog box code, so that if you wanted the logic it necessitated instantiating GUI objects. It did make me shiver, but what about a simple object that has a method to persist itself to disc? That breaks the ‘S’ because you might change the persistence mechanism. So one 'should' create a separate type that does this. In practice this means what was one object is now two, and if I change the first I have to change the second. My project size doubles. If the persistence does change I still have to modify the second object or create a third. The same amount of work, but more spread out. It becomes less clear when I change my object which other classes need to be changed to reflect this, and the amount of information I need to hold in my head to make the change increases. There are advantages I wouldn’t argue with that, but there are also advantages, great advantages, to keeping things simple. If an object wants to persist itself to disc then let it and SOLID can bugger off. That's the 'S', don't get me started on the 'OLID'.
Regards, Rob Philpott.
Always 'old' programmers who complain about these sort of things. I prefer having everything separated which makes everything maintainable and testable. A domain class carries data, nothing more, nothing less. A repository takes care of the CRUD. If you prefer to put everything in one class that's your decision, good luck creating a PI repo or dont cry if you bump into serializing issues. You are probably more a procedural object oriented programmer anyway. :)
-
I’ve noticed the acronym SOLID rearing its ugly head more and more lately. I first heard of it about a year ago but I think it’s probably about ten years old, and this is despite the fact I’ve been writing OOD code daily for the last 22 years. I’m not sure whether it qualifies as a design pattern, but it’s got the attributes of one – someone else’s opinion on how things should be done, stupid sounding names ‘Liskov substitution’, ‘Dependency inversion’, some self-righteousness about it – that sort of thing. When I learned C++ in 1990 there were 4 OOD aspects – Inheritance, Polymorphism, Encapsulation and Abstraction, but now according to SOLID there are five. I actually think the original four sum it up quite nicely, even to this day. The ‘S’ in SOLID is for Single Responsibility or ‘a class should only have one reason to change’. Indeed, usually because it’s not correct. This is a good principle but is far too rigid. The worst abuse I’ve seen is a system I worked on where they’d put all the logic into dialog box code, so that if you wanted the logic it necessitated instantiating GUI objects. It did make me shiver, but what about a simple object that has a method to persist itself to disc? That breaks the ‘S’ because you might change the persistence mechanism. So one 'should' create a separate type that does this. In practice this means what was one object is now two, and if I change the first I have to change the second. My project size doubles. If the persistence does change I still have to modify the second object or create a third. The same amount of work, but more spread out. It becomes less clear when I change my object which other classes need to be changed to reflect this, and the amount of information I need to hold in my head to make the change increases. There are advantages I wouldn’t argue with that, but there are also advantages, great advantages, to keeping things simple. If an object wants to persist itself to disc then let it and SOLID can bugger off. That's the 'S', don't get me started on the 'OLID'.
Regards, Rob Philpott.
Following any design pattern to the end will lead you to an overabstracted system that could be easier to maintain for a team of thousand people, but a single programmer can't understand, at all. That's why my only rule while programming is KISS.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Following any design pattern to the end will lead you to an overabstracted system that could be easier to maintain for a team of thousand people, but a single programmer can't understand, at all. That's why my only rule while programming is KISS.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
Sir, succinctly put and damn accurate I'm with you on that. That makes two of us anyway. Actually, in the real world where people just get on with things rather than bang on about how they should do them in places such than this, that probably is the norm. KISS - as you say, the ONLY rule. :thumbsup:
Regards, Rob Philpott.
