You have to realize that not every problem has opportunities for eliminating repeating, and planning out your programs meticulously is often more work than just jumping into coding.
composition(embedding) + interfaces > implementation_inheritance This is how "inheritance" is done in the Go language. You compose your object out of other objects using the embedding syntax, which makes you "inherit" the methods, and you use interfaces to deal with polymorphism.
I guess inheritance can give the programmer a compact, clever solution to a problem. But the minute the problem changes, it can be a pain and a new clever solution must be obtained, but doing so, requires understanding the entire problem, which requires a lot more work.
Can be solved with SOLID principles . If you inherit only the basic interface that would always apply for any sort of group of problems that the program is intended to deal with, then you can just comment out the function and uncomment a bunch of different ones that will inherit to the interface and solve the given problem. If the parent class is the wrong class for the problem and SOLID principles are followed, then it's the project manager's fault for not understanding the full scope of possible problems, not really that of the programmer.
+Michael Lewis No it's a fault of inheritance. It removes the modularity from your code and makes it increasingly difficult to change the more it is used. Because in the example what is the solution now that they know the problem? It's either to remove the inheritance or change all the associated code. This wouldn't be necesary if inheritance wasn't employed to begin with.
+Sander No, it's a fault of both poor communication and bad project management. It doesn't have to decrease modularity, either. In fact, if used properly, inheritance increases modularity. Inheritance allows you to have modules that build on other modules instead of rewriting the same code over and over again in every module. The problem here was two-fold. First, the guy who made the changes was unaware of the flow of logic that the guy who wrote it was using to structure his code. This is where properly documenting your code and using comments becomes essential when writing collaboratively. I have objects that I have written where the number of lines of comments documenting how it fits into the program as a whole are several times that of the number of lines of executable code. The second failure was that the second writer who made changes without consulting with or even notifying the original writer. The exact same problem can occur when somebody rewrites a function you are trying to call in a program. Even something simple like changing the order in which variables are passed or adding an input value for increased functionality with an unexpected default constructor that changes the output of the function can royally pwn anybody trying to use that function. You also see similar problems in modular operating systems when a software dependency is significantly changed in an update. That's why often times a dependency will be listed as = instead of >= in a Linux package manager or a distribution will wait to push an update until there is also an update for another package the update breaks. The solution in this case is to write the base modules correctly to begin with and if there are problems or changes to be made, to communicate those problems and seek input before making changes to somebody else's code so that the original writer doesn't try to take advantage of functionality they wrote into it that you changed or removed. After the fact, you have to either rewrite the lone child class that failed due to the changes in the parent or rewrite the parent to accommodate the child.
+Jason Nichols "In fact, if used properly, inheritance increases modularity. Inheritance allows you to have modules that build on other modules instead of rewriting the same code over and over again in every module. " Having code build on other code is exactly what modularity isn't. " I have objects that I have written where the number of lines of comments documenting how it fits into the program as a whole are several times that of the number of lines of executable code." Yeah that's not good. Objects shouldn't be written to fit into the entire program as a whole. This because that literally destroys modularity. The objects should be completely oblivious as to how they fit in the entire program. The program should know how to interface with the object not the other way round. "The second failure was that the second writer who made changes without consulting with or even notifying the original writer." This I agree with. "The solution in this case is to write the base modules correctly to begin with " This is not really a solution is it? "The best way to do something correctly is by not making mistakes." 10/10 advice. And trying to always write base modules 100% correctly the first time means you are losing the ability to quickly develop software. It's oftentimes a lot better to work towards a prototype so the person you are developing for can give feedback, since quite often they don't know exactly what they want the first time. In any case I don't necesarily want to start a discussion, inheritance has its uses, but its use, to me, solely applies when you are using source code. Like extending a base Activity-class in Android. This because this is the only code in your project that can be expected to not change within the duration of the project.
The entire time I was watching this I was thinking "But that's what interfaces are for..." I was super glad when I heard you say that because so many people would have just shat on OOP and didn't mention the proper way of doing it. I will say this about speed improvements and what my philosophy is behind it. Recently I had to write a program that has to take 20k+ strings in as data points and lay them out into a grid and do some formatting on them. There were a few ways to do this, I could have A: Pulled in each string and ran a loop to place all the data points. This would have been by far the slowest, taking 10-20x the amount of time as B: Since the datapoints already output into a grid, I could just copy every cell at once and move them into the new cells with the formatting. Or C: Perform the formatting on the datapoints in their original cell which would have been the fastest conversion. Option D: Would be to pull in the formatting choices from the file and apply them to the data cells. I went with option B and here's why. Option A would have taken far too much time because of the amount of time to perform every operation on each cell would be equal to the amount of cells in that particular data file. If A processor can perform a few billion operations per second this may not seem like much, but given that I have to have the loop jump back to start and perform the checking and move all the data into a temporary place, it would have made the program much slower. Option C seems like the way to go, but there is a different problem with this one, that being, if there needs to be a change to the formatting it has to be hard coded in. This means that in the future any updates will make the people who are using the program have to submit their changes to me or some other programmer, and then we will take more time to program than adjusting a predetermined template (In this case an .xlsx file) . Option D may seem like it would be faster than option B, and very well could be. However, this would make it so that I would have to search the file for any changes and the come up with the logic to apply that formatting properly, and that logic would be very sketchy and prone to breaking. So while Option B is about half as quick as Option C, and slightly slower than Option D if its done properly, C isn't as universal of a solution and will require more frequent updates, and while it's twice as fast as B it will take more time to update and waste company resources. Option D is less stable than B, so unless high precision and speed are required its better to choose option B. Basically, the best price per performance ratio that can get the job done on a logarithmic scale of diminishing returns. Edit: I also did a million data point test of my program on my laptop with a 500GB WD Blue SSD and the processor is a 7th Gen Core I5 with a 1050Ti GPU which has 4GB GDDR5, and System Ram is 8GB, 2400MHz, DDR4. It took less than 5 seconds to perform the operation.
I agree with you. Some months ago I learned it by the hard way. Inheritance sometimes is helpful, but if the specs change can lead you to lose a lot of time, and to write spaggueti code if there is no time for adapting the domain.
No. Instances of classes are clasess at compile-time. They might construct objects on run-time. An object is not its constructor semantic, an object is an entity in memory.
Funny story. :) This is the problem of code synchronization, which you should avoid by all means. It doesn't happen only in inheritance but also in duplicated code. All code should be written so that it doesn't depend on other code, as much as possible. If code is written so that when you change it you have to change also other code, and compiler doesn't warn you about that, then that is bad coding practice.
Composition always came naturally to me, even without knowing I was doing composition. Inheritance just didn't make much sense to me, except in some very edge cases, which I have used mostly with abstract classes to provide common functionality, but now that I think about it, it could be refactored to composition. It just made more sense to inject an object into another to have that extra functionality, because most of the times, they are used in different contexts.
Inheritance can be problematic, but probably because the designers of the base object didn't think too carefully about what parts to expose to other classes (remember, a private method can't be accessed by subclasses, only by the base class). All too often I think people tend to make too many things protected instead of private and if you do that, then you must be extremely careful about altering code that uses protected members, because any of your subclasses may be manipulating that in ways you may not be expecting. The less you expose to the user or subclasses, the better.
Back in the 90's when I was doing a lot of C++ in projects I used a lot of inheritance and base classes. I never really had much trouble with breaking my code because I tended to really think through the inheritance design. A couple of rules I used were: 1) Don't change what you've already build. Add to it. Especially if your sharing code. 2) Overload the methods if you need something different, or just create additional methods. I agree that anymore it's not such a great way to build things, but I had a lot of fun with it at the time, and the enjoyable challenge of good inheritance is well thought out architecture. Build it right, and extending the functionality in an easy to use way not only worked well, but hid the complexity of the lower levels to your extension classes. At the time I was doing a lot of work with various communication drivers utilizing protocols and hardware layers. Not the only way to skin a cat, but I did enjoy it.
Both of your points 1) and 2) suggest that you shouldn't change anything that you have already written. To me that indicates that the code written in such a way is brittle, hence why you suggest not changing the code. Speaking from my experience, when I can't come in and tweak the design, refactor old code, get rid of dead code; that leads to code bloat as you are always adding but never cutting and productivity drops like crazy later on. Please do take my comment with a grain of salt, because I work on games with 1-4 man teams.
Yeah, I get what you're saying, but I don't agree with this kind of 'broad brush' way of describing the issues. This is part of my issue with this kind of comment, first by Stefan, and by you. It's too general to be meaningful. The fact is that All frameworks and structures have an architecture that you must respect when adding or making changes to the structure. So talking about old code, dead code, etc. is just generalizations, buzzwords, that are nebulous and don't mean much when it comes down to doing the work. You can't just change things willy in any code that you're going to build on. You have to understand what you're doing. The reality is a well build base class and inheritance system can save an incredible about of time. It all comes down to how it's written and what it's used for. If you're a Microsoft windows programmer using VS, you're going to use inheritance whether you like it or not to extend existing .net functionality, or to customize a base function like exceptions for example. So this is all really nice theoretical talk, but to me it doesn't mean much when it comes to working in the real world. I do appreciate what Stefan is saying and don't jump to inheritance when designing my projects, but it does have it's place and if done properly is a great way of designing certain things. It was certainly an excellent approach to communication drivers in handling the different layers. The base classes didn't need to be modified because they only performed a specific task. Complexity is added as the layers of classes are built. Good design allows one to plug in additional functionality on the proper layer. This was very straight forward with communication drivers. I would not say it's the best solution for different types of application, but it was for that. The code wasn't brittle, and the changes that I referred to were always additional functionality which is normally 'added' to the existing code. Yes, it takes some thinking, and planning to do inheritance. I think that some coders just don't have the talent for using it because it takes a little time to plan.. Again, to just say that inheritance is bad design and brittle to me reflects a certain amount of ignorance. The fact is that if you're using any existing libraries to build on in the modern world, those libraries / frameworks use it. Why? It's a damn good idea if you know what you're doing. It's not necessary for most developers to use inheritance in their own designs, and because it 'can' be an issue for them then sure, don't use it, but don't for a moment imagine that the frameworks you're building your apps with don't use it. If you think that you're merely sawing off the branch you're sitting on. Cheers
Let me add what I think could be a general rule about using inheritance because I will agree that inheritance is not for everyone, nor is it for every project. It should not be used just for the sake of using it. It's not a silver bullet to solve a solution building problem: 1) If you don't fully understand inheritance you shouldn't be using it. I don't just mean the 'how', I mean the 'why', because there IS a why. 2) If you do understand inheritance and it's philosophy of application to a class structure, then you'll know when to use it, and it won't matter what anyone on a vlog or blog has to say about it , positive, or negative. The second point to me is what makes this discussion a little silly. If a person really understands inheritance , the how, when, and why it should be used, telling them they shouldn't use it because it makes for brittle code is a straw-man argument. It's meaningless. Never use it because someone said you should. The notion that it makes for good designs in an of itself is nonsense just like proposing any other technique as a be all, end all to coding a solution. I would recommend that developers take the time to understand inheritance though, and the relationship of 'is a' as opposed to 'has a' if for no other reason to be able to deal with it if and when they come across it.
I completely agree with most of what you are saying, but I would like to make a remark regarding the " 'is a' as opposed to 'has a' ". I have seen a great talk about inheritance and why its so bad, but I can't find it right now. There was one part of the talk that sticks very well and I remember it. Real world relationships have nothing in common with relationships of data in code. By every definition, Square IS A Rectangle. class Rectangle { private int width, height; public int getWidth() { return width; } public int getHeight() { return height; } public void setWidth(int w) { width = w; } public void setHeight(int h) { height = h; } } class Square : Rectangle { public int getSize() { return width; } public void setSize(int size) { width = size; height = size; } } If Square is used via the (getSize(), setSize()) interface, everything is fine. You can even use Square as a Rectangle and the (getWidth(), getHeight()) interface will work. But imagine what happens if someone intentionally or accidentally passes a Square instance to a function that wants a Rectangle. The function modifies the Rectangle (setWidth(5), setHeight(10)). Now the laws of nature are broken, and your Square is no longer a Square. The problem here is that a Square should never have been a Rectangle in the first place. The better solution would be to implement it using interfaces if one really needs that abstraction: interface Frame { virtual int getWidth(); virtual int getHeight(); } class Rectangle : Frame { private int width, height; public int getWidth() { return width; } public int getHeight() { return height; } public void setWidth(int w) { width = w; } public void setHeight(int h) { height = h; } } class Square : Frame { private int size; public int getWidth() { return size; } public int getHeight() { return size; } public void setSize(int s) { size = s; } } Again, the gist of the talk is that inheritance produces very brittle abstractions and can be implemented many other ways which produces the same quality of abstraction and even better if you take into account that its less brittle. Could you give a concrete example in which its hard to achieve something without using inheritance?
You have given a very interesting example... And, you are right, implementing your definition of Square class will lead to brittle code... But, the main reason for the code being brittle is less due to the concept of inheritance and more due to your mistakes... Before I start, let me think a reiterate your statement, "Every Square is a Rectangle". This is a very important fact.. But, there is also another part to it, and that is, "But, every Rectangle is not a Square". So, what is Square in relation with a Rectangle? And, the answer is "Square is a Rectangle where both length and breadth are of equal length." The aforementioned fact is the key statement that we, as designers of the class, needs to make sure is enforced throughout the Square class.. So, let us first define the Rectangle class... class Rectangle { private int width, height; Rectangle() { // Default Constructor width = 0 height = 0 } Rectangle(int w, int h) { // Mainly used for inheritance purposes width = w; height = h; } public int getWidth() { return width; } public int getHeight() { return height; } public void setWidth(int w) { width = w; } public void setHeight(int h) { height = h; } public int calculateArea() { return height * width; } public int calculatePerimeter() { return 2 * (height + width) } }; // End of Rectangle class (I hope that you still remember the statement about making sure that at all times, both length and breadth should be equivalent to the value of side i.e, length = breadth = side) Now, defining Square class... class Square: public Rectangle { private int side; Square(): Rectangle(0, 0), side(0) { // Default constructor } Square(int s): Rectangle(s, s), side(s) { // Parameterized constructor } public int getSide() { return side; } public void setSide(int s) { side = s; // Enforcing length = breadth = side setHeight(s); setWidth(s); } ( Since, like you have already mentioned that the existing function definitions for setHeight() and setWidth() are going problems in their original behavior... Therefore, we will need to override them, to make sure that our key fact remains true, even if someone calls these functions, they don't violate the "laws of nature" (as you call them )) public void setHeight(int h) { // Ideally, we should raise an exception but in this scenario, either we could do nothing or print a // statement telling the user that this operation is not possible, so that they don't get confused. cout
Bottom Line if you want to save time: Always avoid unnecessary complexity if you want to write a clean and maintainable code. It's not only inheritance, abstraction also sucks if you don't use it wisely.
To not understand what is being said in this video is to anchor yourself in the past. React, Vue, A-Frame, Web Components, preprocessors... They're all going this way. We're also mostly through the age of the monolith. Microservices make enterprise scalability practices obsolete. They also introduce domain driven design (DDD) which might start to take off once the business people learn about Event Storming. Functional, reactive, event driven, test driven, behavior driven... These are all far more attractive subjects to learn as a programmer than investing in learning how to draw intricate, elaborate, and delicate UML diagrams. OOP was a very necessary step outside of machine language, but even SmallTalk was oriented around messaging (hence the name).
6:29 in 3-4 seconds he said "that will CUT down the amount of code" and at the CUT something behind fell down as in his chi presence and willpower is so strong here he accidentally let loose his dragonbreth...
Used properly, there is nothing wrong with inheritance. Using OOP, you can create interchangeable code components with shared properties and behavior, reducing code and making it easier to read. The situation you describe could have been solved by using an abstract or pure virtual method in your base objects to establish a contract with derivatives, leaving implantation to them. If you change code in a method, so that the inputs no longer produce the same outputs, you are going to have problems no matter what paradigm you subscribe to! Of course, in a rushed production environment, depending on the programmer's skill and experience, using OOP can be a hindrance leading to long term un-maintainability.
The problem is that when you work with a large team, all the careful planning and metaphysical nail-biting that you went through to create your elegant object model gets lost as soon as you check your code into source-control. You spent a lot of time thinking about the essence of chairness before you wrote a line of code in class Chair. All of that philosophical hand-wringing is in your head, and not on the page, unless you write a novella-worth of comments. In which case, no one will read your novella, they will simply alter your base classes in a way that makes your novella completely invalid, and they won't bother to edit the novella. So now you have not only shitty code, you have shitty out of date comments to go along with the shitty code, and new programmers come in and see the mess you've all made and storm the boss's office with torches and pitchforks until she lets them re-write the mess. Using the "right" object model this time, of course. Complete with UML and sequence diagrams that capture about half the complexity of the first iteration of the rewrite, and then are never updated afterwards. Then along comes a new crop of kids to do it the "right" way again..... Not that I'm cynical. :)
Let’s ask the question another way. What can I do with inheritance that I can’t do with composition and interfaces? What we have learned over the last couple of decades is that small subset of items is, if it exists, tiny. For most programming tasks composition and interfaces achieve the same levels of polymorphism with a far less brittle design.
Nikola Tesla The communication was a problem because inheritance is among the tightest forms of coupling in use in modern programming. By definition the internal implementation of a base class is inherited by all sub classes. Yes, we have languages like C++ and Java that add a protected/private distinction. That distinction is an admission of the problem not a solution to it. Composition and interfaces provides equivalent representational power to the programmer while requiring all coupling to flow through publicly defined behaviors. No sneaky internal only interfaces to worry about. The composition and interface methodology is also more expressive because you can build bigger interfaces by composing smaller interfaces. It is also more expressive because I can implement and interface on something that may not be in anyway related to the base class. IO is a good example of this. Golang’s compression functions implement the writer and reader interface. As such I can implement compression for a file or network stream simply by inserting the desired compression function in the stack before I decide where to send the data. If my IO functionality required extending a base class every time I wanted a new IO handler I would have problems creating new IO handlers whose internal structure differed significantly from if not conflicted with the base classes internal structure.
NeuralSimulation -so the problem isn't inheritance. It's "co-workers" not reading the documentation and comments you put there so others *can* understand the framework and systems you designed to make their lives easier. Basically, the "co-workers" are actually "hacks" that don't care about anything but getting their tasks and tickets done as quickly as possible. without give a crap.
cool, i've watched a lot of your video but didn't know you lived in Canada. I don't fully know why but it's cool to see Canadians i like on youtube that are programmers. you dont find them too often
Interfaces leverage off of inheritance. Interfaces are just abstract base classes that languages like C# and Java use to allow multiple inheritance. So we're talking about the differences in abstract classes over virtual ones. Interfaces (abstract base classes) allow decoupling of implementation logic at compile-time whereas inheritance (virtual classes) generalise that logic so that it doesn't need to be re-implemented multiple times.
I recently read about computer architecture and operating system. They are all about interfaces. Inheritance can be rewritten as interface + dependence injection. Inheritance is actually interface in disguise, but with stricter constraints. Inheritance needs to inherit everything from base class. I think the worst part is that I can’t treat the base class written by someone else as a black box. I have to read the base class to make sure that I am using base class correctly.
While I do agree that interfaces are typically the better option, because it makes it easier to both change base classes and perform testing, there are downsides to them as well. For example, when someone uses an interface they typically expect that interface to never change, which is true for all interfaces (not just in programming). This often causes heaps of legacy code to pile up, since when someone comes up with a new and better way to do something in the base class, that often results in a brand new method in the interface, or a new version of that same interface. It's common for methods to be marked as deprecated, but left around for a long time without being explicitly removed, even if those deprecated methods may lead to security flaws or other critical errors. Or one may handicap these methods to prevent the errors, which users of the interface remain unaware of. Sometimes it's good to force changes because those changes are necessary, and that is the main advantage of inheritance. Yes, you break things, but by doing so you may prevent even greater issues. Of course you still have to tread with care, and use proper testing to ensure that you don't unintentionally break things (as in the example from the video).
I agree that removing complexity from code is a very good goal to aim for. However, having a rigid ideology like 'don't use inheritance' is a good way to create toxicity on a team and lose focus on what is pragmatically important. The one programmer shouting at the other is pretty clear evidence that this isn't a coding style problem, but a communication and team leadership problem. Composition, inheritance, are all tools that have their use depending on the situation. I would be careful not to lose sight of that.
Base classes are not meant to be changed (Open Close principle)....In any unavoidable case, if base class is bound to be changed, it'll never hamper the child one because of inheritance. But yeah it'll break if the child is making a Contract with it. So no worry with inheritance. Happy coding
(Replying to criticism of the video, not the video) No this video isn't "really about bad OOP vs good OOP". It's about understanding the vulnerabilities of OOP. In general, inheritance works well for libraries, abstract classes, interfaces (except that interfaces are "implemented", not really inherited), and similar very base-level objects. For the most part, however, YOU are likely not coding a "very base-level" object, unless you are the project lead or architect. Those base-level objects are intended to handle the parts of a project that are necessarily inflexible or otherwise require specialized knowledge, and to set up universal standards for all the other objects to live by. The video could have been a bit more clear about its point, however. The point that should have been made is "Composition over inheritance". en.wikipedia.org/wiki/Composition_over_inheritance ... This is how interfaces are typically used, injecting interfaces into an object rather than inheriting functionality from a base class. This also aligns with the Open/Close principle from SOLID: Open for extension, Closed for modification. The error made in the example is the violation of the Open/Close principle. Note that Mischook is talking about work done in the 1990s. SOLID principles were published in 2000 by Robert Martin (they weren't even called "SOLID" yet!). Back in the 90s, the OOP mantra was to use inheritance like crazy. Inheritance WAS the design pattern for a lot of people. (And the GoF "Design Patterns" book is from 1995, and not yet common knowledge among developers.) In a way, the SOLID principles might be regarded as a (not quite complete) list of the vulnerabilities of OOP, as opposed to a prescription of how to do OOP correctly. Part of doing OOP correctly is understanding its vulnerabilities, AND understanding how scope/requirements can change during the course of a project. In general, inheritance is more fragile and more rigid than composition and using interfaces. If even one developer on your team works on base classes for inheritance and forgets the Open/Close principle, it can cause other developers to lose a lot of time. The advice of "do it right the first time" addresses the wrong problem: some kinds of coding are riskier than others. So if you are giving tips to new developers, then suggesting that they avoid inheritance is good advice. This isn't to say that inheritance is bad, but it is risky even when it is absolutely necessary and should only be trusted to more experienced developers.
Very good video. I like the fact you have the courage to "attack" the principe of inheritance in oop. I'm building my first app with symfony framework and in this app I'm using oop inheritance, interfaces and trait. I also feel like interfaces and trait are more cool and flexible to implement than inheritance.
So what now if we don’t have change management, use interfaces, and some noob changes some buried lower level interface which causes someone to lose hours. Are we going to now take a dump on interfaces?
That instance occurs in every coding environment where there are more than one person working in a project. Not reading comments in the changes is one thing everyone could miss. Inheritance is a wonderful mechanism for breaking down complex component and layering improvements, usages, diversions on top. You find this in everything in nature. Children inherit parents genes to create diversities, electronic engineers reuse the same components to create different products. I think the guy who changed the underlying implementation of layer below should really think twice before jumping in and changing the implementation. He should have communicate proposals of changes before jumping in. That's just pure lack of communications. Nothing to do with 'weaknesses' as you've labeling your video.
If used properly, inheritance is a great tool for sharing resources among the child classes. This problem being described could have been avoided with a good testing suite (and hopefully an engineer smart enough to not simply rewrite failed tests without fully researching them).
I really like your videos and this is the first time when I do not agree with you. :) Inheritance is a very big gift when you have a modularized application and you want to customize it for your customers. Let’s say you have a core app and you want to sell it to individual customers. 1, Your first layer will be defined by interfaces. 2, Creating the core app by creating classes by predefined interfaces. 3, You will get a request from one of you client for customization -> inheritance will be your best friend :)
You're right. But it will take a generation or two for people to realize it. Many developers are extremely resistant to ideas that go against OOP dogma.
I was 100% self taught in coding starting in 4th grade. When I later learned about OOP it seemed like a crazy way to make things far more complicated and fragmented.
This story has NOTHING to do with OOP at all. Somebody changes something in the code and borks something else that touches it. Yeah, that is not the fault of OOP. This same story has happened on code that is not OOP at all. I am currently coding TCL and get the same thing.
Oop inheritance is bad because is not flexible in design and is hard to think.Is easier and more flexible if you use 'has a' relationship instead of 'is a', but inheritance is cool if you use capabilities like Runnable or Iterable, Drivable and for that is better to use Interfaces, also deep hierachies are hard to debug and test
Finally! Inheritance is the worst form of coupling. OO provides the ability to change objects behavior without modifying the class. Inheritance forbides this. And in order to keep it DRY all you have to do is "ctor" inject the object which functionality you would like to reuse.
So i did some research and it looks like this is actually really useful for entity objects in games. In my dev class for our project we realized the enemy movement could function just as well for platform movement, so maybe it would work better as an interface. I might try a game over the summer with an interface design to try it out. It would help me to get used to that and a sort of pseudo multiple inheritance at the very least (Using c# here). Though, i do believe in my beginner opinion that inheretance does have its place in games. I dont see anything inherently wrong with the tight coupling from a games standpoint, especially very shallow inheritance. The organizational side of me kind of bristles at using interfaces for things like to define wether the entity is an enemy or a non player character or a player. Why not have very shallow inheritance with very small classes and mostly interfaces? Yea you could “compose” a slime enemy of, say, enemy interfaces and movement interfaces and theres nothing actually wrong there. But the petty noob (or nerdling as you call it haha) part of me is muttering “ but its an enemy...it should go with the other enemies...”. Like a file system almost. That said, the more i think about it the more i like the idea of interfaces. C++ is huge in games and while it doesnt support interfaces it DOES support multiple inheritance, and it looks like you can take advantage of that to create “pseudo interfaces” if you will. Really interfaces just seem to be a way to allow multiple inheritance where it isnt allowed. Im glad i watched this video, if nothing else it got me to rethink convention which i always kind of like👍
@@Ryan-gx4ce It doesn't even work in theory. When the concept was developed computers had very little memory (32kWords or so) and software was necessarily small and simple. The academic examples on which inheritance was demonstrated in the early days are nowhere close to the kinds of systems in which it is in use today. That it would have to scale was therefor not a concern of its inventors.
When using inheritance, protected class members act as the interface between the base class and its sub classes. You can change private members of the base class as long as the protected members are not affected. But changing the behavior of protected members of the base class in any way is equivalent to changing the signature of an interface method: It changes the contract and breaks all the contractors.
First question: are those contracts necessary? If not, then why are they there in the first place? Reliable systems are loosely coupled, hence they don't make a myriad of assumptions about interfaces and they don't try to enforce resilience by hard requirements on other parts of the system.
@@lepidoptera9337 Strange question. Of course, there are cases when such contracts are required. Loose coupling is an ideal that can never be fully realized. Especially not in environments where short-term goal attainment is more important than the limiting case of t tending to infinity.
@@robertmuller1523 If you have short term goals, then loading your team with contracts is the last thing you should be doing. I have no idea what you are talking about. In general, if your software contains tons of tests and special case handlers, then you have been overthinking the problem.
@@lepidoptera9337 Who wrote about tons of testing and special case handling? On the other hand, the main motivation for people touting loose coupling as the ultimate design goal is usually precisely to build tons of tests around it. :)
@@robertmuller1523 I never build any test cases for my software. I still have industrial products with 100% uptime and zero known bugs out there. I am simply not anal about parts of the system that do not matter. I focus all of my attention on the parts that do, which is usually a very small number of core functions that have strong dependencies that can not be avoided.
The trouble with inheritance is that the Liskov substitution principle does not work correctly. What I mean by this is that, when you extend a class with additional methods, those methods often want stronger data structure invariants. This is the classical square-rectangle problem.
Inheritance is fine if you have a shallow broad tree. You just define you contracts with interfaces so the objects are interchangeable. Most people that hate OOP just ran into a bad design IMHO. It's no coincidence that a lot of development shops skip or shortchange the design phase. You reap what you sew...
I think I missed something. How is inheritance different from interfaces? I'm coming from C++, so if you want to do an interface, it's a struct with pure-virtual methods and then you still INHERIT from that... it can definitely get out of hand. Or you can use templates/concepts, which I now prefer over inheritance.
He is right. Dependencies are what kills it. Use interfaces instead of inheritance, it is a lighter form of dependency. If you still need to subclass, keep your inheritance hierarchies shallow. Other videos about this: "Oops! OOP Is Not What I Thought", "Object-Oriented Programming is Garbage: 3800 SLOC example", "Object-Oriented Programming is Embarrassing: 4 Short Examples" and "Object-Oriented Programming is Bad"
Regarding the computers, the difference between the mid level and the high end are often quite big in performance too, not only in the price. A mid level graphics card vs top of the range can mean the difference between making a game playable or watching a pictures slide show :), or if can deal with the same VR content or not. The other components matter just as much if you deal with virtual machines for example. I agree with your idea though, usually the percentage for the price difference is not found in the one for the performance difference. I definitely recommend you to try a computer from the higher range because you very likely can afford it. You will see that even though costs double it worth every penny, as anyone who got one can confirm (except the ones having problems with the RTX cards :)). Just go for robust components and configuration, not overclocked or too new components that are overpriced and untested properly. All the best!
But on the other hand it could be an advantage. If you want to change something for all sub-classes you just have to change in one place, not in every single class. Is it right?
Programmers should understand that computers don’t understand classes or inheritance. It’s a level of abstraction we use to make coding simpler. Inheritance is an abstraction of classes, and the more you abstract the more brittle your code becomes. Golang doesn’t have inheritance for that reason. People saying it was a problem of communication in this video, No because quite often programmers work on large projects where there is little communications. Also at times you work with legacy code with even less documentation. The problem with java and c# is that they force the oop model which in turn forces you to create classes to solve even a simple procedural problem. C++ allows the use of classes when need be, however using multiple inheritance leads to other problems as well.
Ah, I really enjoyed this one. Very insightful. I wasn't aware at all. (I learned programming from a book written in 1998.) I'm in total agreement: verbose is better than concise but cryptic.
The deeper reason why inheritance is flawed is that it mixes several concepts: reusing code, add new behavior, change existing behavior, introducing subtypes, conforming to existing types etc. There might be cases where this mix fits your needs, but more often some of the baked-in concepts fit and others don't. But you can't take just the concepts you want and need, it's an "all or nothing" decision.
Every type of coupling will make the code more brittle. So we got rid of coupling? If you do this then you will have the same code spread through the codebase and any bug or improvement should be replicated everywhere. OOP Inheritance can be used but as with any other coupling, it shall be used thoughtfully. Sometimes the problem is people using inheritance when they should be using composition. So when should we use inheritance though? When a family of classes has to have the same behavior, in some sense it's enforcement of behavior. Will it make the code more brittle? Sure, but you write tests to verify its consistency.
I don't think that interfaces are any different from inheritance. Basically, the API of a parent class is, in a nutshell, the interface of its subclasses. The only difference, basically, boils down to the fact that an interface can be implemented by anyone, but with inheritance, only subclasses can access the API (if we're talking about protected methods). So, basically, a parent class is a "private interface". The guy could change method signatures of interfaces too, and it would break your code too (think of ambiguous method resolution in C++)
The moral of the story: if somebody changes one part of the code, another part that relies on it may break. This nothing to do with OO or inheritance, nothing at all.
Yes, it does, because inheritance creates the strongest possible dependencies. A much better way to develop systems is to keep dependencies to a minimum.
6 лет назад
Use interfaces instead whenever possible. But by making the properties final the issue would never had arisen. BTW, what is your opinion about deep learning making code instead of human coders?
Deep learning needs millions of examples to learn basic things and is very nondeterministic. It's not like humans that can learn something reasonably well after having done it a few times. When you add the fact that most of the difficulty of programming is often figuring out the requirements, that makes deep learning even less attractive. We've had programs that write programs for a long time, i.e. compilers. There isn't really much that machine learning can do to improve on them. You need to specify the software requirements to it in some way, and once you do, that specification is basically just a form of code. At that point, all your ML algorithm would be doing is act as a compiler, and ML isn't really helpful for compilers.
Very interesting video. Thanks Stefan. Another meaningful example of the virtues of the interface-based programming could be the Microsoft COM objects (with some conceptual and implementation quirks as compared to OOP that is more usual, but anyway)
You shouldn't be afraid of inheritance, because you otherwise will brake core concepts of OOP. But you should know when to replace inheritance with a composition. According to the 5th principle of SOLID - you should avoid using inheritance from non-abstract classes. So, according to this principle - in case if you want to extend one class from other, and the parent class: - is abstract class - use inheritance, - is non-abstract class - use composition Thats it.
Inheritance is a tool. Its not a very good tool, but its a necessary one. It should be used when all other tools can't get the job done, but no more than that.
I can agree that inheritance sucks in server side code, because i never need it on backend. But in game development, or graphic libraries it absolutely nessesary.
change function signatures in a function-only library -> same result change method signatures in an interface-only library -> same result bottom line, someone who modifies base classes, interfaces, or functions without consideration for existing code should not be called a coder. AND...running unit tests before commit would have avoided all the issues mentioned in the video.
Interfaces are also inherited, but they just don't have logic or fields, but enforce their objects to implement a function. Inheritance used properly significantly improves readability (given that you use proper naming) and makes the code more compact. A wall of code is not more readable, to the contrary, it's worse in pretty much every way if you don't use it when you probably should. It simply prevents redundant code and makes different objects approachable in the same way. The colleague that changed the base class is the real culprit here, and the other was a moron, because he knew there were more people working on the code and that should be one of the first places to look. A proper IDE would also help (or just looking at the compiler errors should be enough to not embarrass yourself) If you were to explain real drawbacks, like memory efficiency or security in some edge cases, I would agree. Your argument however does not check out and makes it seem like you don't know what the hell you're talking about.
This is just one tiny example, experienced developers could write books about how evil oop is, I still use it just as a way to structure large classes and hide variables, like interfaces but I never use them to do work or polymorphism, Never ever use them to allocate memory or threading
I don't think you even need to be experienced. When I was learning coding I was constantly baffled why there were no good explanations for OO despite everyone raving about it.
A 20% increase in run-time efficiency means your software will run better on slower systems. Will you notice it on a bleeding edge system? Probably not, but when your grandmother tries to run it on her 10 year old computer, it might mean being able to show her what you have been working on for the last six months... That's assuming she'd even really care, which she probably doesn't unless the program you wrote helps design knitting or cross-stitch patterns. Actually, my grandmother wrote a piece of software that laid out how to lay out colored threads on a loom in order to make different patterns, but I do digress. Even if Grandma doesn't care about the new Lego project software you just wrote, that poor guy who lives in the corner apartment downstairs and can't afford to upgrade his computer but builds Lego displays for the local public library will be happier when it runs on his machine. Of course, if you are trying to get top dollar for each copy running, you probably don't care about him. That being said, if I'm running the same code on a server that many people are using, that 20% efficiency means 20% more users are able to connect and run the program simultaneously. Of course, this all depends on the compiler and whether your code efficiency translates into run-time efficiency. This is not always the case. In rare occasions, tight code ends up translating into less efficient machine code.
My opinion is that if you follow the guidelines for what part of the code is reaponsible for certain things, and not try to fix a subclass by tweaking rhe base class, you wont get this issue. Since we dont know what was changed to fix a subclass, this whole talk is just an abstract opinion.
The flip side of brittle classes is that big fixes also propagate down into the tree as well... It's just like any other code. By the way, the whole reason for the interface contract is to define the behavior of the object. This isn't an inheritance problem, it's an implementation problem.
You clearly don't understand what "brittle," means. It means that it's inflexible. If anything it makes solving bugs more confusing. Even you point out that the supposed "flip side" applies to other code as well. Its not a flip side, it's a general property of code reuse.
But if you don't use OO inheritance than you don't use 80% of what object oriented environment has to offer. Inheritance is the key for most of design patterns. Some of the best patterns that need OO inheritance are composite, state, strategy and visitor. I agree that inherited classes are tightly coupled with the base class but what are the alternatives. Let's say you have the base class vehicle and inherited car, truck and tank and you have the list of vehicles. How would you implement this without the inheritance? If you use just an interface vehicle you would still need the duplicate code for position, weight, speed and methods, turn left right, brake...
So when you want to set the position of the tank you do this: MyTank.Vehicle.PositionX = 100; Instead of MyTank.PositionX = 100; if Inheritance was used? Doesn't that destroy the abstraction a little?
Yes indeed. I prefer prototypal inheritance of JavaScript. Prototype in JS is an object and all other objects inherits from it, but industry only recognize class-based languages as object-oriented. React.js or Python / Django is my preference.
Sorry folks, in 18 years as programmer I have never seen a huge library or system that does not rely on inheritance. Interfaces and inheritance are there to solve different problems. The problem is when people that does not know how to use a tool decides to say that the tool is bad. Maybe they were using inheritance when they should be using interfaces and vice-versa.
In terms of code sharing, I don't really see the benefit of composition over inheritance. You talked about a tight coupling between the base class and the sub classes and stuff breaking when you change code in the base class, but you have the same problems no matter how you share code. The problem is intrinsic to code sharing. I would've liked to hear your reasoning of why interfaces/composition are better than inheritance for code sharing instead of just "use this, it's better".
To all those saying it's a communication issue: it's not. That's not how software development works. You often need to deal with code whose original writer is long gone, or deal with needing to rewrite huge amounts of code because inheritance basically copies and pastes things. In general copying and pasting is not really a good idea in computer programming.
I have to disagree in spades. Inheritance is a wonderful mechanism, and it works well. Your story sounds like there were several layers of incompetence going on, not to mention mushroom management, and lack of communication. That said, Interfaces are good, too. Interfaces have their own problems, but they certainly solve the other inheritance problem that was never resolved: multiple inheritance. Inheritance works well as long as your classes emphasize polymorphism rather than encapsulation. In other words, class structures that are wide and not deep.
You know, while I think the language itself is ugly, I think one of the best implementations of OOP was ObjectiveC. It used a message-passing design, and de-emphasized inheritance and the like. Message passing isn't perfect, but it allowed a more "horizontal" design, instead of a hierarchical one.
What he should say is this: Don't make modifications to the base class, just add to it. That's the contract between base class designers and class consumers. However Stefan showed a good example of real life development.
I was just telling a story about what other developers did. Yes, in practice you should not change the base class. But most people these days are writing business objects that IMHO are not good subjects for base classes. Developing middle layer code is typically hectic and interfaces gives you some flexibility there.
Ohh that's a tough one! I'm am not sure because I haven't followed ggg career closely. But I am under the impression Canelo has fought better opponents ... perhaps giving him the edge? But ggg can hit and is a cool cookie. Should be a great fight!
Well, there's a large number of people who believe OOP in general sucks, lol. Personally, I have mixed feelings, although it seems to work pretty well in django. . .Then again, using django (as a developer) I rarely use it in my own code. Although, if you're using django, you are using inheritance. . . What I mean is this, django has it's own form classes. So, if I don't want to do my form in html (use django forms instead), I'm using inheritance and everything works great. Most of django is like that, even if you're writing function based code, in some way you're probably using inheritance. But for the most part, I try to stay away from OOP in general, because I don't feel I'm good enough, or have enough experience to do a good job.
It goes for all OO languages. Do a search on 'design by interface' .... and you will find some compelling articles on it. I just discovered it on my own through work, and then later found authors writing about it.
I find this interesting. As a student in University my professors go on and on about how great and important Inheritance is. As usual there is more to the story. I myself have had some struggles when I use inheritance but I figured it was just because I was a new programmer and had much to learn.
That search returns 56 results, most having nothing to do with programming. Anyway, interfaces and inheritance are not mutually exclusive. Did you perhaps mean "composition"?
Too strong of a claim. Inheritance can make your life much easier in some situations. Of course, It should only be used when It makes sense, but it's usefulness is not as rare as you might think. Besides, i can think of alot of problems that can arise from composition if there's a lack of communication.
Sorry, but i don't agree with you and that doesn't mean i didn't respect your 20+ years of coding and developing experience. Now it is easier to navigate through subclasses or superclasses. Many intelligent IDEs that support that thing. Even if we need to change the variable name, the IDE itself can show you which classes will get affected and even can do easy refactor to all classes that refer to the variable itself. And now we have a version control system like git or subversion, so if anyone of the team members change something it will be easier to track or fix :).
You make some fair points. That said, sometimes things come down to taste: some people love chicken and some prefer turkey - it's all good because there is plenty of bird to go around! :)Thanks for the comment.Stef
Just because code is easy to write doesn't make it good code. You may not agree, but among language designers, computer scientists and industry leading engineers, there is no debate any longer. Inheritance is a bad idea, and it can be demonstrated mathematically. The way complexity scales with program size means that it is only rarely a good solution.
I still use inheritance and have no issues with scalability. I will admit that there are occasions where people apply inheritance where it would be much easier and maintainable to apply a behavior pattern.... I don't know anything about this demonstrated mathematically business. Perhaps if you supplied a reference I could look into it.
The question is just, why should you use inheritance, when you have interfaces. In most cases, interfaces are fullflling the task and have the great flexibility to be resistant against changes in the base, because no logic is involved in the process.
Mr Mischook, I'm a new subscriber and I like listening to your ideas and advice in every video. However, you're wrong in this one. It only makes sense that the subclasses may break if someone changes the base class. That's why it's called base class. If that superclass is written in enough of abstraction, there's no way it would harm the subclasses. They could only benefit from that. The actual problem of these two people was lack of communication and version control like git. Right?
"The actual problem of these two people was lack of communication and version control like git." True. But in production programming, this can happen a lot. I prefer composition and interfaces over inheritance myself. Ref: en.wikipedia.org/wiki/Composition_over_inheritance
I know that this is old, but if someone changes the behaviour of the object that you used to compose your, it will still break! I don't see that much difference. The real solution to this are unit tests, not paradigm change.
Thanks for experience sharing. You raise the important issues. I would like to get more information on it. Doesn't it just seem common problem of management/communication in team to you?
I mostly blame that guy for not warning his coworkers of the changes he was going to make, but then again the tight coupling between the classes means it would have been a hassle to modify the subclass anyway.
Yeah, you can use interfaces for everything. That works, and solves the problem of the brittleness of inheritance. Or... you could learn about composition, delegation, and higher-order functions, and transition from a puppet into a real boy. :) It also helps if you pick a language that supports those things as first-class citizens instead of as an afterthought (not java **cough**)! You're welcome.:)
But why use interfaces at all? I can see some sense in it if you're the top engineer (or above in the hierarchy of others) and want to force 'em to implement some function (names, since you cannot implement any function's code in the interface), but if you're the sole coder, I can see any sense in using interfaces... but I agree that inheritance sucks... I think it may be useful in some applications, like game design that you have a class, e.g., 'villain' and subclasses, e.g., 'ogre', 'troll', 'skeleton', &c. Of course you must do a very good design leaving to the main class only the functionality that, if changed, the change will make sense for all the subclasses. I think you would make a great lesson for us if you talk about performance issues in this case: would make any difference in: 1) creating a superclass villain and the subclasses of its species; 2) copying and pasting the functionalities of what would be the superclass in each villain and avoiding the superclass at all? And would there be any difference using this latter technique in compiled and interpreted languages?
This is bad advice. Using your argument further, then using functions in software sucks because if someone changes it, the whole program is affected, it becomes "brittle" using your terminology. The problem here was revision control, where your friend wasn't informed of a revision made to the base class. Inheritance is useful where it's needed. But I agree where you say it's far better to elevate simplicity and readability above elegant complexity, to ensure maintainability of software. And I would go further and say object oriented programming is over used in areas where it's not needed.
@@michaelmugge1865 The version control systems of the 90's were not as efficient and convenient as of today. Just a thought based on recollecting similar memories of those dark ages... Main point though and take-home message from this video is that tight coupling is generally speaking a bad idea. The tightest coupling there is is OOP inheritance. Hence, claiming it sucks is a no-brainer.
Come on, you could perhaps argue that the metaphor used could have been better. What you can not do is compare OOP inheritance and it's innate tight coupling problem with "functions". The whole idea of avoiding tight coupling, and the tightest there is - OOP inheritance - comes down to the brittleness of not promoting or enabling future change. Changing a (1!?) function should be easy...especially if it is pure.
Thomas Sandberg .. he’s saying it sucks now. Are we arguing that we should not use inheritance today because VC sucked in the 90s? Besides even back then, we used versioning and any breaking change get a different major version ID so downstream devs don’t run into this. This has nothing to do with inheritance. It’s a simple failure at change management.
@@senpaisylnsr5253 To repeat myself, the main point is not the metaphor used in his example. What is important and correct though is him addressing the unnecessary brittleness using OOP inheritance which enforces the strongest kind of coupling there is. Use interfaces or better composition (or even better, abandon many of the OOP practices in favour of FP) but do not claim that class inheritance is the recommended way to do it. Not yesteryear, not today and not in the future.
@@devtactix No. They're right and you're missing the point:: inheritance >management< is principally the same thing for any sort of dependency management, whether it be code, libraries, APIs, infrastructure .. or what ever. A breaking change in any of these areas that is not communicated / known / managed / TESTED .. will basically lead to "brittleness" in any of these areas. If your misuse of something makes it "brittle" then you need to go back to the kiddy pool, before you drown in the pool with the big kids.
You recommend delivering a product that's 20% less efficient so you can do %30 less work :) You also don't give a coherent reason why tight coupling is an issue, just that someone changed code in a program and broke things one time. You can change source code in an interface and break its implemented use also, but that's not an example of tight coupling.
Sounds like a testing problem rather than a design problem. The tests should have blocked the base class changes before they were delivered and broke the derived classes for everyone else. You should never have a team setup where someone can deliver broken code without anyone noticing. OOP is a tool. Like any other tool, you'll break more than you'll fix if you don't know how to use it.
