Video is wonderful. Please continue with this series for SOLID principles Chris.

Your explanations are long winded, but they are clear and that's why they are really helpful. Thanks.

That's amazing. I am always eager to understand pure concepts rather technology coupled ones. I appreciate your interest in that matter and you are truly killing it. Thank you for your efforts and I hope you continue sharing your great knowledge.

so good to hear from you after long time.! welcome back!

I love all your videos! Thank you so much for taking the time to make them!

Very nice presentation, easy to follow and understand. Thanks for sharing!

Amazing video as usual! I think an interesting thing to point out is that many of these different "software design principles" complement each other, each making use of the others easier and more effective. For instance, preferring to code to interfaces makes adhering to the Liskov Substitution Principle much easier, because there are usually no invariants relating to state. Similarly, interface segregation leads to small interfaces, whose invariants are easier to grasp and enforce. Sharing code through composition rather than inheritance bypasses substitution concerns entirely, since there's no subtyping involved.

The thing is LSP often hides behind something that does not look like a subclass. For example, in Haskell, LSP is an important principle when using lens. This appears strange since Haskell isn't even OOP and lens are just a function from a profunctor to a profunctor. But lens actually has a subtyping hierarchy that has to be respected.

Another excellent video, thanks for making it! ❤

Before I even finish this video-big thank you for the Elegant Objects recommendation in your other video about Always Using Interfaces. I am about halfway through the book, and in conjunction with your content about coupling to abstractions, my understanding and use of OOP has already begun greatly improving the code I write at work.

great piece of knowledge! thank you!

covariance and contravariance are probably one of those things i understand subconsciously but can never seem wrap my head around consciously

This is the first time I've really appreciated the LSP and the implications of violating it. Would be nice to see some patterns to deal with situations where inheritance seems applicable but the LSP would be violated. Using a version of an example you used, say I had a third party class for some collection (i.e. I don't own the code) and I wanted to make an immutable version of it where the Clear method doesn't empty it.

You make this difficult subject easy to understand. Thank you.

Thank you!

Great video, thank u

comment for support! thanks! I'll get back here in 2 years :D after I have learned enough to understand the explication

Sounds more like a quantum physics thing than a software development thing, to be frank. Which is awesome.

Un gustazo escucharte

Wow I never thought Postel's Law is related with LSP. It makes a lot of sense, though!

I wonder here now, if I need a type T which violates the LSP if set as subtype of pre-existing type P, would modifying the hierarchy and changing P to be a subtype of S, and S to be subtype of whatever P was a subtype of (and not violating LSP here), is a good move. For example, make pre-existing List a subtype of newly-created UniqueList.

Can it be worthwhile to apply these principles to interface evolution, when a need for backwards compatibility is desireable. It seems that yes, it could apply.

Lovely! Thanks for this video! I have a question, is a violation of the LP if a method in the subclass accept more parameters (meaning not a bigger range of values of the parameter, but really the number of parameters the method is getting as input) than the method in the superclass?

This seems kind of obvious to me. If B is a subclass of A and “x” is an instance of some subclass of A, and you could have x.fido() calls anywhere, then it would be utter chaos because x could be an instance of B in any of those places and B could have overridden fido to behave so differently that your code can’t know what to expect as a result of x.fido() because it could be anything. If I expect x.fido() to return an array, then an array of objects, or array of ints is fine, but of course you shouldn’t override it to return an object or some struct. And if the arguments given to x.fido() could be any integer, then of course you shouldn’t reject whatever would normally be acceptable to A for that method.

Excellent as always. How soon will you publish your own book?)

nice as always bro , can make technical practice video for this .

Interesting! How would one implement classes such as UniqueList or ImmutableList while still following these principles? It seems so natural to just write a bunch of code for a base List class, and then just make a subclass that inherits this code but adds extra checks (for immutability or uniqueness). How do we do this in other ways?

Thanks for this amazing content. It might be dumb to ask but being a non native english speaker what is this word you are using in a lot of your videos wich sounds like "hirokee" ? Need to know how to spell it to search for the definition 😅

Be a nice guy, and don't expect every one will be a nice guy!

Don't be a trouble maker, and don't fail if you have to work with a trouble maker!

14:33 the same argument could be made when you say same or weaker precondition. If we have a base type of UniqueListBase with a precondition, on the Add method that you cannot add duplicates, and subtype of UniqueListDerived that isnt restricting the uniqueness. That would also be a violation of liskov no? if somewhere down the road, people are using UniqueListDerived as a UniqueList, it might cause them problem

I write code in C#. Technically, if I don't override any base class methods or if I don't use base classes, then I can't violate the LSP. I dont find this to be a particularly useful definition.. In C#, the LSP changes. We talk about implementing interfaces instead of inheriting from super classes. All implementations must correctly implement all methods on the base interface. This means that a method can consist of one line throwing an exception. Some people say that LSP means that you must use the most abstract class in your code and let DI do the work of populating the correct class. There is no value to doing this ALL of the time. Interfaces should only be used when mocking for testing is needed or if you are implementing something like a strategy design pattern. Otherwise, you are increasing the amount of code in your code base for no discernable reason.

If you use composition over inheritance, and DI with interfaces, and not types. You can't violate LSP, because the rules are inherently followed. This is actually one of the reasons that composition is better than inheritance.

😎

Can we have examples?

First one here :)

Liberal is weaker, conservative is stronger. Got it.