What i love about your videos is LENGTH. Its perfect. I can sit back with coffee, be done ca when i finish drinking and get to work feeling ive learned something useful. cheers
@@jr.BoarOfGold My plan is to try and keep videos between 10-30 minutes. Anything more than that and retention drops which causes the algorithm to ignore me as well. It's very much a balancing act.
@@hetsmiecht1029 Well actually RUclips changed that to be only 8 minutes instead of 10. The also automatically enabled mid-rolls in all the videos that were eligible after the new change, that's why you're seeing more ads on RUclips now :D
Hi Nick great video! In defense of LSP, It applies to interfaces to not only class inheritance as this principle predates modern (java-like) OOP. As i seen a lots of time, i found people using the same interface for very different logic, (mostly to implement dynamic behavior, but sometimes just for convenience) this makes the code extremely complex and hard to reason about as you cannot know what a class will do without deep understanding of the whole project in its current state (and sometimes without running the code with specific data) I believe that types should convey meaning, having an interface be a contract for some specific behavior (ISP) makes the code match more easier to understand, because you can see a specific type and know that the method you call will do. Imho DIoC without LSP (and ISP) is "unproductive" and adds unnecessary complexity as many of these principles they relay on each other to properly work. again, thanks for the great content. cheers
For me personally S, L and D are all very important, while O and I are not quite as important. "S" makes your code organised, so that people can read and understand it, but sometimes people struggle to define the scope of a responsibility, and either make them too small or too large, and both of these cause spaghetti. "D" makes your code loosely coupled and testable "L" makes your code correct. Your concretes must implement your abstractions correctly, or you won't be able to swap your implementations. Even if you're using composition over inheritance (and you should be) you still implement abstractions for "D". You might also extend an implementation by wrapping another implementation of the same abstraction in order to do "O", and which one you use should not matter to the caller, who only cares that the abstraction is fulfilled correctly. "O" is nice to have but realistically you will need to change some existing code. It's sometimes just the lesser evil than making a more complicated change just to satisfy "O". You should have adequate tests to ensure that existing desired behaviour is not broken by later changes anyway. "I" can be good, but I have also seen it cause damage, where it's split into multiple interfaces but then a consumer later needs to consume several of them, each of which is backed on the same implementation. It's good where it makes sense like splitting read only from read write, but I think there has to be a real benefit from doing it in each case, it should not just be "because solid says so", and the design should not be based on any knowledge of how the consumer will use it, because you could have multiple consumers or they could change.
You can't imagine how happy I was to see that I placed the first 4 principles the same way you did (I only placed Dependency Inversion in B rank instead of A). I wish there were more resources out there to practice SOLID principles and then compare to a given solution of the exercise (It's one thing to learn about these concepts but another to be able to actually apply them in real scenarios). Cheers Nick !
my tier would be S > O >= D > I > L *highest to lowest Single Responsibility is the highest because it is the most helpful, most implementable, and most useful. Liskov Substitution is the lowest because it is the least implementable (especially if you are creating more class just to satisfy this principle). Plus, there are alternative solutions.
Hey Nick, I pretty much agree with your tiering of The solid design principles. For the most part they pretty much reflect what I think about them as well. I often start off with dependency inversion and single responsibility as my go to design principles to immediately implement. Whereas, the others vary an importance to depending on context. Great video!
Agreed with this ranking. The dependency inversion gets bonus points because once you use it it's so natural and low effort to use, unlike SRP which is very important but can actually be hard to follow. And dependency injection enabling easier tests means you can always refactor down the path
Interface segregation principle is one of those things that's very powerful but almost nobody uses it correctly. In most of the code bases I've worked with everyone thinks about interfaces as "header interfaces" (all of the public properties and methods of the implementing class) rather than "role interfaces" (multiple interfaces defined by the consuming code). You can write perfectly decent software without proper interface segregation, but I'd love to see more people wrap their head around role interfaces.
Dependency inversion depends on Liskov's substitution principle to large part, so I would definitely rate L higher. Personally, I would probably rank none of them to the top since there are reasons to break all of them. Open/Closed principle I'd probably rank lower than the rest, unless you are specifically delivering a library, but the others I see as equally important.
@@nickchapsas LSP basically defines that pre- and post-conditions, as well as the invariants, need to be compatible between implementations. It hardly matters if you depend on an abstraction if the implementations don't fulfill that.
@@ShawnBlais check my comment above yours Yes, you can do DI without adhering to LSP, but it will just lead to unexpected behavior and bugs. Consider the common C callback interface: void do_something(FuncPtr callback, void* data); The condition on the interface is that "data" is passed as a parameter for the "callback" function, if some implementation of "do_something" would put NULL or other random data there instead, that implementation would be generally unusable for clients relying on the "do_something" -interface.
Honnestly I exactly described solid the same way you explained it during an interview and what is funny is that liskov substitution is actually reduced with time as inheritance is more and more replaced by composition except in case of base abstract classes
I played along and produced the same results, except that I put "L" into B-tier instead of C-tier. Also: I oscillated back and forth about putting "I" into A-tier, and for some of the things I write, "O" is absolutely S-tier! As for this "game", I think it's more important than you're giving it credit for. Coding is all about deciding between competing approaches having competing trade-offs, so your input as to what you think is _relatively_ more important between competing values is useful. What's especially useful is the reasoning for your preference - when and why you think one value might be more important than another.
This is spot on and 100% agree with your words. I have used your take on this for the last 5 years and it works. I have seen some bad supportable code with interface segregation where they have gone mad, multiple interfaces with nothing in them just to use the up chain, a dev support nightmare so it's right where it is. And as of liskov haven't violated that due to the fact it's to complicate to do it these days. Anyway thanks again for your vidoes from a 30 year dev veteran they are fantastic
Just to address something that came up a couple of times in the comments. Yes SRP can be defined the way I described it in the video. It can also be defined as “a class should only have one reason to change”. In the context of SOLID those are the exactly same for the simple reason that if you are following open-closed then: “If a class is doing only one thing then it only has one reason to change” and “if a class has only one reason to change then it is only doing one thing”. For context this is how Robert Martin originally defined it in his book "Agile Software Development, Principles, Patterns, and Practices": "The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility." He later rephrased that definition in the Clean Architecture book but one does not cancel the other.
“If a class is doing only one thing then it only has one reason to change” No, because the class could be used by multiple people. One of them wants you to change the class, you change it, then the others come to you and complain about the change they didn't want. As you may know Robert Martin has clarified that "reasons" are people. Or more precisely: the roles they play. He explains that in a video you can find on YT that's titled Robert C Martin - The Single Responsibility Principle .
Great video. In my own experience to date, most legacy code urgently needs S before you can even begin about thinking about OLID. If the language is OO heavy, then I go D next where harmless to do and then try and get unit testing happening - this is often hard because plumbing is so deeply embedded in code. I especially dislike pulling apart "using(sql_or_txt_file) { }" kinda code.
I always extend I Principle to use it for libraries / packages as well. for example, if I want to separate new libraries for common classes / interfaces, in many cases I will create two or more library projects. this can happen when some classes require other dependencies, such as some nugets.
I think the DI principle can be over applied. Supporting unknown input implementations takes extra effort and often doesn't get used. Gradually ascend the ramp of complexity, don't jump up it. It's usually easy to extract an interface later if you need to.
Great discussion on ranking the relative importance and agree with the ordering. I think the reason it's the order it is may have to do with the relative age of the principle. E,g, D is a relatively new concept relative to S. L is more recent than S but not as recent as D. Of course it may just be coincidental too. A couple things I've noticed over time: 1. Open-Closed tends to be something to evolve the code to over time. The first time you need a class, the long-term hierarchy may not be clear. If this is applied too early, you may easily be violating YAGNI. Over time as other "same-as" things are discovered, that class will need to be modified (violating the closed principle) in order to allow it to be open for extension as it relates to other classes. For example, one may start with a given implementation. As other "same-as" classes are discovered, the original class may morph into a base class with virtual and/or abstract methods/properties that can be extended. 2. "Composition over inheritance" - I think this rule can be taken to extremes in an effort to dismiss inheritance entirely. I think a better thing to focus on is asking "is this a 'same-as' or 'has-a' relationship?" "Same-as" tends to lean towards inheritance whereas "has-a" toward composition. Using inheritance for "has-a" relationships can be pretty brittle. It's much easier to inject those things.
Great video once again. I'm becoming a better developer cause of your channel, thanks. I have a request if you don't mind. If you can ask how many of your followers would like to see you build a small production ready solution, eg a weather app with its various micro service, just so that they can see how you would go about putting up almost everything you have taught us. Obviously if you don't mind and have the time of cause, otherwise your content is still fantastic the way it is and thanks for that
The LSP applies to Interface inheritance as well, doesn't it? And since DIP is so highly ranked, I would argue that you are actually having to account for LSP in your day-to-day coding. I actually struggle quite a lot with defining Interfaces that encompass just enough behavior (and not too much) so that different - but similar - objects fulfill the Interface, which is what LSP is all about, right? What if you have an IOrder Interface and you need to add a new Order type that doesn't need/want one of the methods in the Interface. This is an age old, non-trivial problem in OOP: Defining suitable abstractions that can accomodate for changes to the system. Once you have decided on an Interface, you're locked in. You could switch over Types, but this is frowned upon in OOP, because we are expected to rely on polymorphism.
LSP applies to the contract yes, but it's never really a concern in interfaces that don't have default method implementations in the interface since it defines a parent and child relationship and it assumes that there is logic there to break.
Who are these people who are swapping out their database systems? In 25 years of coding I’ve never done it and every attempt I’ve seen firsthand has been a business failure. I think that value is overstated, but DI has great value for the other reasons he mentioned.
literally the same ranking I give them. L in a big legacy project is critical, that's where the nasty impossible to track bugs like to hang out - especially the pre and post conditions being violated..such as exceptions that the base doesn't throw etc.
Great! Thank you for your videos. Did you hear about "Maybe and Bind" approach instead of chain of if(smth is not null) ? It's more functional, I think. What do you think about a couple videos on this topic (tutorial and opinion)?
@@nickchapsas What about going deeper and talking about LanguageExt ? That would be amazing. "Should you stop throwing exception ?" Maybe. Thanks for your work Nick
That's not what the Single Responsibility Principle stands for. There is a similar principle to the one you described, and it is applied to functions, but it is not the SRP. This is a widespread mistake that I used to make myself until I read the Clean Architecture book and hear the proper definition from Uncle Bob itself. For more info, check Chapter 7, SRP, and Chapter 13 of the Clean Architecture book
Taken from the original definition at Agile Software Development, Principles, Patterns, and Practices. "The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility." which is exactly what I said in the video. Every class (and every method I added) should be doing one thing only meaning it should be responsible for doing one thing. How is that different from the definition? It's not word for word but it is the exact same thing and context.
@@nickchapsas Using Robert Martin own words "Of all the SOLID principles, the Single Responsibility Principle (SRP) might be the least well understood. That’s likely because it has a particularly inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing. Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles-it is not the SRP." The SRP talks about a module/class having a single reason to change. This reason to change is more related to under which actors desire the module/class should change. By actors, he refers to stakeholders, clients, and developers in some cases depending on the domain. In the end, the SRP actually refers to grouping together in a class or module those functions and data structures that change at the same time and for the same reason (actor's will). It is about enforcing cohesion, not the singularity of behavior. The high-level SRP version is CCP (Common Closure Principle) which applies the same reasoning but for packages and libraries. Robert C. Martin is the creator of SRP and CCP. All this confusion was my confusion until I read the Clean Architecture.
@@nachovc The quote that I cited was from Agile Software Development, Principles, Patterns, and Practices which is the book that Robert Martin wrote in which he originally defined the principle. I've read Clean Architecture. The two quotes mean the exact same thing from different angles. Saying that a class should have one reason to change is the same thing as saying that it is supposed to be doing one thing. If something is doing one thing then it only have one reason to change. It's literally the same thing since both of those statements are 100% correct.
@@nickchapsas, I can see the implication going in one direction: If something is doing one thing, then it only has one reason to change. But that doesn't apply the other way. If something has a single reason to change not necessary is doing only one thing. If that were true, probably the Interface Segregation Principle would be redundant. Why else would it make such a clear clarification in Clean Architecture which is much a modern book (2015 or 2017, I think), by saying "...It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing. Make no mistake, there is a principle like that. A function should do one, and only one, thing... we use it at the lowest levels. But it is not one of the SOLID principles-it is not the SRP." Nice discussion, BTW!
You said that you only writes micro services, can you make a video or a serious of videos on microservices, messaging, patterns, best practices. Thank you ❤️
Completely agree with the ordering, D & S take the crown. I do struggle with O a bit. I try to have only one method that executes some centralized BL. Buf if I need to make behavior adjustments, then I will need to change the code in that one spot. I don't think there is a good way around that unless I apply things like strategy pattern but that seems overkill if it's just one small method. Thoughts?
I just came across something like this a few hours ago, and I think I like it like this: What you're saying I completely agree with, but when the day comes where you need to make changes it is wise to decide then and there whether you should take the time to replace it with a Strategy pattern now that you've proven to yourself that you had to revisit this code. (Code that's instantly 'dead' the moment you write it might never have the need for a fancy pattern. So maybe one refactor later you decide on it)
@@jangohemmes352 that's exactly what I do now, centralized business logic that only needs to be changed in 1 place. Apply additional design patterns to it if modification s are frequent or the initial use case changes a lot Just curious if people have other ideas for a "better" initial setup.
I have found that O is a bit of a situational one and very much open to interpretetion. Like, the concern other than bloated classes, is that you can make cascading breaking changes but if you have unit tests covering that code then what's the problem? Things like this are very open to the coder's opinions on the matter so it shouldn't be taken as a hard rule.
How do you implement composition instead of inheritence with dependency injection? When I tried, I had parameters need to be passed to the inner object and the dependency injection prevent passing parameters. Maybe you can do a video on that also?
I'm confused why you ranked Open/Closed so highly if you don't use inheritance much. Doesn't this mean the vast majority of your code is open for modification since you typically work with flat hierarchies? I thought the whole thrust of open closed is to extend classes in order to add functionality, rather than modify the base class, am I wrong?
I use Rust, so Interface Segregation is S tier and L doesn't exist; I also put Open-Close in B-tier (although it's something I could probably be served by a better understanding of)
AFAIK Rust isn't considered an Object-oriented language by design and SOLID principles apply directly only on OOP languages. I should have actually mentioned that. You can adapt them to other languages but the gravity of different principles change, like you mentioned.
@@nickchapsas Rust's OO is a bit weird; pretty much the only classical OOP feature they're missing (deliberately, as you said) is inheritance. Most of the principles still apply, although they do indeed have adjusted weights.
I always wonder what's the real use of interface segregation principle when you already follow single responsibility principle. I don't pay attention to it, because if I would violate the interface segregation principle, it would be already visible in my single responsibility checks as some class eventually needs to implement the interface
There's some low level interfaces I use often in C# that are a good example, IDisposable, IComparable and ISerializable. It's also a good tool for refactoring legacy code where you do have some classes with too much responsibility, it helps you to start prying them apart But yeah I don't find it's often a thing I have to think of much.
Hey Luigi, I don't really work with front-end at all at a professional capacity and I like talking about subjects I'm proficient at so unfortunately this channel won't be producing and front-end specific content.
@@nickchapsas Ok, I understand. Better to stay in back-end, as I like, but more often recruiters search for front-end skills also for back-end developer, so I've asked you that.
I have never heard a good explanation of the Open/Closed principle. If I have a class that filters employees to show people over the age of 30, and the business rule changes, do I not just go in and replaced the number?
Obviously, if it has to change, it has to change. The SOLID-O principle is about WHERE and HOW the change is made. Are you opening up a working class that then needs to be recomplied AND retested, AND - and this is big - redeployed? That's what the Open-Closed Principle hopes to minimize and avoid. It seeks to have new functionality being an ADDITION, not a CHANGE. The Open-Closed Principle is mostly concerned about functional changes, because changes to a parameter like an "over 30" filter on age shouldn't require but a single change to some file or database value holding such configuration type of constants. As a borderline inviolable rule, you should never have a hard coded constant like 30 living within a routine... it should always be coming from the outside, at the class level at a minimum, and preferably from a configuration file or database or something. The reason you want that is for testing, and for ease of change & deploy, and for consistency across the application (in case multiple places use the same "over 30" constraint).
@@mathboy8188 hard coded, you are right, it was maybe a poor example. I think I understand the principle, just not the explanation or name for it 🤷🏻♂️
Actually in Micro Services I heavily use inheritance for base classes. Like a base controller that you can inherit from. Or a base repository that checks first a Redis cache before hitting the database. Or a base entity that implements auditable information.
I’ve only seen that model cause problems long term. I 99% go composition over inheritance unless there is a very specific thing that is too much of a hustle do do otherwise. For example what you described should be done with decoration not inheritance. You just coupled 2 things together when you only needed an interface and DI redirection. I have a video on how to do this exact thing the clean way. It’s call something like “implementating decoration with scrutor”. Highly recommend it
S is not about class doing one thing, you get it wrong. We already have a principle which say that something should do only one thing, and it is about methods, not class, nothing to do with SOLID. Feel free to investigate what is S =)
Yeah I've read clean architecture as well. The original definition by Rober Martin does actually say that it's supposed to do one thing. He later rephrased that he meant that it should have one reason to change. To me as long as you also follow open-closed those two are exactly the same. If your class is doing one thing then it only has one reason to change and if a class has only one reason to change (and is following open-closed, which it should) then it is only doing one thing. For context this is how Robert Martin originally defined it in his book "Agile Software Development, Principles, Patterns, and Practices": "The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility." =)
What i love about your videos is LENGTH. Its perfect. I can sit back with coffee, be done ca when i finish drinking and get to work feeling ive learned something useful. cheers
I really appreciate you saying that because I’m making videos that I’d watch as well and length is a dealbreaker for me too
@@nickchapsas But Nick, don't be afraid to dream big, a detailed 30 minutes video would be great too
@@jr.BoarOfGold My plan is to try and keep videos between 10-30 minutes. Anything more than that and retention drops which causes the algorithm to ignore me as well. It's very much a balancing act.
@@nickchapsas just make sure the vid is over 10 mins long, or else you can't have mid roll ads 😜
@@hetsmiecht1029 Well actually RUclips changed that to be only 8 minutes instead of 10. The also automatically enabled mid-rolls in all the videos that were eligible after the new change, that's why you're seeing more ads on RUclips now :D
I just want to say, as a junior developer, your channel has been absolute gold for learning to become a better engineer. Thanks for what you're doing.
I absolutely agree with you. Thanks Nick!
Hi Nick great video!
In defense of LSP, It applies to interfaces to not only class inheritance as this principle predates modern (java-like) OOP.
As i seen a lots of time, i found people using the same interface for very different logic, (mostly to implement dynamic behavior, but sometimes just for convenience)
this makes the code extremely complex and hard to reason about as you cannot know what a class will do without deep understanding of the whole project in its current state (and sometimes without running the code with specific data)
I believe that types should convey meaning, having an interface be a contract for some specific behavior (ISP) makes the code match more easier to understand, because you can see a specific type and know that the method you call will do.
Imho DIoC without LSP (and ISP) is "unproductive" and adds unnecessary complexity as many of these principles they relay on each other to properly work.
again, thanks for the great content. cheers
For me personally S, L and D are all very important, while O and I are not quite as important.
"S" makes your code organised, so that people can read and understand it, but sometimes people struggle to define the scope of a responsibility, and either make them too small or too large, and both of these cause spaghetti.
"D" makes your code loosely coupled and testable
"L" makes your code correct. Your concretes must implement your abstractions correctly, or you won't be able to swap your implementations. Even if you're using composition over inheritance (and you should be) you still implement abstractions for "D". You might also extend an implementation by wrapping another implementation of the same abstraction in order to do "O", and which one you use should not matter to the caller, who only cares that the abstraction is fulfilled correctly.
"O" is nice to have but realistically you will need to change some existing code. It's sometimes just the lesser evil than making a more complicated change just to satisfy "O". You should have adequate tests to ensure that existing desired behaviour is not broken by later changes anyway.
"I" can be good, but I have also seen it cause damage, where it's split into multiple interfaces but then a consumer later needs to consume several of them, each of which is backed on the same implementation. It's good where it makes sense like splitting read only from read write, but I think there has to be a real benefit from doing it in each case, it should not just be "because solid says so", and the design should not be based on any knowledge of how the consumer will use it, because you could have multiple consumers or they could change.
I think you just invented D-SOIL.
Developer-SOIL, the soil from which healthy code will grow.
I actually noticed that during editing and I was laughing on my own 😂
@@nickchapsas And it works so well, will be using it from now on :P
underrated comment.
You can't imagine how happy I was to see that I placed the first 4 principles the same way you did (I only placed Dependency Inversion in B rank instead of A). I wish there were more resources out there to practice SOLID principles and then compare to a given solution of the exercise (It's one thing to learn about these concepts but another to be able to actually apply them in real scenarios). Cheers Nick !
my tier would be S > O >= D > I > L *highest to lowest
Single Responsibility is the highest because it is the most helpful, most implementable, and most useful.
Liskov Substitution is the lowest because it is the least implementable (especially if you are creating more class just to satisfy this principle). Plus, there are alternative solutions.
Hey Nick, I pretty much agree with your tiering of The solid design principles. For the most part they pretty much reflect what I think about them as well. I often start off with dependency inversion and single responsibility as my go to design principles to immediately implement. Whereas, the others vary an importance to depending on context. Great video!
Agreed with this ranking. The dependency inversion gets bonus points because once you use it it's so natural and low effort to use, unlike SRP which is very important but can actually be hard to follow. And dependency injection enabling easier tests means you can always refactor down the path
Interface segregation principle is one of those things that's very powerful but almost nobody uses it correctly. In most of the code bases I've worked with everyone thinks about interfaces as "header interfaces" (all of the public properties and methods of the implementing class) rather than "role interfaces" (multiple interfaces defined by the consuming code). You can write perfectly decent software without proper interface segregation, but I'd love to see more people wrap their head around role interfaces.
Dependency inversion depends on Liskov's substitution principle to large part, so I would definitely rate L higher. Personally, I would probably rank none of them to the top since there are reasons to break all of them. Open/Closed principle I'd probably rank lower than the rest, unless you are specifically delivering a library, but the others I see as equally important.
How come? I'm interested to hearing this because I can't see any way that DIP would depend on LSP at all.
@@nickchapsas LSP basically defines that pre- and post-conditions, as well as the invariants, need to be compatible between implementations. It hardly matters if you depend on an abstraction if the implementations don't fulfill that.
@@defeqel6537 Dependency Inversion does not depend on sub classes at all, it is just a fancy word for a basic facade pattern.
@@ShawnBlais check my comment above yours
Yes, you can do DI without adhering to LSP, but it will just lead to unexpected behavior and bugs.
Consider the common C callback interface: void do_something(FuncPtr callback, void* data);
The condition on the interface is that "data" is passed as a parameter for the "callback" function, if some implementation of "do_something" would put NULL or other random data there instead, that implementation would be generally unusable for clients relying on the "do_something" -interface.
it's the great conclusion of solid principle, Thank you.
Honnestly I exactly described solid the same way you explained it during an interview and what is funny is that liskov substitution is actually reduced with time as inheritance is more and more replaced by composition except in case of base abstract classes
I played along and produced the same results, except that I put "L" into B-tier instead of C-tier.
Also: I oscillated back and forth about putting "I" into A-tier, and for some of the things I write, "O" is absolutely S-tier!
As for this "game", I think it's more important than you're giving it credit for. Coding is all about deciding between competing approaches having competing trade-offs, so your input as to what you think is _relatively_ more important between competing values is useful. What's especially useful is the reasoning for your preference - when and why you think one value might be more important than another.
This is spot on and 100% agree with your words. I have used your take on this for the last 5 years and it works. I have seen some bad supportable code with interface segregation where they have gone mad, multiple interfaces with nothing in them just to use the up chain, a dev support nightmare so it's right where it is. And as of liskov haven't violated that due to the fact it's to complicate to do it these days. Anyway thanks again for your vidoes from a 30 year dev veteran they are fantastic
Forget SOLID and apply D SOIL. 😜
Just to address something that came up a couple of times in the comments. Yes SRP can be defined the way I described it in the video. It can also be defined as “a class should only have one reason to change”. In the context of SOLID those are the exactly same for the simple reason that if you are following open-closed then: “If a class is doing only one thing then it only has one reason to change” and “if a class has only one reason to change then it is only doing one thing”.
For context this is how Robert Martin originally defined it in his book "Agile Software Development, Principles, Patterns, and Practices": "The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility."
He later rephrased that definition in the Clean Architecture book but one does not cancel the other.
“If a class is doing only one thing then it only has one reason to change”
No, because the class could be used by multiple people. One of them wants you to change the class, you change it, then the others come to you and complain about the change they didn't want.
As you may know Robert Martin has clarified that "reasons" are people. Or more precisely: the roles they play.
He explains that in a video you can find on YT that's titled Robert C Martin - The Single Responsibility Principle
.
Great video. In my own experience to date, most legacy code urgently needs S before you can even begin about thinking about OLID. If the language is OO heavy, then I go D next where harmless to do and then try and get unit testing happening - this is often hard because plumbing is so deeply embedded in code. I especially dislike pulling apart "using(sql_or_txt_file) { }" kinda code.
I always extend I Principle to use it for libraries / packages as well.
for example, if I want to separate new libraries for common classes / interfaces, in many cases I will create two or more library projects.
this can happen when some classes require other dependencies, such as some nugets.
Thanks for this awesome content!
From my limited experience so far I would have ranked them the same way and totally agree with you.
I think the DI principle can be over applied. Supporting unknown input implementations takes extra effort and often doesn't get used. Gradually ascend the ramp of complexity, don't jump up it. It's usually easy to extract an interface later if you need to.
Great discussion on ranking the relative importance and agree with the ordering. I think the reason it's the order it is may have to do with the relative age of the principle. E,g, D is a relatively new concept relative to S. L is more recent than S but not as recent as D. Of course it may just be coincidental too.
A couple things I've noticed over time:
1. Open-Closed tends to be something to evolve the code to over time. The first time you need a class, the long-term hierarchy may not be clear. If this is applied too early, you may easily be violating YAGNI. Over time as other "same-as" things are discovered, that class will need to be modified (violating the closed principle) in order to allow it to be open for extension as it relates to other classes. For example, one may start with a given implementation. As other "same-as" classes are discovered, the original class may morph into a base class with virtual and/or abstract methods/properties that can be extended.
2. "Composition over inheritance" - I think this rule can be taken to extremes in an effort to dismiss inheritance entirely. I think a better thing to focus on is asking "is this a 'same-as' or 'has-a' relationship?" "Same-as" tends to lean towards inheritance whereas "has-a" toward composition. Using inheritance for "has-a" relationships can be pretty brittle. It's much easier to inject those things.
Great video once again. I'm becoming a better developer cause of your channel, thanks. I have a request if you don't mind. If you can ask how many of your followers would like to see you build a small production ready solution, eg a weather app with its various micro service, just so that they can see how you would go about putting up almost everything you have taught us. Obviously if you don't mind and have the time of cause, otherwise your content is still fantastic the way it is and thanks for that
If you don’t have video about “how clean code project layers look like”, you should create one. I think it will be interesting.
I like your process of thought and your technical explanations. Είσαι ωραίος. 👍
The LSP applies to Interface inheritance as well, doesn't it? And since DIP is so highly ranked, I would argue that you are actually having to account for LSP in your day-to-day coding. I actually struggle quite a lot with defining Interfaces that encompass just enough behavior (and not too much) so that different - but similar - objects fulfill the Interface, which is what LSP is all about, right? What if you have an IOrder Interface and you need to add a new Order type that doesn't need/want one of the methods in the Interface. This is an age old, non-trivial problem in OOP: Defining suitable abstractions that can accomodate for changes to the system. Once you have decided on an Interface, you're locked in. You could switch over Types, but this is frowned upon in OOP, because we are expected to rely on polymorphism.
LSP applies to the contract yes, but it's never really a concern in interfaces that don't have default method implementations in the interface since it defines a parent and child relationship and it assumes that there is logic there to break.
Who are these people who are swapping out their database systems? In 25 years of coding I’ve never done it and every attempt I’ve seen firsthand has been a business failure. I think that value is overstated, but DI has great value for the other reasons he mentioned.
Good video. What are S, A, B, and C?
very good explanation
Just a reminder that co and contravariance are also aspects of the Liskov Substitution Principle, which is especially important for libraries.
literally the same ranking I give them. L in a big legacy project is critical, that's where the nasty impossible to track bugs like to hang out - especially the pre and post conditions being violated..such as exceptions that the base doesn't throw etc.
Great! Thank you for your videos.
Did you hear about "Maybe and Bind" approach instead of chain of if(smth is not null) ? It's more functional, I think. What do you think about a couple videos on this topic (tutorial and opinion)?
I actually have a video on that very topic. You can check it here: ruclips.net/video/OJjVvPINlYA/видео.html
@@nickchapsas Oh... I'm so blind! Thank you.
No worries, the name is a bit deceiving so I can see how it can be missed 😃
@@nickchapsas What about going deeper and talking about LanguageExt ? That would be amazing.
"Should you stop throwing exception ?" Maybe.
Thanks for your work Nick
That's not what the Single Responsibility Principle stands for. There is a similar principle to the one you described, and it is applied to functions, but it is not the SRP.
This is a widespread mistake that I used to make myself until I read the Clean Architecture book and hear the proper definition from Uncle Bob itself.
For more info, check Chapter 7, SRP, and Chapter 13 of the Clean Architecture book
Outside that constructive comment I really like your content, keep it up!
Taken from the original definition at Agile Software Development, Principles, Patterns, and Practices. "The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility." which is exactly what I said in the video. Every class (and every method I added) should be doing one thing only meaning it should be responsible for doing one thing. How is that different from the definition? It's not word for word but it is the exact same thing and context.
@@nickchapsas Using Robert Martin own words
"Of all the SOLID principles, the Single Responsibility Principle (SRP) might be the least well understood. That’s likely because it has a particularly inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing.
Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles-it is not the SRP."
The SRP talks about a module/class having a single reason to change. This reason to change is more related to under which actors desire the module/class should change.
By actors, he refers to stakeholders, clients, and developers in some cases depending on the domain.
In the end, the SRP actually refers to grouping together in a class or module those functions and data structures that change at the same time and for the same reason (actor's will).
It is about enforcing cohesion, not the singularity of behavior.
The high-level SRP version is CCP (Common Closure Principle) which applies the same reasoning but for packages and libraries.
Robert C. Martin is the creator of SRP and CCP.
All this confusion was my confusion until I read the Clean Architecture.
@@nachovc The quote that I cited was from Agile Software Development, Principles, Patterns, and Practices which is the book that Robert Martin wrote in which he originally defined the principle. I've read Clean Architecture. The two quotes mean the exact same thing from different angles. Saying that a class should have one reason to change is the same thing as saying that it is supposed to be doing one thing. If something is doing one thing then it only have one reason to change. It's literally the same thing since both of those statements are 100% correct.
@@nickchapsas, I can see the implication going in one direction:
If something is doing one thing, then it only has one reason to change.
But that doesn't apply the other way.
If something has a single reason to change not necessary is doing only one thing. If that were true, probably the Interface Segregation Principle would be redundant.
Why else would it make such a clear clarification in Clean Architecture which is much a modern book (2015 or 2017, I think), by saying
"...It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing.
Make no mistake, there is a principle like that. A function should do one, and only one, thing... we use it at the lowest levels. But it is not one of the SOLID principles-it is not the SRP."
Nice discussion, BTW!
Liskov Substitution Principle very underrated
You said that you only writes micro services, can you make a video or a serious of videos on microservices, messaging, patterns, best practices. Thank you ❤️
God, I love the DSOIL principles!
Stands for Developer Soil. You know, kind of like the foundation for your code 😂
@@nickchapsas or Developer Software OIL, it keeps it all running smoothly 😅
Completely agree with the ordering, D & S take the crown.
I do struggle with O a bit. I try to have only one method that executes some centralized BL. Buf if I need to make behavior adjustments, then I will need to change the code in that one spot.
I don't think there is a good way around that unless I apply things like strategy pattern but that seems overkill if it's just one small method. Thoughts?
I just came across something like this a few hours ago, and I think I like it like this:
What you're saying I completely agree with, but when the day comes where you need to make changes it is wise to decide then and there whether you should take the time to replace it with a Strategy pattern now that you've proven to yourself that you had to revisit this code. (Code that's instantly 'dead' the moment you write it might never have the need for a fancy pattern. So maybe one refactor later you decide on it)
@@jangohemmes352 that's exactly what I do now, centralized business logic that only needs to be changed in 1 place. Apply additional design patterns to it if modification s are frequent or the initial use case changes a lot
Just curious if people have other ideas for a "better" initial setup.
I have found that O is a bit of a situational one and very much open to interpretetion. Like, the concern other than bloated classes, is that you can make cascading breaking changes but if you have unit tests covering that code then what's the problem? Things like this are very open to the coder's opinions on the matter so it shouldn't be taken as a hard rule.
Can you please make a video on liskov
Cause from what I read on internet. It's very confusing
I almost feel this video came as a result of the comment section on the refactoring videos :) Partly my fault! Good work :)
I have to admit, it was all you Liam
@@nickchapsas I'm sorry!
So a soil became a doil. Nice vid thanks
How do you implement composition instead of inheritence with dependency injection?
When I tried, I had parameters need to be passed to the inner object and the dependency injection prevent passing parameters. Maybe you can do a video on that also?
LSP: I use it when writing interfaces -> all same name methods across interfaces must have the same signature.
Great video, thanks! ☺️
Agree
I'm confused why you ranked Open/Closed so highly if you don't use inheritance much. Doesn't this mean the vast majority of your code is open for modification since you typically work with flat hierarchies? I thought the whole thrust of open closed is to extend classes in order to add functionality, rather than modify the base class, am I wrong?
No. I am using functional programming elements in my code to get around it in a way more elegant way
keeping those algorithms happy...
I prefer to test a lot than to deal strictly with OCP. LOL
I use Rust, so Interface Segregation is S tier and L doesn't exist; I also put Open-Close in B-tier (although it's something I could probably be served by a better understanding of)
AFAIK Rust isn't considered an Object-oriented language by design and SOLID principles apply directly only on OOP languages. I should have actually mentioned that. You can adapt them to other languages but the gravity of different principles change, like you mentioned.
@@nickchapsas Rust's OO is a bit weird; pretty much the only classical OOP feature they're missing (deliberately, as you said) is inheritance. Most of the principles still apply, although they do indeed have adjusted weights.
I always wonder what's the real use of interface segregation principle when you already follow single responsibility principle. I don't pay attention to it, because if I would violate the interface segregation principle, it would be already visible in my single responsibility checks as some class eventually needs to implement the interface
There's some low level interfaces I use often in C# that are a good example, IDisposable, IComparable and ISerializable. It's also a good tool for refactoring legacy code where you do have some classes with too much responsibility, it helps you to start prying them apart
But yeah I don't find it's often a thing I have to think of much.
Dependency Inversion kind of relies quite heavily on the S.O.L.I of SOLID.... It's like the cherry on the parfait...
Will you make a playlist also for a front-end skill, like Vue.js, Nick?
Hey Luigi, I don't really work with front-end at all at a professional capacity and I like talking about subjects I'm proficient at so unfortunately this channel won't be producing and front-end specific content.
@@nickchapsas Ok, I understand. Better to stay in back-end, as I like, but more often recruiters search for front-end skills also for back-end developer, so I've asked you that.
I have never heard a good explanation of the Open/Closed principle.
If I have a class that filters employees to show people over the age of 30, and the business rule changes, do I not just go in and replaced the number?
Obviously, if it has to change, it has to change. The SOLID-O principle is about WHERE and HOW the change is made. Are you opening up a working class that then needs to be recomplied AND retested, AND - and this is big - redeployed? That's what the Open-Closed Principle hopes to minimize and avoid. It seeks to have new functionality being an ADDITION, not a CHANGE.
The Open-Closed Principle is mostly concerned about functional changes, because changes to a parameter like an "over 30" filter on age shouldn't require but a single change to some file or database value holding such configuration type of constants. As a borderline inviolable rule, you should never have a hard coded constant like 30 living within a routine... it should always be coming from the outside, at the class level at a minimum, and preferably from a configuration file or database or something. The reason you want that is for testing, and for ease of change & deploy, and for consistency across the application (in case multiple places use the same "over 30" constraint).
@@mathboy8188 hard coded, you are right, it was maybe a poor example.
I think I understand the principle, just not the explanation or name for it 🤷🏻♂️
Do a smash or pass on SOLID principles
I can never remember what SOLID stands for. Stellar converter! Oberfell v. Hodges! Listerine! Ice ice baby; Dijkstra maps! 😛
I rarely use inheritance these days.
👍🏽
D and O are most important. everyting else is optional.
Do you play WoW mate? :)
Actually in Micro Services I heavily use inheritance for base classes. Like a base controller that you can inherit from. Or a base repository that checks first a Redis cache before hitting the database. Or a base entity that implements auditable information.
I’ve only seen that model cause problems long term. I 99% go composition over inheritance unless there is a very specific thing that is too much of a hustle do do otherwise. For example what you described should be done with decoration not inheritance. You just coupled 2 things together when you only needed an interface and DI redirection. I have a video on how to do this exact thing the clean way. It’s call something like “implementating decoration with scrutor”. Highly recommend it
Funny idea :D
I would have had Interface Segregation in A after Open-Close principle. Not much of a difference.
S is not about class doing one thing, you get it wrong. We already have a principle which say that something should do only one thing, and it is about methods, not class, nothing to do with SOLID. Feel free to investigate what is S =)
Yeah I've read clean architecture as well. The original definition by Rober Martin does actually say that it's supposed to do one thing. He later rephrased that he meant that it should have one reason to change. To me as long as you also follow open-closed those two are exactly the same. If your class is doing one thing then it only has one reason to change and if a class has only one reason to change (and is following open-closed, which it should) then it is only doing one thing. For context this is how Robert Martin originally defined it in his book "Agile Software Development, Principles, Patterns, and Practices": "The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility." =)
@@nickchapsas cool, didn't know that Robert Martin changed his mind xD thanks
Lol, this is a great idea.