The Flaws of Inheritance
Vložit
- čas přidán 15. 05. 2024
- Let's discuss the tradeoffs between Inheritance and Composition
Access to code examples, discord, song names and more at / codeaesthetic
0:00 Introduction
0:25 Inheritance
3:32 Composition
5:22 Abstracting with Inheritance
6:52 Abstracting with Interfaces
8:20 When to use Inheritance
First time I've heard PNG called "ping", hits different
It's the official pronunciation. I don't think I've heard the letters spelled out.
@@eckligt TIL. On Wikipedia, it shows the separate letter pronunciation. Oxford dictionary also shows the individual letters. Everyone I know says the letters individually lol
@@eckligt the opposite is true for me
I've always known it as png since I was a kid and first encountered it. Born in 83 for reference. Also, "gif" is pronounced like the peanut butter "jif". "gib", an old term from gaming that I shan't tell you what it means (we don't want kids changing the meaning) is pronounced with a J sound at the beginning... And that comes from the famous developer that made the word popular.
same, it sounds very strange when the letters aren't pronouced individually
I love the 'real world' examples. Usually I'd see examples like an Animal class or Foo and Bar but these examples make it 'click' easier in my head.
Not a fan of foo and bar. To a beginner, they look like some obscure function or keyword. Animals are a much better subject in this regard. Also don't like "my" classes, something just doesn't sit right with me about them.
@@2bfrank657 I agree the "my" classes aren't very descriptive but one thing i do like about those examples is that they imply they are an identifier, meaning it is named by the programmer rather than being a keyword. Not too useful for any topic outside of the basics, however.
Yeah the problem with those examples they use is that it's only useful to people with the lowest level of understanding. And that level is certainly not where most programmers struggle.
Also the problem you try to solve is to break down complexity. Not just to understand the mechanisms, but why these mechanisms are the best approach. With 'animal' examples you don't hit that type of complexity. And specifically: The biological tree of life does not have the same properties as a good class hierarchy. And prevents good understanding.
Same here. 9/10 articles they make these bare bone, unrealistic examples and call it a day, and I have a hard time then translating it to real world situations.
It's truly unbelievable, in 30 days with 4 videos, 100K subscribers. I have never seen anything like this before. Excellent work, keep going with these small but crucial programming details.
beluga
You have not seen much.
my mans just making equisite videos for a niche audience innit, love of the game my darling
@@henryjobling9178 I did not understand what you said, why?
High-quality, good niche
I've found that tight interfaces with default implementations have provided a really nice balance between minimizing common business logic and preventing tight coupling when you lean on multiple interface implementation. It allows you to mostly lean on composition (implementing the interfaces you care about) while gaining some benefits of inheritance (common methods have a default implementation to reduce code reuse)
agreed - interface -> abstract -> impl has been a winner every time we've needed to scale
You will be big soon, you content is just quality. Keep it up
85k subs in a month is still pr impressive though
Share the video in your social media to help it grow then, stop bragging
@@MaksMikhnevych bragging about what?? stfu
Indeed! It's the only channel that I have activated notifications for.
Frfr
I've been programming for over a decade and these videos explain things I already know or thought I knew in ways that make me question some of my own designs over the years! Thank you very much! I always feel like I come away from your videos with something useful to think about.
As I learn more, I always scold myself for things I've built in the past.
EIther I am too demanding on, and/or too expecting from my subordinates to improve themselves and know all of this, or you lack a lot of knowledge, if you do not design code like in the "good" examples in this video automatically after over a decade of programming. Everybody on my team, even people with less than 3 years of experience, is taught technical architecture through conventions and prepared documentation.
@@Ondraasha What is the point of slamming some random dude praising the video? Also, why do you write 50-word sentences?
Either I am too demanding on, and/or too expecting from my subordinates to improve themselves and know all of this, or you lack a lot of knowledge, if you do not design sentences like me in the "good" previous two sentences I made in this comment automatically after over two or three decades of speaking English. Everybody on my team, even people with less than 3 years of experience, is taught technical sentence structure through conventions and prepared documentation.
Java really popularized inheritance based programming, and it WAS the go-to paradigm for a long time. Only recently has most of us come to terms with its inherent issues. I don't blame people for using inheritance, I've done it myself a lot. The past is the past. Instead we should focus on the future. We will never stop learning and improving unless we give up, and we need to come to terms with that reality that what we did before likely _IS_ flawed.
@@MrMudbill Yes, Java, PHP, and Javascript are the real offenders here teaching hundreds of thousands of developers to stick with OOP Inheritance. Learning and writing Rust, Go, Lisp, and many other languages helps expose people to better ideas.
One of the biggest misconceptions about inheritance is that people think that because the compilation rule is, "This class should have at least these methods", that it is ok to add more __public__ methods to it.
Liskov's Substitution Principal is what you should be keeping in mind when using inheritance. Each subclass should be able to be substituted for another in all use cases without any issue. This means that a subclass should only ever have exactly the same public methods as its parent, no more, no less. This is what makes inheritance powerful because it should then be used with composition to be able to change the behaviour of another class (Dependency Inversion)
Yeah, I think this is something that often gets lost in the composition vs inheritance debate. Like with most practices that go out of favor, I think a lot of the disdain towards inheritance have to do with the misuse of inheritance and people's fear of refactoring code leading to poor choices.
Both composition and inheritance should be used. It's a matter of knowing when to use which one. We should never be afraid of refactoring code.
Liskov substitution principle by no means tells you that child classes shouldn't have more public methods than parent classes.
In game development the most common composition pattern is called an Entity Component System (ECS). You pay a small price in object creation & destruction, but you gain optimal memory access and incredible flexibility!
It’s not immediately applicable to other disciplines of programming, but I’d still highly recommend it to everyone. It’s like the game development version of dependency injection.
Also, virtual function tables are pretty fast in C++
Unity has a Component model and a ECS model, Unreal uses an Actor model
ECS has gained popularity later, and is not a magic silver bullet.
Game Dev is still a heavy OO world (opposed to ECS, which is data driven) where a lot of Inheritance is used along with composition
@@MK-bx8xvit's not about whether vtables are fast or not, one of the main benefits of ECS is that components are sequential in memory, meaning you heavily reduce cache misses and keep your cache full of the data you're going to be processing. It's excellent for quickly and effectively processing lots of elements, and having your data layed out as POD and also sequentially makes multi threading much more convenient to manage.
I would love to see a channel like this explain to the broader community the concepts of SOLID and other principles. So wide is the gap between bad and decent code, and simple strategies to mitigate code smell and technical debt would do many wonders!
May I recommend ArjanCodes? He did just that.
@@3_smh_3 Single Responsibility make code both easier to read and easier to maintain. It reduces decoupling and reduces the opportunity of code smell. By that alone, code can be objectively better.
Open close principle allows for code to be maintained through less need to couple code. Thus, any change to project requirements requires less code refactoring.
Liskov subscription is literally "good adhoc polymorphism". It allows you to do things such as dependency injection.
Interface segregation means clients do not need to require more than the required interface, as seen in this video (though, composition can be better)
Dependency inversion is similar to injection. Except, it is the principle upon relying on the abstraction rather than just moving code to somewhere else.
This is all to say that I VERY much disagree that it is bad to know and employ. It should be second language to a dev, and employed to the appropriate degree in a project.
The problem is that the difference between good and bad code is big and small at the same time.
Big because you need to know how to do it and why, small because you will be typing the same or even less code to get the the results you want.
@@PereViader Code smell is a vast topic indeed, but design principles were coined and employed for a reason. Much like how design patterns were developed to solve common problems. The help reduce the several kinds of code smell and maintain better code.
Edit: oop I misread your words
@@3_smh_3 That's fine. I mean, they're just a collection of best-practices, really. I feal that SRP in SOLID is the most common and enforced, since it follows from basic code habits, such as self-documenting code.
This channel is quickly becoming one of my favorite programming-related channels. I'm sure I'm not the only one who appeciates the clear explanations coupled with beautiful animation - It's like 1brown3blue for programming.
It is called "3blue1brown" lol
any other recommended programming channel you have?
you are too gullible
I'm a firm believer of "Best tool for the Job". I use Inheritance, Dependency Injection, and Interface Composition intermixed in the same code base. It is important to understand that each of these things are just tools that each have pros and cons, and they can all easily cohabitate in the same code base. Saying "don't use inheritance" is an inappropriate hardline, and inheritance has very strong uses. There's also Default Implementation for interfaces that has been introduced in a lot of modern languages over the last few years which has been excellent. It provides a way to leverage interfaces as a way to perform composition without having to do direct inheritance.
Only good reply here. Making DrawableImage inherit Image was just wrong inheritance use.
@@atlantic_love What are you talking about? Learning to use the best tool for the job is like the lesson at the core of software engineering. It is beyond "Useful"
@@atlantic_love Are "Inheritance", "Composition" and "Dependency Injection" the big words? If so, they are "Design Patterns"!. They are a way to structure code following some rules which are supposed to make larg codebases more mantainable and easy to scale, you can learn a lot about them online, and they are used all the time! The names might be complicated, but they are very easy to demistify. Refactoring Guru is a great free resource for example
The OP is making a comment about a general rule: "Composition Over Inheritance" associated with these design patterns (Originally coming from the flus Gang of Four book). And saying how this is commonly repeated outside of this context. Making new programers think inheritance is bad. While, in reality, inheritance is just a tool. And while it might not be the best tool for every job. There are a lot of jobs for which it IS the best tool. Having this knowledge in mind is, in my opinion, VERY useful. Specially for programers new to OOP
@@atlantic_love If you were unable to understand what I am saying, that's completely ok as a novice programmer. I did use a few technical terms, which if you stick with a career in programming you'll come to learn. But it's not nice to say that because I used technical terms in a comment to a technical video that I'm "not saying anything useful". I have a made contradictory argument against his hard-line "Don't use inheritance" stance. If you don't agree with my point of view, that's fine and feel free to express your own opinion on the matter.
@@atlantic_love you either did not watch this video, or did not understand the point they were making. The video makes the argument that inheritance should be entirely avoided due to its flaws. My counter argument is that Inheritance should not be avoided but rather embraced when it makes sense, hence the "best tool for the job". If you're not going to provide any helpful insights or opinions to the conversation, then this entire issue you have with my original comment is moot.
This is by far the best explanation of the topic I’ve ever seen. Not overly complicated, but what’s even more impressive - not unnecessarily dumbed down as well. Fantastic content.
Bro you are a blessing. Your ability to convey the message without extra speech is a gift. Its like every word you say is useful. Thank you 🙏
There is a risk of conflating fine-made delivery with a correct content. Price is paid by ones who fallen under this fallacy.
This channel gives me 3blue1brown vibes and I absolutely dig it! Can't wait for more :)
Very similar aesthetic, and honestly a pretty similar voice/tone/cadence.
Maybe because of the usage of the same library (manim) for creation.
@@aksh1618 did they use the same library for the voice too?
@@wtfzalgo looool
I was thinking the same 👍
The brief animation at 5:44 does such a great job explaining the value of abstracting the contract of relationships between code!
I'm sure this channel will grow exponentially in a few months. I'm happy to be here since the beginning. You are doing an amazing job both in content and visually. Thanks for sharing with us.
This channel never disappoints
how do you know? It's a 10 minutes video and you posted your comment after only 2 minutes since the video was posted
@@i_dont_likevodka3062 they skip n watch in x2 speeed
@@i_dont_likevodka3062 they are talking about the videos this guy uploaded in the past probably
i mean more the topics, I was wondering this the other day and then this pops up in my feed!
This channel don't miss!!!!
This is quickly becoming a top favourite coding channel of mine. The topics are explained wonderfully and I love the visual style. Each of these videos are so easy on the eye, easy to follow, and quick to understand. I think it's because you're to-the-point, you're demonstrating what you're talking about, as you're talking about it; and you demonstrate the importance or usefulness of what you're trying to teach, all in a way that looks beautiful. I look forward to more, they're a joy to watch.
Can you suggest other coding channels?
my first time here. reminds of 3 blue 1 brown quite strongly. (not a bad thing!).
@@eliezra83771 Sure! I recommend Amigoscode, Bro Code, Chris Hawkes, Chris Titus Tech, Code Creative, Codinghase, Computerphile (for Computer Science topics), Continuous Delivery (for Software Engineering topics), DevDuck, Fireship, ForrestKnight, freeCodeCamp, GOTO Conferences (for various talks), Hallden, Keep on Coding, LiveCoder, Mansoor Codes, Missing Semester (very useful!), and NeetCode.
I ran across your channel recently, and I just want to say that it is excellent. I'm really impressed with your presentation of these topics.
I like this professional and visual representation of whatever you are trying to explain, because its really easy to understand
I don't know if you actually read my comment on your video "Abstraction Can Make Your Code Worse", but this is 1) so much better by not making the choice for the viewer, instead clearly stating your opinion and allowing them to come to their own conclusion and 2) an amazing companion video to the discussion around abstraction as a whole. I'm looking forward to the video on Dependency Injection, if for nothing else than because of the great quality of material and informational topics you've covered.
Keep growing, and I look forward to the next topic.
as an artist turn recent programmer I gotta say THANKS. These are so concise, make sense even to me, and are coming at a great time.
Love how the youtube algorithm promotes new fresh channels! I've been watching you since the first video you made and I'm glad you've picked out your niche in this oversaturated field with clear and concrete explanations. You're awesome!!!!!!!!!
Love this channel! This is the exact visual representation and walk through of concepts that all books and articles lack. When are you coming out with that dependency injection video you teased about? Really looking forward to it!
Loving your videos. I've been teaching myself code for a couple of years (while directly deploying my code to prod) and have been trying to get a better grasp as to what the concepts really mean. In a practical sense. You do really well at articulating these concepts in an easy-to-understand way. Can't wait for more.
These videos have been awesome and easy to digest. Please keep it up! I love that you have a pros and cons in all of them as well. Nothing is ever the only answer so breaking this down for people repeatedly is good. I once worked with a guy that was in school part time and anytime he would learn something new, that new thing was the best thing evarrrr and he would start implementing it in code at work without better consideration.
Thank you for this awesome tutorial. I haven't realized how much I needed to hear this to structure my knowledge. I was doing some hotchpotch of both inheritence and composition in my code and didn't really thought about the bigger picture. I'll definitely read about it more, all thanks to this wonderful explanation. Thank you once again!
I just became a Patreon supporter and I'm excited for your future videos. Your videos are on point and your arguments are well thought out. Keep it up!
Four videos and this is already my favorite programming channel. To the point, easy to understand, fair and unbiased analysis, content this good just doesn't exist.
And of course, the response to community feedback. You've done a brilliant job of taking feedback on board and responding to it, literally every complaint I've seen in the comments of your previous videos has been addressed and corrected well in this one.
There's one thing I'm gonna be "that guy" about though, I'm on a 13" laptop screen, and the class diagrams are a bit difficult to read due to their size, maybe would be worth bumping it up a pt or two?
And just as a maybe, at 8:42 you have bracket pairs colorized, it may be useful to have this present throughout the code samples in the video? For those of use interested in looking at the specifics of the code it would make things more readable. Maybe dip the saturation on the colors a bit though if you can, just so it fits more neatly with the editor theme and with the color scheme of the video.
Personally I dislike the colored braces. Making 4 spaces of indentation is already perfectly readable and more colors is distractong
@@griglog1309 I think if the bracket colors were changed to fit in with the code color theme it would be a lot nicer, maybe just desaturated colors so they appear white but when you're looking for it you can see the color.
I think there's a balance between "just make it white" and "colorize bracket pairs" which can work well for everyone.
"To the point, easy to understand, fair and unbiased analysis"
And wrong. This make any sw engineer cringe a lot.
@@alexwtf80 you mean like all the devs who are ditching OOP-first languages in favor of functional ones for the drastic improvements in productivity and efficiency?
Inheritance should be used sparingly when available, and it's trivial if not easier to do pretty much everything without using inheritance.
I think you're confusing now for the 90s.
@@willsterjohnson I have yet to see all those devs. Also, paradigms are tools, you choose the best for your problem, there isn't a universal answer.
At 3:27 the the red class should have a line straight to the green class, I think.. But thanks so much, the way you visualise these concepts is amazing!
Awesome, really good explanation. Thank you so much! I hope there are more videos to come, very high on quality, especially the shapes and form you created to display the logic behind are outstanding.
I’m a huge fan of your videos, and was talking with some coworkers about your “never nesting” video a couple weeks back. Turns out a lot of us had seen it independently haha. You’re getting some great traction!
I've seen class/inheritance coding before in large projects, such as BioPerl. File reading/writing are their own classes. Data storage are another set of classes. Each uses some amount of inheritance to work. For example reading/writing a FASTA file vs a CSV vs Etc... all have a base class to work from and the data held being a Seq, RichSeq, etc... also have their own base class to work from.
What you did in the video mixing reading/writing with the holding/manipulating is what creates the real problems when trying to use classes and inheritance :)
It's pleasant to have these core concept explained with this much quality😌
Best explanation of object composition vs inheritance I have seen so far, great example makes it easy to understand the conceptual differences and pros and cons here. Thanks for a nice video covering this!
Just wanted to say the quality of your videos is visibly improving. I was reading comments from previous videos and seeing how you take criticism and use it is to improve is just great. Keep it up!!!!
I use inheritance a lot when coding guis from scratch. All elements will share some basic functionality (such as having a position on screen, an area, the ability to draw itself, and so on) and as you develop and refine those capabilities, you want your coding to flow down to all the more specialized elements that do the same thing. When you add the ability for the element to recognize that the mouse has hovered over it for long enough to bring up popup boxes, for example, you want every element type you have to learn this ability, so you'd program it into the parent class. I can't even imagine how I'd do this cleanly and quickly without using inheritance.
"I can't even imagine how I'd do this cleanly and quickly without using inheritance"
this is actually one of the problems behind OOP - "to a man with a hammer, everything looks like a nail" : )
Decorator, Strategy, Visitor...? this problem has multiple solutions and battle-tested techniques.
Without inheritance you have a class that consumes a "Position", "Area" and "Drawable" object that does so. Instead of inheriting from a class that has all three behaviours in it interleaved. Actually that is what you call complexity. Otherwise if you want to learn another approach to UI look and learn "Elm".
In a class I just finished, our final project was a 2D arcade game. The class was “Object Oriented programming”, and we used c++. We ran into this problem as we wanted to add features to our characters. We refactored to an Entity/component based system and it was such a relief. Minimal inheritance, mostly aggregation. Inheritance feels like OOP just trying too hard.
suddenly everyone hates inheritance like it’s some guy who shit in their cereal. Can’t we just recognize the best tools for the job and not demonize anything ? Sometimes I wonder...
Ah yeah, projects in uni. We spent days on the fucking class diagram and in the end it still didn't work out as we planned.
@@turolretar I think the reason for that is that many people use inheritance incorrectly, or use it in situations where it shouldn't be used. Just like OOP is often hated. I've seen people hating on OOP and Java and when asked to see their code, they reveal one massive god class with all members public. Of course OOP is bad when done wrong. But to be fair to people hating OOP: in my experience, many books and tutorials on OOP aren't very good at teaching the core principles.
@@turolretar That's the thing with people -- they like and dislike what they're told to like and dislike. As a JS dev, I'm so tired of people praising such and such framework because they heard someone else say it's the best.
@@turolretar The problem with inheritance is that it tries to do code sharing and polymorphism at the same time. There are already great tools that take care of those problems individually - and better. Want to share code between classes? Use composition! Want polymorphism? Use interfaces! Want both? Use both!
I've barely seen any real-world scenario where inheritance is the best option. You're adding a hard-wired dependency to your class for no reason. I find it's easy to paint yourself in a corner when relying on inheritance.
Your channel is definitely in my short list now. I honestly love the content so far. Please keep it up!
Dude this was the video I needed. Have been working on a new code base at work and the architect has introduced an absurd amount of inheritance. I've really struggled working on it and this video has given me the counterpoints / system design ideas to push back a little stronger. Thankyou!
One of my favorite examples on this topic:
Imagine you have a "Person" class, which implements some generic person behaviour. Then you have a "Male" and "Female" class, which both inherit from Person and implement sex specific behaviour. You also have a "Customer" and "Employee" class which also both inherit from Person and implement role specific behaviour. Now the Problem is that you cannot have any of the permutations (MaleCustomer, FemaleCustomer, MaleEmployee, FemaleEmployee) at the same time since its impossible to do this with single-class inheritance.
This comes up quite a lot in many forms and is one of the primary reasons why Composition is often preferred over Inheritance.
What about languages like Python where you can inherit from multiple classes? You could make any permutation that you like.
@@ShaizRevenge This way you're doing double unnecessary coupling just to get around composition.
Rather than considering the MaleCustomer as a single entity (e.g. "a male customer"), it's better to consider it as a intersection of two entities (Male & Customer, "a male that is also a customer").
This way you can also more easily represent unions, such as (Male | Customer, "either a male or a customer"). It gets even more powerful when you can also combine it with intersection (Male | Customer | (Male & Customer), "either a male, customer or a male that is also a customer").
Composition makes this incredibly easy, without the drawback of coupling everything together.
@@dealloc
How you would implement those union and intersection examples without language support for unions/discriminated unions? All I can think of is having a function that takes e.g. a nullable MalenessComponent and a nullable CustomerComponent, checks if one of them is null, and then does something different in each case. But that doesn’t seem like good practice
@@orangeguy5374 Not sure how to ideally represent in languages like Java which lacks algebraic types.
But from what I've found you can represent it in two ways:
On a data level, you could a EnumSet or other way to define all your types of data with a corresponding flag and use its methods to check for intersection/union. Of course this is not ideal, as it would be preferred to have built-in language support.
I also think there are ways to represent intersection types as least with generics, interfaces and constraints. But I am not a Java developer, so I can't speak of how that would be done on a type-level.
I wouldn't overthink it though, because it can quickly result in unnecessary abstractions that makes it all more cumbersome to work with and maintain.
@@dealloc
Actually, I would argue that Java is now a language with almost full support for algebraic types, ever since the addition of sealed classes and records. Funnily enough as Java is seen as the hardcore OOP language with little functional support. Anyway, my question was more about how the idea of composition over inheritance ties into all this. How does composition help you implement algebraic types?
So there are concepts that are either:
1. I understand them well enough already I don't feel especially compelled to continue researching them
or 2. I know they're a gap for me, but I've tried to understand them too much without real payoff, and I've just given up on pursuing those topics.
This channel consistently advances my knowledge in both categories. This video would be an example of the 2nd. Really fantastic work here.
The graphics at 5:46 display your point incredibly well, nice job!!
I love these videos! Your videos explain these topics much better than my CSCI professors ever did. I've been really passionate about using Composition in my game development so I recommended this video to anyone who wants to really understand the concept. Well done! I hope you are able to make more as time goes on!
I did something similar recently where I wrote a trait based rust composition pattern but realized there was a common structure across all implementing classes. I made the code more succinct by creating an "optional inheritance" with its own blanket implementations so for the 99% of implementing classes you can just inherit and get the traits for free and just implement the last trait needed for integration. What makes this optional is that you can just derive the traits that are needed for the framework (requiring implementing the otherwise blanket implementations yourself) and not inherit the "helper" parent class. That way you get the best of both worlds.
Loving the growth of the channel! Keep making these videos!
One note, sometimes it can be hard to tell which lines of code you are referring to when the screen is full of code. Play with ways to focus attention where you want it to be. I found myself having to watch a few segments multiple times to notice everything you were doing onscreen.
Thank you for this. Due to the types of projects I code, I'm constantly struggling with the inheritance refactoring woes you speak of. I have a serious case of imposter syndrome though, and just assumed I was doing it wrong. I've since switched to using the composition method you went over, but wasn't very strong in its fundamentals...and assumed I was doing IT wrong as well (which in some cases, I was). Laying them out like this is exactly what I needed, and you saved me hours of trial and error due to a combination of incorrect assumptions and a lack of a strong foundation.
Seriously, thank you.
This type of videos are like a hole semester of classes in 10 minutes, thanks a lot and keep it up! please!
Holy crap this channel is liquid gold. I'm entirely self taught and have always been a little in the dark when it came to proper abstraction and inheritance. This clears it up soo much! Can't wait for the next upload.
It would be so great to also mention more technical terms for this, like the Dependency Inversion Principle (related to using interfaces), Strategy pattern, etc.. Yeah, you gave a brief explanation of why it is useful, but just throw another bone to the devs who want to find out more about the topic more easily.
As someone who has been trying to understand what inheritance was in the first place for a while, or why it would be used, this video helped me greatly!
and THEN you beautifully describe what composition is as well!
Im so glad i get to be hear from the start. Beautiful visuals, amazing explaination, just great quality.
CZcamss algorithm must be doing something right. I wish you the best in growth and success, its deserves!
Keep it up :)
I saw all your 4 videos today, and I'm sure I will keep watching your content. +1 sub for you!
I haven't seen any info about who you are or where your experience come from, but to me, it looks like you're learning much by yourself, because as far as I know as a self-taught dev, you don't tell people to code the way people learn in school, you tell people to write code that actually makes it easier for everyone to read and understand the code, even for non-devs
I'm used to teach people, help people and learn how to improve my code, and with that experience, content like this makes it so much easier to explain to other people why I write code the way I do, because you literally explain in depth the reason for why my coding style can be so good, which I'm 100% sure is your coding style as well :P
It's worth pointing out that there are a great many different applications of programming, and not all of them lend themselves well to every paradigm. Generally speaking, I think Object Oriented Programming, and inheritance, are very powerful when writing or consuming a library with a public-facing API. The ability to create a set of classes which can be inherited from, and the ability to extend the classes in an API, are quite valuable. But most application code tends to benefit more from a functional or procedural design.
Your channel is so informative with such a clean and good explanations on how to write better code, that I couldn't dream more
I just stumbled upon your channel. It is wonderful to see core design concepts be presented wonderfully. It's amazing content and would make for people becoming better at dev, with such visualisations. Lovely ❤️🌹
A good approach is to use interfaces first, that way you declare what is necessary. Then if you really need inheritance, you can make an abstract parent class that inherits from the interface and contains the boiler plate code you want. This way, not everything that implements the interface also has to inherit all the functionality as well. That can stay restricted only to subclasses where it is actually helpful. Still it is better to avoid this most of the time. Interfaces are fantastic though
One of the better cases for using inheritance is to provide extension points to override behaviour in a class. Using the image example from the video, a TIFF class may provide an extension point to allow additional meta data to be written into the class. Similarly, the PNG and JPG classes may be subsclassed with WaterMarkedPNG and WatermarkedJPG classes....where all behaviour is the same, except when streaming the image. You could do this with composition, but it is far easier with inheritance.
@@jimiscott Yes, easier to implement initially with inheritance, due to less boilerplate. But you trade off flexibility. Consider that some requirements change for the parent classes, but should not change for the subclasses, then you now have an incompatibility, and in an ideal world you would decouple them. But time is money, so you end up patching it by overriding all subclasses to ignore this requirement, or over-abstract the entire thing, ending up with more debt.
We have to consider what would happen in the real world, rather than what is theoretically possible, if we had infinite time to do things.
Of course it could be considered on a case-by-case basis. But sticking with composition will make things much more easily manoeuvrable, even you tradeoff by having to write extra boilerplate.
Inheratance was incredibly useful for me once. The most interesting comment I have heard about it went something like: "My the time you understand enough about the problem to use inheritance, you have already coded the entire thing"
And that is my experience. It is hard to use because it requies a more complete understanding of the problem than we have most of the time, and we don't use it very often, and it is the sorto of technique that even in programming class you will never be given an example of when it is actually useful, instead you will be given a few hypothetically situations where using it is possible but quadruples the amount of work to solve the problem.
Inheritance is the perfect way to solve quite a few problems, but it is not practical 99% of the time.
Very good points. You have to constantly be going back to see what the parent does only to find out that it's that parent's parent that implements something. You have to maintain an awful lot of crap in your head at once.
No. Simply put, inheritance is a powerful tool that needs experience to be used properly. The design described in the video is deeply flawed, it's an antipattern and I would scold if any of my guys do something like that.
Keep the good stuff coming! The editing is wonderful and I enjoy the calmness of these videos ;)
I see that you switched from blurring out the unfocussed portions of the code (as it was in your previous videos) to darken them, as to emphasise the relevant lines that you are discussing. This makes it so much easier to follow your explanations. Thank you for being open minded and listening to your audience's suggestions. Great video, as always.
As with most examples of problems with inheritance/OOP, I feel that the example used here and the particular way that it breaks down is more of a design problem, less of an OOP problem. The three format dependent classes really don't make much sense as subclasses in the first place - why do I care about JpegImage if the only JPEG specific part is how it loads and saves the file? In memory, all the images are the same, so there isn't really a reason for them to not all just be Image. The compositional approach works here, but I would go another direction.
Create an ImageFileHandler class, and give it methods for each type of image. Give the Image class an imageFileHandler, have its save/load methods delegate to this. Technically any image could be saved to any format, so we should go ahead and add a parameter to save to specify the format, and/or include a property the remembers the original format. But for loading, why not just detect the format by file extension.
Now we have an Image class that can load/save images in any format without the user even needing to think about it. New formats can be supported by updating ImageFileHandler and Image doesn't even need to know what the format was!
Alternatively, instead of embedding the file handler inside the Image, a new ImageLoader class could be created, and it would be an Image factory - the load method would return a new Image, and the save method would take an image as an argument.
Precisely, the example was poor.
CZcams recommended this video to me again with no indication that I had already seen it. And I was thinking exactly the same thing I was thinking almost a year ago, scrolled down to comment, only to see that I already had. Very strange feeling.
Great content presentation. I am referring this channel to all present and future junior devs I'm working with. Bang-on about premature optimization and the link to inheritance. The common distinction between a choice of inheritance over composition is the "Is-A" vs. "Has-A" distinction. Inheritance leans towards situations where one thing can be directly and completely represented by a base. The classic dog or cat is-an Animal. Unfortunately these decisions tend to get skewed when your perception starts looking for these optimizations early. It becomes a hammer looking at everything as a nail. I've seen scary situations where things like customers, users, and offices extend a base address type just because they all share an address. This should be a "has-a" relationship, where those classes all "have" an address, Composition. Composition is generally easier and safer to optimize for as you go. Inheritance is an optimization I prefer to encourage as a later re-factoring once the "what" everything should be has had a bit of time to settle. +1 on the grins hearing Pee-En-Gee referred to as "ping" :)
When I was on my coding bootcamp we briefly covered OOP and the topic of composition vs inheritance was something I couldn't get my head around, this was by far the most comprehensive and easiest to understand explanation, quality work and keep up the good stuff!
I wrote an image class just as an exercise about 25 years ago. It was the best lesson on the limitations of inheritance (and templates) I could have ever wished for.
Best upcoming channel ngl
This is like Fireship but with more complex and in-depth videos. Great work!
this is *so much better* than Fireship
can't believe you compared this legend to fireship
@ghost mall like Fireship as in high video production explainers for dev stuff.
Both channels produce good content but serve different needs/functions.
Your videos are unbelievably good-everything about them. Thank you a million times over.
Amazing video! You clearly and elegantly explained a somewhat complicated issue in a very understandable way. The next time I consider using inheritance I will certainly think about the issues you brought up and consider using composition instead.
One additional factor that makes composition preferable to inheritance is in cases where an inheritance tree grows deeper and more complex and you want to share code between two branches that are otherwise unrelated. You may be able to deal with most of those issues with more inheritance, but they will be incredibly convoluted and confusing. In some cases it may be impossible to achieve.
also if you need to change the hierarchy one day (because one of the traits modelled through inheritance will be removed, and some other one will be added).
inheritance hierarchies are notoriously unflexible, so such refactoring will create a powerful domino/ripple effect throughout a codeabse (if it relied on inheritance a lot).
with composition this impact is limited to a minimum.
Composition can grow unmanageable too, if done wrong. Any tool can be abused, but that doesn't make them inherently bad. Try to use a knife as a screwdriver, and it will kind of work, but not well. Try to use a screwdriver to slice bread, and it will perform horribly.
I found that you can't just follow exact rules blindly, programming is too complex for that. The best you can do is having core principles that are vague and contradicting each other. That's why programming hasn't been automated yet.
@@andrasbiro3007 sure. But, in my experience, inheritance is the tool that gets abused the most and most often. And abuse of composition can make code difficult to read and understand. Abuse of inheritance can make certain changes or improvements impossible without what constitutes a complete overhaul.
@@Vendavalez
Difficult to read also means very hard to change. Don't blame the tool, blame the user.
I've been using inheritance extensively for like 35 years, and never ran into big issues.
I refactor the offending code long before it can cause big problems.
@@andrasbiro3007 two questions for you. Are you the only person working with your code base? If the answer is no, now many of those people are juniors?
I've been wanting to learn how you animate your code. Or mainly, how you get highlighted code like this that's also easy to animate.
I know my way around DaVinci Resolve's Fusion but that seems like an imperfect solution for this.
Could you shortly elaborate how you achieve your animation? That would be a great help in my learning efforts and might get me back into making some programming videos again :).
Thanks a lot and please keep on delivering such quality content.
Dude, you just transformed something that is so hard to grasp into something so much fun to learn, well done 👍
Loving the content so far. no one ever explained me the idea of composition and dependency injection in such simple way.
Yep dependency injection and interfaces are a great solution. But it's worth noting that more strategies exist.
C# has also extension methods, which are basically static methods, but used with a notation of actual methods.
And the Rust language has a very interesting typing system which is based on so called traits, really worth to learn about.
But if I choose to use inheritance, I will do it only in the same project for a small set of classes, but not for public library code.
And only just a single base class, expecially no deep interitance trees. Keep it simple.
Last note, methods in C# are sealed by default (you cannot even use that keyword). This differs from Java.
But you can make your classes sealed as well, but which is not by default by the language and which is a very good practice to do by yourself.
It’s strange talking about composition without dependency injection. My understanding of composition is that objects are ‘composed’ of other objects/interfaces. This allows for more straightforward initialization, maintenance, testing and extensibility (among other things)
Your first example of composition, a common class was passed to the signature of a method of three independent classes, which to my understanding, isn’t composition (correct me if I’m wrong)
It almost seemed a bit backwards where if you wanted a compositionally alternative to your inheritance example, you’d have an image class with with an image processor interface in it. From there you’d have an image processor for jpg, bitmap, etc… (not saying I like this way better than your way)
But your second example of composition with interfaces aligns better with my understanding. Again, correct me if I’m wrong. I could be too dependency injection brained and can’t remember alternative ways to build compositionally
Id argue it's still composition, but you end up composing on the method level rather than the class level, which might or might not be preferable
I think the example of inheritance was weakly designed on purpose, in order to refactor it cleanly; the initial concrete class has too many responsibilities.
The first example of composition @4:33 may be a bit misleading : there is NO composition between JpgImage and Image because their lifetimes are unrelated. In a true composition, one class have the responsibility to destroy the other when it's destroyed itself. Here it's a simple Dependency, JpgImage uses Image, but Image is not a structural part of ImageJpg or vice versa so it's not an Aggregation.
In the second example of "composition" @4:50, there IS an Aggregation between ImageDraw and Image, ImageDraw has an Image as a part of its structure. However there is no indication about their respective lifetimes. So we should not say it's a Composition as per the UML definition, but it's close enough for the purpose of the video.
Even if we push an Image in the constructor of ImageDraw, it is NOT dependency injection. The purpose of dependency injection is not to build a composite object, it is to inject an interface (instead of a concrete class) into another class in order to cut the dependencies over a specific implementation, and to facilitate testing (using mocks instead of an actual database, a physical file, or a webservice for example); nice example of DI @8:01
Usually composition refers to an entity having an array of components which makes the entity agnostic to its own properties. Only external systems would be able to work on each individual component of the entity, hence we have composition since you can define a male/female as components of the composition and have them accessed only by the "sex" behavior systems
This is not what I'm thinking of when I hear composition either, to my ears this sounds more like the kind of service-oriented programming that is popular today (for good reason - it's good). Composition as I recall it tends to suffer from the fact that the composed class may need to restate all the desired methods, with the body of the restated method simply calling the method on the property which implements the desired functionality.
Even the wikipedia article on on this ( en.wikipedia.org/wiki/Composition_over_inheritance ) states:
"Composition over inheritance (or composite reuse principle) in object-oriented programming (OOP) is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class."
@@airen2 Only way for true composition is 180 degree turn away from OOP into the unknown lands of DOP (Data Oriented)
THANK YOU, I've been trying to wrap my head around this principle, and you explained it so well!
I have been really confused by how to implement Interfaces basically since I started learning about them. Thank you for explaining this in a way I can finally understand!
This is perfect, I'm loving the Oriented Object Programming series.
Are you planning running through other topics like Data Oriented Design or Functional programming?
I, too, would love to see videos on data-oriented design and functional programming.
I just finished a software engineering course where this was taught. It is crazy how much of a difference production quality and passion about a subject make in understanding.
I love the way you showed code as you explained the concepts, how its used, and where it gets stuck. Very nice. Saying the alternative has problems isn't a great sales pitch for using that alternative. It just leaves people wondering what they should use.
It's not suppose to be a sales pitch. Both of the ways should be used correctly when needed. It's just depends on the need
Great videos where everything is explained with examples and reasons. Subscribed the channel after watching the first video I was recommended by CZcams, didn't disappoint. 🔥🔥
such quality in your content.
This definitely qualifies as codeporn.
Keep up the awesome work.
Even though you don't have many videos they are really high quality and explains the different coding concepts very well.
From last time you uploaded the previous video until this one, every day I check my notifications maybe you posted a new one!!
Keep it up 🙏💯
Bro.. I dedicated my life to learning and dev since I was 8, and I gotta say you’ve got such a finessed approach that is easy to digest and retain simultaneously. Well done, my friend, well freaking done!🎉
You still inherit base class for BmpImage in 4:44. Also I think t's kind of weird "in between" way to implement this - holding path as property while passing Image by reference, and mutating Image during load. I would personally either make these classes completely stateless ( void save(Image image, string path), Image load(string path) ), or also hold ownership of Image as class member. Nevertheless, concept by itself is exceptionally explained - great job!
Then it starts to become closer to the better pattern, which is to go Functional.
Could you elaborate on why clean relational DB schemas are bad for scaling and why you switched to NoSQL to fix that?
They're not bad, it's just the common trap many devs fall into when it comes to "WORKS AT SCALE". Relational DBs can be scaled and run as nodes just like NoSQL DBs. The thing that truly puzzles me is that some popular NoSQL DBs have terrible transaction handling which should make devs terrified of using them in production, but people don't think of that.
20 years of developing software and my first video I've watched from your channel. Instant sub. Great work! 👍
Adding english subtitles to your video is a really really good idea, already written subtitles can be easily translated automatically by CZcams, letting me understand completely this video in my native language ! excellent ! And excellent videos btw, this is helping so much as I'm a beginner !
I find that functional-inspired programming is by far the most aesthetic code I've ever seen. Would you be able to create a video on that subject?
One thing that puts me on "inheritance always sucks" side is many times you'll have multiple shared behaviors which don't align with any hierarchical structure. A child class cannot inherit from multiple parents, but it can inherit from multiple interfaces (typeclasses, traits, etc.). A quick example:
Let's say you have three classes: Bike, Car, Helicopter. Bikes and Cars have wheels, and Helicopters and Cars have baggage holds. You want to write methods that handle baggage holds (put stuff in and out) and wheels (rotate them, count them, etc.). It is impossible to create appropriate parent classes for this purpose - you would have to have a parent class for Bikes and Cars to inherit from, and one for Helicopters and Cars to inherit from, which is impossible with classes (because Car inherits twice) but not interfaces.
You can't make a parent class that encompasses all those behaviors either, because then it would have to have useless functions for some of those subclasses and throw errors/panic/etc. when you call them. Because this structure is not hierarchical, where bigger concept contains smaller concepts, but instead you have concepts that overlap for some thing and don't for others and structure is disjoint, inheritance is completely inadequate to handle this scenario, even though it's fairly simple.
If we'd learned anything from database programming, most things are linked chaotically and not at all in a hierarchical structure. Your data structures can share traits with many other data structures that don't contain it or aren't contained within it. This is why I like that Rust has no inheritance for structs - if you want shared behavior, use traits to describe it. This allows Rust to describe shared behavior even for built-in types, where a lot of them are composed of various combinations of traits.
I feel like, in this instance, it would probably be best to make a Wheel class and a BaggageHold class, then make those members of the Bike, Car, and Helicopter classes, accessible with car.wheels or helicopter.baggageHold. However, some languages have multiple inheritance or mixins which could also be used to solve the problem
"a child class cannot inherit from multiple parents" - in C++ or Python it can.
@@-Jakob- Yes, and that causes its own problems.
@@michaelmounteney2034 yeah I don't use it, more confusing than it helps.
@@tomysshadow Sure, but that's composition. And imagine you can't do that, let's say you have wheels and axels. Both rotate, so you have to make a stupid class RotatingThing, that defines a method rotate(). But wait, that's basically an interface
Subscribed. Video was comprehensive and comprehendible. Helped me realize something I haven’t formally seen before. Thank you!
I need more content! I find these videos highly relatable, useful and almost therapeutic.
I was a little concerned you wouldn't mention any of the cons of composition at all, but you eventually did, although its likely late enough in the video where a lot of people wouldn't have seen it.
Particularly with large scale projects, inheritance becomes much more important, as you alluded to in your pros and cons list.
I don't think I've ever heard anyone pronounce PNG as 'ping', and honestly I was happy keeping it that way
I don't think I've heard anyone pronounce any other way than "ping".
@@eckligt it's PNG, you pronounce it letter by letter.
Edit: maybe it isn't
@@jbritain According to en.wikipedia.org/wiki/Portable_Network_Graphics you're wrong, and actually even according to libpng and w3c (source 2 and 3 in the footnotes on that Wikipedia page) you are also wrong.
If you're gonna be assertive, at least be correct.
@@eckligt I mean the creator of the gif format pronounces his own format incorrectly 😉
The "official pronunciation" of PNG honestly looks like a nod to the intended/proposed name "PING" to be a recursive acronym to mean "PING is not GIF", though that's only recursive if the name remained as "PING", which it didn't; it ended up being named "PNG" which SHOULD come with its own pronunciation. I imagine it stuck since without a vowel to make it feel like a "word" like JPEG or GIF they wanted a way for people to say it quickly and easily but in a world where people just read "png" on their screens we see that's not the case.
Language is supposed to evolve, and that evolution often follows the colloquial path.
@@eckligt I stand corrected!
Incredibly narrated, Legitimately the best I've come across !! Looking forward to more videos :)
Thanks for illuminating this topic in depth. I'm just at this point of my career, where I'm starting to grasp Encapsulation, Inheritance, Polymorphism for real and had some trouble finding a good explanation for this circumstance.
Thank you so much for this content!
Minimalist design with great explanation on important topics.
Please continue, like and subscribe guys :)
🎯 Key Takeaways for quick navigation:
00:00 🔍 Composition and inheritance both aim to reuse code, but inheritance can lead to coupling issues and inflexibility when changing code.
02:20 🔄 Inheritance can force unnecessary methods on subclasses, leading to awkward workarounds.
03:56 🤝 Composition allows code reuse without forcing a common parent class, providing more flexibility.
05:02 📜 Inheritance creates abstractions by sharing a common contract, while composition relies on interfaces to define contracts more minimally.
07:47 💉 Dependency injection involves passing interfaces for flexible class interactions.
08:50 🧩 Composition reduces friction between objects, making code changes easier, while inheritance might be suitable for highly repetitive code in existing systems.
Made with HARPA AI
this channel is pure gold, thank you and keep up the great work!
This guy deserves the best.
Many people teach beginners how to code, but only masters teach experienced how to code correctly.