The latest dull fad - SOLID
-
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
