The latest dull fad - SOLID
-
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.
-
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
"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." That's the impression I got. I can see how a narrow vision of what 'single use' or 'single responsibility' means, can lead to some bad design work.
-
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 have been programming close to 40 years. SOLID is good, but it isn't a cure all. "If your only tool is a hammer, then every problem looks like a nail." However what I have found is projects that use SOLID and clean coding best practices tend to have few bugs and those bugs are easier to fix. Projects that didn't use SOLID and clean coding BP would end up being maintained by junior programmers and then rewritten. SRP has saved my tail many times, however it can be carried to extremes. For example: a = a + 1; Just a simple statement, but it violates SRP, because it does the following responsibilities: 1. Access memory 2. move a to an accumulator 3. load 1 into a register 4. add register to accumulator 5. save accumulator to memory Of course this is plain silly, but it goes to show that SRP can be taken to extremes. However the world responsibility really means it has one function. However the true meaning should be taken that it perform a single identifiable task. This task could be very complex for example launching a rocket. However within this Launch method, it may call other methods which also has a single responsibility and so on. My test is can you change anything in a method and it will still perform the correct operation as described by it's name. For example: AddItemToOrder(Order order, Item item,int NumOfItemsToAddToOrder) { DecrementItemCountInInventory(item,NumOfItemsToAddToOrder); var orderItem = new OrderItem(); orderItem.Item = item; orderItem.Qty = NumOfItemsToAddToOrder; OrderItemList.Add(orderItem); } This does two things: 1. It removes the count of items from the inventory 2. It adds an item to the order list. We could delete and change DecrementItemCountInInventory call without causing a problem with the function of this method. Of course it would screw up the database, but the order would be correct. Also another team working on the shipment part might also think they should decrement the count because it wasn't done in the mainly code. One of the things I try to do (of course not always possible) is to limit the functionality of a method to the point where the calling method knows if it was successful. Also there is exceptions. This method could throw 2 (out of memory and database exception). The logic to handle to exceptions from the calling method becomes much more complex.
-
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(); }
} -
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.
-
Sounds like they are taking the method's responsibility and applying it to the class level....
Exactly.
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
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'm, just now getting exposure to the Domain Model. From what I'm seeing in action at the moment, is that all hierarchies appear to be flat and relationships between objects are a mess to unravel and understand. It looks like spaghetti glue for OOD. I hope this isn't what the model is about... Gotta order that book today...
-
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.
-
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:
This is a good principle but is far too rigid.
Of course. It must be applied appropriately.
Rob Philpott wrote:
If an object wants to persist itself to disc then let it and SOLID can bugger off.
However if there are 200 objects then each of them should not be persisting themselves.
-
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.
First, you are right in that many people over use this (and other things) and sometimes push things to extreme. But why not admit that you don't believe others can help you and move on? SOLID is not a design pattern. It is a set of principals which when combined with design patterns can make code easier to maintain. It doesn't say that you can't have an object that appears to persist itself. But simply that said object would in fact have a division which the persistance is separate from the "business" logic. And yes, it can make more work. But as a project gets larger, it can reduce the amount of code. It can reduce searching for functionality (because persistance code isn't mixed with other logic). If you change the persistence, only a couple classes need to be changed, not every class that gets persisted. You have clearly not understood SOLID. It does not replace the 4 OOD aspects. It expands on how to use them and extends from the Gang of Four patterns.
-
First, you are right in that many people over use this (and other things) and sometimes push things to extreme. But why not admit that you don't believe others can help you and move on? SOLID is not a design pattern. It is a set of principals which when combined with design patterns can make code easier to maintain. It doesn't say that you can't have an object that appears to persist itself. But simply that said object would in fact have a division which the persistance is separate from the "business" logic. And yes, it can make more work. But as a project gets larger, it can reduce the amount of code. It can reduce searching for functionality (because persistance code isn't mixed with other logic). If you change the persistence, only a couple classes need to be changed, not every class that gets persisted. You have clearly not understood SOLID. It does not replace the 4 OOD aspects. It expands on how to use them and extends from the Gang of Four patterns.
Kirk Wood wrote:
You have clearly not understood SOLID
You see, you spoil what might have been a fair argument there when your resort to condescending and arrogant remarks like that.
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:
This is a good principle but is far too rigid.
Of course. It must be applied appropriately.
Rob Philpott wrote:
If an object wants to persist itself to disc then let it and SOLID can bugger off.
However if there are 200 objects then each of them should not be persisting themselves.
jschell wrote:
However if there are 200 objects then each of them should not be persisting themselves.
That may only hold true if all those objects had to be persisted at the same time. Even then, depending on how long it took to persist each object, it might still be more efficient to persist them one at a time (from a queue, for instance). Something pops the queue, but the object still saves "itself". The notion that 200 objects cannot save themselves implies that they are components of something "bigger"; I didn't read that.
-
jschell wrote:
However if there are 200 objects then each of them should not be persisting themselves.
That may only hold true if all those objects had to be persisted at the same time. Even then, depending on how long it took to persist each object, it might still be more efficient to persist them one at a time (from a queue, for instance). Something pops the queue, but the object still saves "itself". The notion that 200 objects cannot save themselves implies that they are components of something "bigger"; I didn't read that.
Gerry Schmitz wrote:
That may only hold true if all those objects had to be persisted at the same time.
No that has nothing to do with it.
Gerry Schmitz wrote:
Even then, depending on how long it took to persist each object, it might still be more efficient to persist them one at a time (from a queue, for instance). Something pops the queue, but the object still saves "itself".
Presuming that is a valid case then it would demonstrate my point that it is inappropriate for the objects to persist themselves. Certainly each would not be a queue.
Gerry Schmitz wrote:
The notion that 200 objects cannot save themselves implies that they are components of something "bigger
Not sure what that means but of course 200 objects which require persistence are part of a larger business entity.
-
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 think the S can actually help a lot, but I do not like the O (Open/Closed principle) because that one can become too restrictive. Imagine that you can never change a class and you end up creating new classes just because you should not change the faulty one...
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I think the S can actually help a lot, but I do not like the O (Open/Closed principle) because that one can become too restrictive. Imagine that you can never change a class and you end up creating new classes just because you should not change the faulty one...
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
Did you see Adam Tibi's response above about that?
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.
Couldn't agree more. I've shared the feeling since I first read about SOLID principles.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Did you see Adam Tibi's response above about that?
Regards, Rob Philpott.
Cool, thanks for pointing it out :). It's exactly how I think
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
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.
Once upon a time, Jargons and acronyms were created by people "who knew computers" to impress those "who didn't". Guess what, Now its a payback time for those "who didn't"!!!! OLID
