Depend on Abstractions not Concretions (Framework)
ฝัง
- เผยแพร่เมื่อ 6 มิ.ย. 2024
- I made this simple framework to explain why and how we should "depend on abstractions and not on concretions". It's a quadrant diagram where the two dimensions captures the principles "program to interfaces, not implementations" and "dependency injection".
🏛️ geni.us/IBhtLnh (Clean Architecture)
🧠 geni.us/CpLx2y (Agile Principles, Patterns, and Practices)
🌟 geni.us/zzlx (Dependency Injection: Principles, Practices, and Patterns)
00:00 Intro
00:14 Overview
00:41 The diagram
02:41 Concretion + Instantiation
05:34 Dependency Injection (Concretion + Injection)
06:36 Program to interfaces (Abstraction + Instantiation)
09:22 Combining both (Abstraction + Injection)
10:01 Book recommendations
10:39 Depend on abstractions (Abstraction + Injection)
Watch next: • Always Use Interfaces
Now THIS is how you teach a complex topic like DIP: energetic, clear, to the point, and with humor. Bravo 👏
Thank you 🙏😊
Your teaching style is optimally concise. I have lightbulb moments with every video I watch from your channel. Bravo!
Wow. Thank you for the kind words. 😊🙏 I'm happy to hear that. Will try my best to keep improving.
Man, I think this video is the best explanation for DIP
Thank you very much for the kind words 😊🙏. To be fair, this video doesn't cover all the intricacies of DIP, but (imho) most of them 😊
That understanding of change in behavior than data, made me get it very clear that the conditional for behavior change in Player is where a subtype polymorphism should be used. I now can read conditionals in a sane way than before where I used to worry about every switch and if statements.
I'm so glad you are making videos again! Thanks
Fantastic demonstration of how these principles are implemented. Thank you!
i love this guy as a tutor :D
Begin from top left and refactor towards bottom right as you need it, otherwise you end up with a lot of unnecessary boilerplate you ain't gonna need (YAGNI), and in some cases even might lift statically detectable errors into the runtime. This is a tooling problem but still happens a lot in real code.
Also if it is the wrong abstraction in the beginning, which new code usually is, you'll end up reinforcing the wrong abstraction early on in the calling code. In the beginning we usually need to switch the big parts of the implementation a couple of times, in which the concretions win every time.
I always start with concrete implementation. I rewrite to abstraction only if necessary. Furthermore I came to a point where I implement requirements driven and not framework driven. At the end it always fulfills a business need. Doesn't solve every problem but it makes some implementations less hard than thinking in patterns first.
Excellent description of the situation!
This is absolute gold, you are really good at teaching ! Thanks
You are the legend.... many Pakistanis and indians are revamping your videos. and contributing to the society to make the object oriented inclusions at the grass root level to lift up naive programmers... You are Great sir.. hats off....
Awesome work. I love getting these notifications.
I am following and learning a lot from your lectures. It is absolutely great and a true joy to follow. Keep it up and thank you very much!
Absolutely amazing contact.
Respect
as usual a great watch and awesome breakdowns
I have never thought these in this framework. Like it. thank you
Im glad you're back
Great video and wonderfully explained!
great explanation!! expecting more videos like this❤️
As a self thought qa engineer I always struggled with truely understanding DIP. I knew it must be great since people put so much emphasis on it and in the case of Unit testing I could see its benefits. But now finally after watching this video I feel like it truelt clicked. My brain really needed to see these 4 quadrants together to truely understand the topic. Thanks
Very happy to hear that. Thank you for sharing these details 😊🙏
Good to see you doing your thing bro ❤
Great content and very neat and clear presentation, keep it up
Thanks a lot! This and the other videos are great. Nice to see more content coming up.
Can be adopted to any OO-Language .... really well done.
Passing lots of data around instead of objects is one of the top topics in ABAP Coding ....
Next up is abstraction of round and using a builder pattern to bring the two concepts together. A factory could build an abstract round (Round robin, randomised round) then assign players to that round ( two or more) that then gets returned to a game coordinator. Maybe even make a round slightly immutable so that after a play it's winner is recorded but never changed and forms part of a linked list to produce a history of rounds to document the game moves...
Absolutely. Around more than 10 years ago, inheritance used to be the way to go. Now, after almost 20 years, it is much too rigid and has massive overhead - and dependencies. Interfaces that are injected by the application engine offers simpler designs. It also allows for much simpler enhancements. Adding an operation that only takes minutes without needing to care much about hard dependencies offers so much more.
Great video. The book Dependency Injection: Principles, Practices, and Patterns is one I've recommended to colleagues. It really digs deep on the topics and helped me supercharge my engineering skills.
Thanks for sharing your experience 😊🙏
Awesome explanation! Thanks a lot
Your teaching style and knowledge is exceptional. Please make some videos about functional programming design patterns.
Thanks for the video. Also, thank you for recommending these books. It really helps the viewer to get deeper in the topic when you mention the resources.
Thank you for the feedback 😊🙏
Loved this, it enlightened me with Dip.
One of the best explanations of Dependency Injection I've ever come across. Thank you.
Glad it was helpful! Thank you for watching 😊🙏
You are just so good at this! Thank you so much!
Thank you for the kind words and for watching 😊🙏
Some of your videos are review for me, some are new ways to look at problems, but I always learn something new and become a better engineer.
Thank you for your work.
I’m very glad to hear. Thank you very much. And thanks to you all for the things that you are teaching me along the way 😊🙏
Can't wait for you to finish your series on SOLID principles.
Next video to drop is a video on LSP. Currently editing. Thank you for commenting and for watching 😊🙏
Yess sir! ❤ Many thanks.
Using abstraction in general great. People shouldn't feel like they should have to build everything from scratch. Using good code already out there will save people a lot of time and effort. I see people who feel like they are bad programmers because they have to use libraries and tools made by others to complete their projects, but there's nothing wrong with not knowing every detail of how the abstraction was created. No one knows everything about programming and everyone has weak spots and stuff we've never worked with before. Just trust that if you need to figure it out, you can, but don't worry about it unless you have to.
Imho I think you are very right and I think that you are raising a very important point. Perhaps I should even make a video on this. Lemme think about it. It's important to me that I don't contribute to causing more stress in the world. Thank you for sharing 😊🙏
Simply the best
My favourite tech youtuber 😍
Awesome 👍
You are amazing, Thank you so much 😍
Brilliant man, I just used Injection and build something with Quad 4, Just didn't know what is the term for the concept!
This is super. Thank you!
And thank you for watching and commenting 😊🙏
Amazing vieo. I can't explaing my satisfaction watching these videos. That's real science.
Well explained
It's funny how I had no idea how all these frameworks are called, but I use them everyday. But I love it how well you presented them. And I finally get it why you would use interfaces :)). Thank you!
I'm very happy to hear that it resonates with the way you are thinking. Thank you for sharing and for watching! 😊🙏
Great video.
Fascinating!
Please record a video of demonstrating this in JavaScript
Wow you are amazing!!
I'm happy it is useful. Thank you for watching 😊🙏
... woah 🤯 great stuff!
🙏🙏
It's a really good video, but 2 question emerges:
A: If its not Round who constructs Player 0 and 1, then who does?
B: If there are multiple strategies to implement a Player then who decide what implementation is used?
Abstraction looks good on paper, but if the base problem is complicated (ex: today's micro-services architecture), then it can only ease the process of creating something, that eventually has to be refactored, for reasons that was not part of the original architecture...
So, sometimes messy is actually good because its easy to adjust, while organized is harder to update because new requirements go against the existing architecture.
To create the objects you will need another pattern, creation pattern, You can use a factory or a builder, the idea now is that the creation of the objects goes to another class and you can abstract it from the code explained in the video., i was expecting him to mention that in the video.
@@JuniorMoreiraC His video "WHY Waterfall Doesn't Work" and "They Knew Waterfall Didn't Work" describes what I mean. So as long as your problem is "Simple" or "Complicated" it's all good to use abstraction. Once the problem in question is more on the "Complex", and "Anarchy" side, I would use minimal or no abstraction. If u manage to tame your problem to "Simple" or "Complicated" that's the point where u can use all that is described above. I know it's a theory video, but I miss this important caveat.
The goal is to achieve design that will be easy to modify and build other features upon.
A "problem" with all the designs shown is that we always treat 2 players instead of a List which would be a pain to refactor if in the future we wanted to have 2v2 rounds for example.
BUT, coding for such flexibility from the beginning might be overengineering! Such flexibility is not easy to work against, and nobody promises you that 2v2 rounds would ever be required.
This is where YAGNI rule comes and the considerations are different in every situation.
In summary: Great video, but beware of overengineering because you can waste weeks on something that... gained almost zero benefits from the abstraction layers you made (Personal Experience)
Yagni is one of my favorite principals.
Everywhere I’ve worked pretty much, there is always too much trying to anticipate future ideas that never happen.
@@khatdubell I know, especially when you are a solo developer working on a personal project. I never worked in the industry before, but I guess when you have a deadline... it will not be so easy to over abstract your code lol
It’d be interesting to hear about the trade off, often times you don’t need unlimited reuse, so the right would offer the greatest ease of usability by end code consumer without them having to know anything about the architecture. Downside code alterations would be painful
Greetings from Germany. I love you!
If you're sure there will be no need for polymorphism as there's only one thing, staying in the upper right corner is fine (IMO).
Your final best solution should probably be using an array of IPlayer because some games can use more than two players. Also, this would allow reuse of some of the code in other applications. Lastly, the Round class is probably converting the players into an array anyway to use array methods to help with looping.
I set the speed at 0.75. But the previous videos about patterns I was consuming at 1.5-2 probably.
I want to hear your thoughts fast as it is, but I need pauses to compare to my experience and digest. I suggest making fast speech and longer pauses between sentences, like, 1-2 sec at least
Ah, good point. Thank you very much for the detailed feedback. Much appreciated 😊🙏
Amazing explanation! TicTacToe in it's elegant way. What are your thoughts about Golang?
I'm happy you find it useful. I have to look deeper into Go to have a proper opinion. Will try to make a video on it when I have explored it much deeper 😊. Thank you for asking 😊🙏.
So what If I want to instantiate classes with constructor based on user input?
Awesome video. Perhaps you speak a bit too fast in the beginning and that may make it a bit difficult to understand the problem.
Anyhow, these are things that I have learned through experience and pain, like having to maintain code which contains lots of conditionals depending on the class subtype, which are clearly bad design smells.
Thanks for explaining these things so well so it's possible to understand and identify them.
Thank youg, great content. But then don't we simply move the instantiation to somewhere else? What if the instantiation logic is based on some calculation that is done deep in this chain?
Great question. Thank you 🙏😊. You are entirely right. We are simply moving the instantiation "outwards" ("upwards") towards the "main entry point" of the application. The point of this is to colocate as much of the instantiation as possible. I.e. in as few places as possible. You are also entirely right that sometimes instantiation requires logic that needs to be performed deeper in the chain at run-time. I will try to address this issue in detail in a future video but the gist of the solution is that we then use factories (Factory Method Pattern or Abstract Factory Method). That would allow us to delay instantiation that need additional run-time information (such as a say a choice from the user about what kind of Player to use in a Round). See what I mean?
@@ChristopherOkhravi Thank you for the detailed answer!
By the way love your teaching style though
each abstraction generates a need for someone to externally provide an implementation at the end of the day. so use them, but do know when to stop.
I find material on DI and abstraction lacking. They never specify that at some point, there *must* be concretions and *something* must manage the concretion's lifetime.
At some point, *something* needs to perform the object construction: of Rounds, Humans, and Computers, and *something* needs to determine which IPlayer concretions are paired with specific Round concretions.
*Something* also needs to decide how to destroy those concretions.
So follow-up question: is it objectively better to always push the responsibility of concretion creation and arrangement "downwards" towards the base of the call stack?
Great question. Thank you 🙏😊 I will try to address this issue in detail in a future video. But the gist of it is: push instantiation "outwards" (btw I would refer to this as "upwards" rather than "downwards" but I can see that we mean the same thing so the wording doesn't really matter here) AND use factories (Factory Method Pattern or Abstract Factory Method) to delay instantiation that need additional run-time information (such as a say a choice from the user about what kind of Round to start. See what I mean?
ahhh shit now i have to refactor a bunch of code thank you (:
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...
The short answer is: in Main and in Factories. The long answer is that i will try to address this in a future video 😊😊 Thank you very much for watching and for asking 😊🙏
I still remember your snake 🐍game. You're cool.
Is this video a programming lesson or a life lesson?
But even after this type of architecture, there is still a place, where the objects have to be created. So instead of solving the problem. Are we in reality not just passing up the problem. In this example it seems as if it solves everything. But lets it was a much bigger system, with many more abstractions wouldn't the problem still exist ?
Yes. Sorry for not being clear enough. We are not removing instantiation. We are pushing it “outwards” so that all instantiation happens in as few places as possible. Thank you very much for watching and for the comment 😊🙏
If you think of a class, temporarily as a variable. It is clear that all variables required to complete a task, must be present and creating the instance of all variables is required.
That said, how your code uses those variables is the "problem" we are examining here.
All instances are likely needed. (Unless it's a mistake)
If you don't tell your depending classes that the parameters they get are of a certain type, but of a "contract" that can do something, but whatever this contract says, is dependent on the actually implementation of said contract, you can pass down many different types of parameters, not just a specific type.
Which is where for example he says player human, is a contract iPlayer and player computer is also.
Now if you want to add player computer easy, player computer average, player computer hard.
You would literally only have to write those concrete implementations. The rest of the system doesn't need to be touched at all.
No tests required for the untouched code. (Only their original tests are required)
You don't have to adapt existing code bases to have a switch for easy, medium or hard)
It's whstever player you instantiated.
Also. There is no duplication of logic. You don't need to revise all the code in your switch cases when you add "extreme" difficulty for example.
your code requires less maintenance.
It is much simpler to write automated tests for.
Any concrete implementation, would use interfaces for dependencies. So no matter your implementation count on an interface, you would only ever need a single set of unit tests for that implementation.
Because everywhere it's used, it's referenced by abstraction(interface)
This means: when you introduce new classes, you only need to touch the "factory" object. Where it is instantiated, and the actual implementation itself. All other written code remains untouched.
When you have low coupling, you have to modify all tests, and all coupled classes when you introduce a new instance.
It's the difference between having to write a multiple of tests pr dependency, to an addition of tests pr dependency.
Your code base becomes much smaller.
You're right that in some sense we're only deferring the problem of instantiation to a different place. But doing this has many benefits. To mention a few:
- the fewer places where your objects get instantiated, the fewer places you need to change when the constructor changes
- when components accept their dependencies as abstract arguments to their constructor, it is easy to customize their behavior and reuse them across the system without having to change their code (or the code of their dependencies)
- when a component has explicit dependencies that it doesn't instantiate itself, the tests for said component become simpler because you don't also have to cover the functionality of the dependencies in the test (you would need to do that if the component is responsible for creating the dependencies)
- when you delegate responsibility for certain tasks to a dependency, your own behavior becomes simpler and more focused
Dependency injection doesn't shield your system from the need to instantiate components, but it does shield your individual components from that need, which makes it much easier to design small, reliable, and reusable components that are easy to test and straightforward to reason about.
I had this exact same question!
What are the cons of "Depend on Abstractions, not Concretions" ?
It can lead to overengineering if you take it too far.
Think of projects where literary every class has a separate interface. Even if there will only be 1 implementation ever.
hi 🤗
Hello 😊
Thank you very much for your videos! Can you please talk a little bit slower? I usually watch your videos at 0,75 speed to be able to keep up.
Thank you very much for letting me know. Will try to figure out a solution that keeps all sides happy. 😊🙏
dude, this is a banned commercial of rust programming language and why to use it. traits and trait bounds in a nutshell.
to fast for me
Thank you for the feedback 🙏😊
Meow
as always with this oop bullshit, no real world examples, only contrived examples, no actual real code, no metrics to tel that this 'framework' is better than any other way of programming.
ew
Thank you very much for the feedback. I appreciate your alternative perspective. Which part of the example is it that you find contrived? I interact a lot with university students and this very much resembles code that I see in real life all the time.
I certainly agree that I’m not presenting any metrics here. It’s merely a tool for those of us who find that organization of ideas is helpful when we’re trying to make sense of different ideas 😊
Thank you for your comment again 😊🙏
This has nothing to do with 'frameworks'. These are concepts that every programmer should understand before using any kind of tools that automates these processes.
Also, these principles are agnostic of every programming language or development platform.
He clearly demonstrates what benefits we get by using Dependency Inversion and Dependency Injection principles. And these should be always taken in consideration when designing softwares, with or without external frameworks.
I understand that watching an use case example written with real code on an IDE could have solved certain doubts like "Where the injection happens?", but I guess this wasn't the aim of the video, and also there isn't a valid answer for each case, but it depends on the use case you are trying to implement.
I think these contents have a lot of value for the coding industry, cause I met too many developers focusing just on using the "right" technology, or framework, or library, without understanding that if you learn these stuffs, you are going to improve your analytic skills for matters of code design that can be used in every context.
Your lack of ability to see potential applications of theory to practice is not a failure of the teacher, its a failure of the student..
You want practical application?
Unit testing.
Try unit testing _anything_ more serious than a wet fart without dependency injection and/or interfaces.
@@khatdubell ah yes, the good old 'i dont have to prove my statements, you have to disprove them'... cause youre feeling entitled today i guess.
and what can't you test without dependency injection ? can you give me an example ?
@@ViolentFury1
"ah yes, the good old 'i dont have to prove my statements, you have to disprove them'."
Not what i said. Allow me to clarify.
I said you don't have the intellect needed to see the benefit. Hope that's clearer. I was just trying to be nice.
"Can you give me an example?"
Yes, yes i can. But i've dealt with your type before. You'll find something to nitpick about it. Something to make a "no true scotsman fallacy".
But here you go, baby bird:
class NotificationManager {
public:
void notifyUser( std::string_view message) {
EmailService emailService;
emailService.sendEmail(userEmail, message);
}
}
Please, explain how you'd test this with this hard-coded hidden dependency.
Oh, wait, i almost forgot, you aren't going to. You're going to find something to nitpick about it to say its an invalid example. _sigh_ , so boring.