The latest dull fad - SOLID
-
Rob Philpott wrote:
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.
You'd inject that dependency :-\
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Well yes, you probably would. The change still needs to be made though. And if you do inject it, you'd probably inject according to some interface (which may also require change). That leads on to over-engineering as my simple object is now three things, the object an interface defining a way of persistence and the concrete object that does it. I'm of the school that if only one thing implements the interface, get rid of it, it's just clutter. Now that will annoy anyone who owns (and worse yet, has read) the GOF.
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.
Rob Philpott wrote:
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.
Indeed. I've complained about that before. It's actually even worse than having to maintain two classes: you have to maintain two classes where one needs intimate knowledge of the other. That also violates some "rule". SOLID is a religion.
-
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'm with you on the use of fads, catchphrases, and so on. I would be willing to be that 80% of the agile developers that mock XP (extreme programming) with the paired programming construct don't realize that 90% of their current methodologies are just a refactored form of XP with a SCRUM master. I haven't come up with it yet, but I am working on a variation of the of my own programming acronym called SOILED. I will keep you posted on that one. I have come to learn that Software Design Patterns are useful. The tenets described in SOLID are technically sound. The problem is, all of these terms have become rhetoric, and people know the terms, and can even explain what they mean. However, when it goes to trying to apply the concepts, all is lost. There is no context for reference to apply any of those principles towards, and therefore things just become more complicated. Reading through your 3rd and 4th paragraph, it would seem to me that SOLID is not the problem, the developers that built the system do not understand how to apply SOLID. A final case in point; I was describing to my peers (strong advocates of SOLID) how I have put an adapter interface in place between the use of all of my application code, and external libraries. This is whether it is the use of STL, existing libraries, or libraries to be developed internally, for future flexibility at a single point of change. At this point pride crept in, and they argued I shouldnt put an adapter between their library and my code, I should be using the library directly. I find it ironic their ego was arguing against the solID for this methodology they are adamant about. The I and the D both refer to creating single points of change through interfaces and dependency inversion. Fight the good fight, and I hope your co-workers aren't writing a nuclear power plant control system.
To know and not do, is not yet to know
-
Well yes, you probably would. The change still needs to be made though. And if you do inject it, you'd probably inject according to some interface (which may also require change). That leads on to over-engineering as my simple object is now three things, the object an interface defining a way of persistence and the concrete object that does it. I'm of the school that if only one thing implements the interface, get rid of it, it's just clutter. Now that will annoy anyone who owns (and worse yet, has read) the GOF.
Regards, Rob Philpott.
Rob Philpott wrote:
And if you do inject it, you'd probably inject according to some interface (which may also require change). That leads on to over-engineering as my simple object is now three things, the object an interface defining a way of persistence and the concrete object that does it.
Yes, seen enough projects with "clever" crap that prevented one from actually reading the code. It leads to ravioli code[^].
Rob Philpott wrote:
I'm of the school that if only one thing implements the interface, get rid of it, it's just clutter.
I'm of the school "don't reduce my work to a set of simplified rules, as the abstraction will leak". Either you can explain what advantage the concept has that you just typed ("izza Singleton!") or out it goes ("and this is a static class"). And yes, I actually expect an argumentation, not just the line that it's a best practice.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I'm with you on the use of fads, catchphrases, and so on. I would be willing to be that 80% of the agile developers that mock XP (extreme programming) with the paired programming construct don't realize that 90% of their current methodologies are just a refactored form of XP with a SCRUM master. I haven't come up with it yet, but I am working on a variation of the of my own programming acronym called SOILED. I will keep you posted on that one. I have come to learn that Software Design Patterns are useful. The tenets described in SOLID are technically sound. The problem is, all of these terms have become rhetoric, and people know the terms, and can even explain what they mean. However, when it goes to trying to apply the concepts, all is lost. There is no context for reference to apply any of those principles towards, and therefore things just become more complicated. Reading through your 3rd and 4th paragraph, it would seem to me that SOLID is not the problem, the developers that built the system do not understand how to apply SOLID. A final case in point; I was describing to my peers (strong advocates of SOLID) how I have put an adapter interface in place between the use of all of my application code, and external libraries. This is whether it is the use of STL, existing libraries, or libraries to be developed internally, for future flexibility at a single point of change. At this point pride crept in, and they argued I shouldnt put an adapter between their library and my code, I should be using the library directly. I find it ironic their ego was arguing against the solID for this methodology they are adamant about. The I and the D both refer to creating single points of change through interfaces and dependency inversion. Fight the good fight, and I hope your co-workers aren't writing a nuclear power plant control system.
To know and not do, is not yet to know
Paul Watt wrote:
Fight the good fight, and I hope your co-workers aren't writing a nuclear power plant control system.
No we're just doing weapon guidance, don't worry! :)
Regards, Rob Philpott.
-
Well yes, you probably would. The change still needs to be made though. And if you do inject it, you'd probably inject according to some interface (which may also require change). That leads on to over-engineering as my simple object is now three things, the object an interface defining a way of persistence and the concrete object that does it. I'm of the school that if only one thing implements the interface, get rid of it, it's just clutter. Now that will annoy anyone who owns (and worse yet, has read) the GOF.
Regards, Rob Philpott.
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.
-
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.
What if you want the object to persist itself to somewhere else? At least pass a persistence interface to the persist-yourself method.
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.
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.
-
What if you want the object to persist itself to somewhere else? At least pass a persistence interface to the persist-yourself method.
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 EinsteinSimply 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.
-
I'm with you on the use of fads, catchphrases, and so on. I would be willing to be that 80% of the agile developers that mock XP (extreme programming) with the paired programming construct don't realize that 90% of their current methodologies are just a refactored form of XP with a SCRUM master. I haven't come up with it yet, but I am working on a variation of the of my own programming acronym called SOILED. I will keep you posted on that one. I have come to learn that Software Design Patterns are useful. The tenets described in SOLID are technically sound. The problem is, all of these terms have become rhetoric, and people know the terms, and can even explain what they mean. However, when it goes to trying to apply the concepts, all is lost. There is no context for reference to apply any of those principles towards, and therefore things just become more complicated. Reading through your 3rd and 4th paragraph, it would seem to me that SOLID is not the problem, the developers that built the system do not understand how to apply SOLID. A final case in point; I was describing to my peers (strong advocates of SOLID) how I have put an adapter interface in place between the use of all of my application code, and external libraries. This is whether it is the use of STL, existing libraries, or libraries to be developed internally, for future flexibility at a single point of change. At this point pride crept in, and they argued I shouldnt put an adapter between their library and my code, I should be using the library directly. I find it ironic their ego was arguing against the solID for this methodology they are adamant about. The I and the D both refer to creating single points of change through interfaces and dependency inversion. Fight the good fight, and I hope your co-workers aren't writing a nuclear power plant control system.
To know and not do, is not yet to know
-
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.
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 Einstein -
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.
