SOLID IS OLD!! - Dependency Inversion Principle

SOLID Principles are the core principles of Object-Oriented Design. Buy SOLID is OLD! Get it?
O, L, D are essentially Polymorphism. I’ve removed S and I and used it as “IS”. But SOLID is fact OLD, in that not only is this not new. But I think we need to move past SOLID, primarily because of the issues with SOLID. In this video, I tell you why I think that is, and the issues I have with SOLID. But there is also something VERY important that’s missing.
Sample Visual Studio APS.NET Core Web API solution
github.com/matlus/MovieServic...

[@esmaelmohamed8209]

Well Done Shiv!! Long live life for you and all around you!!!

[@itsnotjustcode2255]

This was great, Shiv. Really interesting to hear your perspective of the demystification of old/"common practice" concepts.

[@Matlus]

Thank you for writing in and letting me know!

[@stephenstout7246]

You had me at "old, it is". Nice intro.

[@VinuP2023]

Thank you Shiv. As always, you explanation is top notch. 🙏😊

[@Matlus]

Thank you Vinay! 🙏. Glad you liked it.

[@softwarearchitecturematter4482]

Hi Shiv Very nice channel. You have very high quality videos and topics are great. Thank you, Vikas

[@RondellKB]

Love this video, especially the part about a room of professionals all having different ideas and implementations when it comes to these principles. As someone trying to learn software design, I come across that exact thing very often online, and it always devolves into flame wars. The definitions for the letters are far too vague and this sometimes leads to wildly different interpretations, especially the Single Responsibility Principle.

[@Matlus]

Your experience is the same as mine then. And I've been learning software for over 22 years! Nothing has changed apparently :).

[@RondellKB]

@@Matlus That just goes to show, people will always be the same, no matter the era. Mike Tyson said, "What we learn from history is that we don't learn from history".

[@informetica7394]

Thanks Shiv . Amazing explaination.

[@josiahtobas9172]

I must say that your emphasis on Abstraction has increased my understanding of it's importance and the part it plays in the construction of elements within a software system. It caused me to think more about the the basis for building any element of a software system (high level details) be it a method or a class rather than mostly following the concrete guidelines that most people put out there for developers follow (low level details). My point is: besides understanding the fundamental concept of buidling meaningful Relationships between classes. So that actual work coordination can be achieved. It's fundamental "sidekick" (if you will) is Abstraction building. These two concepts is what i have just come to understand are the main driving forces behind building successful software systems. (This from watching only the first 41 mins of your podcast.) Everything else such as: relationship types, rules of thumb etc. are just ways to refine the software system so that the it's domain model is properly aligned both in the diagramming stage (planning stage) and within the code and that it fulfils client expectations. Thanks alot bty. What say ye?

[@Matlus]

Thank you for your long and we'll thought out comment Josiah! Also impressed that you seems to have definitely got they key points and importance of abstraction I've been attempting to convey across these videos. Yes Abstract is almost more important than anything else. It's like the key ingredient I talk about. If you get it wrong, nothing else will be right.

[@josiahtobas9172]

@@Matlus Thank you, so guess what... I'm currently on a journey now to understanding the art of Abstraction Building 🙏🏿. And thanks for assessment it is greatly appreciated.

[@Matlus]

I'm impressed! I wish now of us went on that journey

[@artiomciobanu498]

On 13:00 when you start commenting the definitions, everyone should understand that they are too formal. They are like written by mathematicians (why "like"? It is almost true). So you can thing he's repeating the same thing, but he's not. These sentences are similar, but specifying details about different aspects, which should just be formally defined. I think it's the biggest problem while trying to understand SOLID principles - you always think they are the same or there's nothing new. Until you finally get the point. When I explain them to my friends/colleagues they are like:"Oh now it makes sense!" Actually there are lots of similar definitions regarding any domain: music, physics, psychology. When you try to define something as precise as possible, you will come up with similar definitions.

[@WilliamWoodAZ]

@shiv - another great one! I may be the only one but I'd love it if these were available on a podcast platform so I could listen on the go without KZbin. just an idea. Thanks!

[@Matlus]

Hi William, thank you! Glad you enjoyed it. I do plan to simultaneously publish the audio to various podcast sites in the future. Just need to get organized a bit.

[@gmedia7041]

Thanks for touching a tabu subject on programming community. Never understood open close principal, seems weird to extend classes just for modifications sake, and this seems to colides with liskov. The S and I seems ok to me, but not something to make so much drama. Dependency Inversion is the only one that needed this clarification. thanks a lot Just one thing: Solid was introduced in 2000 not the 70s

[@rossthemusicandguitarteacher]

Great video, thanks. It makes me realize that I am doing this correctly, but I might be doing it too much.

[@Matlus]

Thank you Ross. >but I might be doing it too much It takes many years of experience and introspection to realize and admit Ross! So you're definitely on the right track.

[@hamoudrodriguez2702]

Awesome explanation! Thanks

[@Matlus]

Thank you Hamoud! Glad you liked it

[@mustafaelshobaky6881]

Thank you for clarifying abstractions. It's far more important than SOLID. Understanding this made me a better developer.

[@Matlus]

Thank you Mustafa! Yes, as you know, I agree. The missing ingredient is knowing how to arrive at the right abstraction. Not necessarily to do the abstraction (abstract base class or interface) right away the class you're using should have the correct public surface (interface) so that if/when the time comes you can either re-write the implementation or if need be, define an ancestor (abstract base class) or an interface and then have multiple implementations if you have a need to support multiple implementations in production.

[@schwamm1996kopf]

Hi Shiv, I have a question: Let's say I have a "PersonManager" class in the domain layer with an "Person" object (which belongs to the domain layer). If this PersonManager calls a PersonDataManager in the data layer, would the PersonDataManager return a "Person" object or a "PersonDataAccessLayer" Object? If I understood you correctly, it should return a "Person" object and the domain layer should have no knowledge of the data layers models (otherwise it would be a leaking abstraction). Am i correct with this assumption? If yes, how is this possible, assuming the data layer and the domain layer are in two different assemblies? The domain layer needs to have a reference to the data layer, so the mapping needs to happen in the "PersonManager" class in the domain layer. But if that's the case, the domain layer would know of the "PersonDataAccessLayer" object.

[@pawanranawat]

Nicely explained 👌

[@Matlus]

Thank you Pawan!

[@trongphan6197]

32:40 the second Domain Facade: should it be Data Facade?

[@Matlus]

Yes, it should be. Thank you for asking at for not blindly following without thinking.

[@rossthemusicandguitarteacher]

D was the hardest one for me to understand, and it is the one that I am always the most aware of when I design my solutions. But I am self-taught so I might have it wrong still haha

[@Matlus]

I hope this video has helped "D"mistify things for you Ross. If there is something that you'd like further explanation on, please do ask.

[@rossthemusicandguitarteacher]

@@Matlus it did for sure! I would be interested in how you set up your facade entry point class. Right now, I am using UseCase classes that call classes in my inner business logic layer. My domain therefore has two layers, Core with UseCase above it.

[@Matlus]

@@rossthemusicandguitarteacher Glad to hear Ross. Ok, I have a sample ASP.NET Core Web API application with unit tests, database etc. On my GitHub. at GitHub.com/matlus/movieserviceyoutube

[@rossthemusicandguitarteacher]

@@Matlus Nice I am going to dig through it thanks!

[@PramodChoudhari]

Your voice ❤️

[@Matlus]

Thank you Pramod! How about the video?

[@BryonLape]

Polymorphism has its origins in the 60's, with a few implementations by 1970. This is years before Liskov.

[@Matlus]

Really? I wasn't aware. Liskov wasn't even talking about objects as we know them. Where did you learn about this? Any link?

[@johanlarsson9805]

Good job keeping it together while talking that much about "the D".

[@vaibhavbrid2133]

I do see developers claim they have designed their code using SOLID. Instead you should be able to validate that your initial design does closely follow SOLID. As you said it is all about good design. At the end when everything is said and implemented, it all comes down to is your code understandable, readable and maintainable. If you are not able to write unit tests easily - STOP. That right there is the first indicator your code design is bad.

[@Matlus]

I agree with almost everything you're saying :). I don't believe the inability to unit test is an indicator of bad design. Just like I don't believe the ability to be able to unit test is an indicator of good design.

[@fleedum]

Subscribed because you seem to know what you're talking about but this video is a bit long, I might be old when I finish.

[@Matlus]

Thank you for subscribing. Yes, this one is a bit long. I could have left it after I explained it using the slide, but I had to get to the "missing ingredient". I could have broken it into 2 parts, but either way it's long. Do you you finish the video though, you'll find you're wiser but not older :)

[@fleedum]

@@Matlus I'll try my best, since you put in the effort!

[@Matlus]

@@fleedum Thank you. I'm sure you'll find it is time well spent :)

[@johnnyserup5500]

Why did I dislike this video? well, I could try to explain it to you, but I am not sure you would understand it - get it?