Відео

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

Your explanation is lit ❤ I read the book explanation after your video and it made so much sense! You made it so easy ;)

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

Here's my invariant: sometimes I'd like to give a bigger thumbs-up than others. This is a good lesson! Worth re-uploading the corrected version, good stuff, can recommend.

How many attempts at the orange juggle before camera perfect? 😄

Bro I been saying this for years, no way.

I have cracked Low Level Design interviews in companies like Microsoft, Amazon, Atlassian, Flipkart, etc with the help of your videos. Your videos are really helpful. Keep up the good work.

2024, saving lives.

Liberal is weaker, conservative is stronger. Got it.

Greetings from Germany. I love you!

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!

Pure Majic in Explanation !! Didn't realise the time while watching it and it seems like just now started.Thankyou for such good content!

😎

You can also find a lot of information about the problem of subtyping if you look up "Circle-ellipse problem".

The first Design Patterns Series that really simplifies and doesn't overcomplicates the basics! You're the best, keep up with the channel please!

great piece of knowledge! thank you!

Great video, thank u

Your content is amazing. Great stuff

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.

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

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

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

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

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.

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

Thank you!

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

Can we have examples?

Great explanation indeed, but the remaining question is: When will you instantiate the objects? This has to happen somewhere, right? One cannot have infinite levels of abstraction...

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.

Bag of fruit has apples, bananas, grapes, oranges.....

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

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

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 😅

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?

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.

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?

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

First one here :)

I love lean

An enlightening reading is smalltak objects and design by chaimond liu, chapter 17. The problem with class inheritance is that it allows method overrides, which in practice violate LSP. If the instances are read-only you don't override get/set and LSP is satisfied

I think this MUDA concept will have very big acceptance in Serbia.

😎

😎

i have never read the original paper but to my humble understanding, Waterfall makes sense in projects where requirements are basically "given" from the beginning and can't be changed without deep analysis e.g. in military applications etc.

Such a MasterPiece it is !!!! Awesome Explanation

Awesome explanation

One of my favourite resources to learn OOP.