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