Let's Talk - Creating Instances, Using Inheritance - No Thank you!

sometimes i catch myself wondering why we create objects for every class in our system and why we don't use statics instead and what is it about statics that people seem to dislike what's up youtube welcome to this next video on the series let's talk today we're gonna be talking about a few things i'm going to put them all together because i think they are related but this video is in many many ways a continuation of last week's videos if you haven't watched last week's last week's video i'll put a link to it over here you need to understand what i would use today the terms behavior only classes and state only classes so i'll be using that here but just so you're clear please go and watch that video before you watch this one you haven't watched that yet all right so today's by the way this book i don't know if you can see this there you go this actual this book itself i mean the physical book not the the print if you will this specific book is about bought this in 1996 it's been with me since this it looks brand new it looks like i've not read the book or even bothered to open it [Music] but this book has been extremely well read by me i've read it many many many many times um so if you don't have this book it's not the best read so i don't necessarily recommend this book unfortunately because it's not just written well the code is in c plus or small talk in it's all very succinct and you know i think they're not trying to explain anything they're just trying to show how well they know their stuff for the most part that's my take on it because if you can't explain something you don't know it well enough anyway there are some key things in this book that i'll be talking about today but essentially the talk is about instances as in objects inheritance and then one of the tenets of over programming and polymorphism and how i use these three things i don't use these three things in my system to start with i'm going to talk about these dtos or state-only objects that i call them in the last video but these are classes that maintain state and you need instances of these because you generally have let's say collections of the same thing and so you want to have every instance maintain its own data right a collection of customers a collection of orders and things of that nature for those classes i have instances meaning you know objects but i don't have inheritance right why not because i've had listen you learn from your failures you don't learn from successes you only learn from failures at least that's how i see it you might learn a few things from your successes but it's more like you're patting yourself on the back with failures you have no option but to accept failure and start to learn from what what things didn't and did not work you know so that you can you kind of have this introspective uh idea about things when you have failed and what i've learned from some of my past phase now failures may be a stronger term but of course if you're being very hard on your designs on your let's say the outcome of your systems that you've built and you really nitpick and trying to find things you know what you could do to improve your systems then that's what i'm calling a failure like the system failed it's just there's something that i've said man i would have done this differently because you're seeing hints of certain issues or problems mainly to do with maintainability comprehension of the system for new team members you know things of that nature that's that's the driver for me when i talk about programming with intent that whole series i'll put a link to the playlist over here if you don't know what i'm talking about there's like at least 40 50 videos on that playlist well i don't know something a large number and this video is driven from programming with intent it's about the same idea you are programming with intents to show me your intent so how do you write your code to show me maybe it could be my future self it could be you joining the team in the future somebody else was on the team but didn't do what i did but you're kind of looking at the code after the fact whatever the me is all right so why don't i have inheritance in details because i think that unnecessarily confuses the issue and inheritance has issues these are well documented i want to beat them here these are well documented issues with inheritance and i don't use inheritance unless i have the need for polymorphism let me back up a little bit there are two kinds of inheritance one is extension for the sake of extension you are extending functionality from a parent class or an ancestor so you get some behavior and some properties for free from the ancestor and you want to extend or add more methods of properties to that ancestor that's for extension just for the sake of extension the other kind of inheritance is purely for the sake of polymorphism why because polymorphism depends on it which is the idea of being able to treat all classes in a family in the base class and all the sentence in a uniform fashion which implies you're not extending and that's what programming within two interface is all about it's programmed to the interface meaning that base classes interface if you're new to this channel when i say interface or interfaces i don't mean i blah blah blah i just mean the public surface of a glass or thing interface you know api but in this case interface so polymorphism requires you to program to the interface which is the base classes set of methods typically and not implementation meaning you don't have to worry about what additional functionality that might have been added on to the descendants so in other words when you inherit you're simply inheriting so that you can treat all the sentence in a uniform fashion your intention is not to extend now there could be commonality common functionality that is rolled up into the base class descendants are happy to use that implementation i'm talking about extension meaning adding on more than what the base class has so if you were to type a variable of a certain base type and you you know those methods or properties will go missing because you've extended right so two forms of inheritance one for the sake of extension and one for the sake of polymorphism i don't use inheritance for the sake of extension i only use inheritance for the sake of polymorphism okay but going back to the details that the project i'm working on currently uh one of the devs has convinced me by convince i mean you've got to make a really hard cell twist my arm make me see the light and kind of prove beyond reasonable doubt if you will to me that these classes these details should have a common ancestor and the reason i have given into this in this particular project and this is after many many years of not doing it is that there is a need for us to treat these same classes these dtos in a uniform fashion in one part of our system and as a result of which that is the sort of the driver that's the the the straw that broke the camel's back the tipping point if you will because we have this very strong need to treat these classes these details in a uniform fashion because they all share a certain set of properties they all extend but they all share a certain set of properties and in this part of our system we need to treat these classes in that uniform fashion so yes you know that's a very very rare situation i'm not talking about sharing the property so that it saves you from having the trouble to declare the same properties okay i'm talking about when you use these classes you have a need to reuse or look at just those properties in the commonality you don't care for the instance type if you will right so you're treating those classes polymorphically so don't make the mistake of saying because of these two classes or these ten classes share the same properties that they're inheriting from each other from the ancestor it's because it's on the flip side you need you have a need to treat them uniformly very different thing right so i'm not reusing or extending therefore i'm not inheriting because of reuse or extension i'm inheriting for the sake of treating them in a uniform fashion okay okay so the details i generally don't inherit i simply redefine the same class even the properties are the same i don't really care right it's not about some sort of comfort of oh my gosh i got to repeat myself it doesn't matter they are completely different entities they just belong different they don't share anything all right what about instances now [Music] we all talk about objects which means it's an instance right it's the instance of some class in my systems i don't really have a lot of objects now when i do inherit and when i do create an instance it's generally for the sake of polymorphism i love polymorphism so that's something i use you know classes for definitely because then i prefer polymorphism over let's say higher order functions which is sort of the functional style of getting polymorphism right i call that four minus polymorphism if you haven't seen that video of mine on delegates an hour or functions i'll put a link to it over here i talk about this thing how i call it poor man's polymorphism because it's there's no ceremony right you simply define a delegate and you're done there's no class hierarchy ancestor descendants and you know the lack of ceremony is why i'm calling it a poor man's polymorphism it's polymorphism it's just very quick and easy dirty quick and dirty you get to polymorphism without a lot of ceremony i prefer polymorph for them okay so at that point i will inherit okay i want to treat them uniformly i'll create an instance because of course the only way to pull off polymorphism is to create an instance of some class and then treat these instances in a uniform fashion if i don't i have a class for which i have no need for polymorphic behaviors and there's this one class and that's it right there's no family there's no hierarchy how to create an instance why would you need to create an instance of class that one you either don't inherit from or two you don't have multiple let's say versions implementations of it these are not details these are behavior-only classes now i'm talking about sorry i should have probably made mention of that this is behavior-only classes they don't have state if the class doesn't have state how does it maintain state and the class is not good if it's not belonging to a family if you will right whether you're intending to use this polymorphically then why do you need an instance simple question right simple answer you don't i don't i don't do that so if i have a class these are important classes so don't get me wrong these are not classes that you throw away from innocent they're not just like you know baby classes no no these are forming some real important critical functions in the system they're highly specialized in what they do and as a result there's no deviation as you don't have variations of the same theme you know in the business system there's no need for polymorphic behavior and so but that that functionality is still you know highly critical to the business but it's a standard class that's just how it is because i don't have a need for an instance why would i create an object just for the heck of it like what's the point of that what am i getting there's no multiple objects multiple instances with different state i don't have state in these classes so that already there's no need for it to be a instance and i don't intend to use these things polymorphically so there's no inheritance therefore no need to create an instance therefore i don't create an instance now before you get to using statics i strongly suggest watching this other video of mine i think i talk about statics i forget the title but there's something was stacked up a link over here it's paramount you understand statics you need to understand statics in and out because you make one mistake [Music] with these statics and that's it your life is going to be miserable it's very difficult to understand some of these problems because if you don't understand what statics are you won't recognize the problem [Music] and you won't pinpoint it to these static classes that you may have been either misusing or missed or wrongly programmed you know so be sure you understand what statics are how they how they should be implemented watch that video and only when you're comfortable and truly understand statics that's when i suggest you use statics so statics have their place i'm just trying to get across that point static classes have this they have their place and in my system the proportion of statics to non-study classes is 50 15 or more right so about 50 because a lot of my classes are like that they're all specialized classes one two three methods and they are used by other classes so they have the functionality that they they provide and that function is required but and that's it and that's there's no other version of this functionality that's all i have in my need for my system i also want to mention that i don't use inheritance but i do and will use composition and that's what some of this book actually mentions they say favor composition or inheritance as well besides the program to interface not implementation that's another one of those sort of the tenants i think of this book you know if you have this book don't get anything free the first two chapters that's it everything you need to know is right there so it's just the first chapter i forget i think it's just the first chapter not the second okay back to this is this interference thing so composition favorite composition or inheritance why because first of all you mitigate the issues that the well-known and documented issues with inheritance that's kind of gone secondly within attendance you have inheritance you have this thing about white box versus black box meaning descendants can see ancestry ancestor things right methods and properties and it feels a bit dirty because that it seems to be breaking encapsulation in some ways so with composition because you're dealing with the classes public surface so hopefully you understand composition i'm not going to explain it basically some people call it aggregations people call it composition for this conversation they're one of the same thing but they're not actually the same so if you understand aggregation it's the same thing composition and aggregation are the same for the purpose of this discussion so when you're composing or aggregating one class let's say class a aggregates classes b and c which means uses depends on b and c these b and c in my case would probably be static and because i have no need for there's no polymorphic behavior required so if there's no polymorphic behavior required these classes can just be static they're already behavior classes which means they have no state which means there's no need for an instance they don't inherit so again there's no need for an instance and they don't have this they don't need from a family if you will an ancestor they just static so class a could depend on or aggregate or composite classes b and c these classes b and c are static class a is giving me the full functionality of what i need i don't need to know i don't want to know that class a depends on b or c i don't actually don't want to know right i'm not interested so why do people actually do that why do they create instances for classes where the the criteria is met which is their let's say behavior only classes they don't inherit and have no need for polymorphic behavior but yet we go about creating instances of these classes why i have a theory [Music] it's the same what's the word i'm looking for this is the the culprits are the same right dependency injection mocking testing especially testing and isolation these are the same reason that these but that people create classes all the time because you can't test any classes okay so let it be you just test the outer class that aggregates these other classes right what do you have to test study classes you don't have to test everything in isolation just pretend those classes don't exist they're static just leave them alone no no you got to create an instance for everything because you have to be able to swap out everything for testing purposes and you have just completely damaged your system with all this proliferation of testing needed things just ramping across your system and creating instances right static classes have another advantage that is i'll take something out from that video on static stamp that i talked about there so just so you can have this conversation but please don't assume if you haven't watched that video you will understand what i'm saying here in that video talk about type objects and class objects every time you touch a class in the dotnet framework or any any class in the dot net world you are you have to have a type object if you're creating instances of these classes meaning you know new something other then you also have class objects class objects is what we would call objects you know instances the type object already exists only then can you create class objects with statics you only have type objects you don't have any class objects what i'm getting at is statics are less pressure on the garbage collector now this may not be a big deal i'm certainly not saying this is the reason to use statics right but you should know there's additional behavior or additional benefit there performance in terms of method calls are much faster or millisecond microseconds faster okay much faster it depends on what you're doing right at the end of the day if you're calling the same method a million times a second i've had systems what i've called methods uh well the request from the outside was 10 000 requests per second but some methods because they were being called from within a loop they were going easily you know over 500 000 per second right so if you're working at that level then the little bit of performance improvement the stacks give you does matter and the lack of additional garbage therefore less pressure on the garbage collector is a huge difference it's a big difference i'm not saying that's the reason to go to stacks but it's nice to know that that there's an additional benefit to statics so i think as i said most people stay away from statics because it's it's not conducive to testing in isolation and mocking independence injection but to me that's not a reason i don't the idea that i damaged my design to support testing i can't i just can't fathom that it's just too much of a compromise to make that's not to say i don't test it i mean maybe you don't know i test or not but i do i test my system i test all of it i get now that i chase this uh code coverage thing but i end up getting 98 100 code coverage just by doing my testing i don't even bother looking at the code coverage until after the fact and it's very simple to get that code coverage because i'm testing the functionality of the system i'm not just testing the parts and the pieces i'm testing the functionality i don't care what classes give me that functionality and there may be classes where i test uh compulsive i call a composite class compile the test these are the same kind of tests i was talking about the class a might composite a b and a c and a d maybe and these are other ones the static classes i don't care for me the outer class is the class that provides that functionality that's either critical or complex to the system and i would decide to test that class that composite independently of my entire system right so there's basic i mean there's time when i do that i'll do that as well but it's a case-by-case basis i don't say that's just how it's going to happen for every kind of classes if it's either complex or it's critical to the business then as a team we may decide to test that composite we see it as one class internally it might have other classes or use of the classes that's fine when you composite because you're dealing with the public surface of these classes that you're compositing it's black box reuse not white box right because you can't see the internal even that outer class the one that's aggregating the other classes can only see the public surface of these classes it composites so it's a black box reused rather than a white box to use right and that's one of the problems with inheritance the white boxer is that is mitigated by composition okay so i don't know what you guys think about this with regards to why create instances and why inherit since inheritance certainly is a big one of the tenets of three terms of objective programming and [Music] instances as well as this is writing what are you doing if you don't create instances and i'm saying i don't want to create instances why would i want an instance in programming with intent you are showing me your intent if you don't intend to maintain state therefore you don't create instances then don't create show me your intent be clear in the way you write the code the way you design these systems so i understand my future self me coming into the team in the future date or at some point later you know five ten years after the system written if i look at the code i understand your intention you don't intend for this class to inherit from something so it is not he not it's not inheriting it's sealed you don't intend to create distance from it and if it's a state less class then why do you need an instance and make it static if the class is static right off the get go then i know that that's your intention these were all these things you were trying to tell me was just marking the one class as static and that's it you told me all the stuff right so this communication a conversation you could be having with your future self or other people on the team without saying much static it says a lot right seal says a lot by the way just so while i'm on this topic of inheritance when you do inherit keep your hierarchy shallow meaning there's a let's say a base class ancestor and there's second level down there's a bunch of descendants so it's a wide hierarchy but shallow i mean it's just not going deep right the other problem with the inheritance is that as you get deeper things get a bit too complicated and hairy and it's just it's just a nightmare so i strongly recommend if you do use inheritance for whatever purposes hopefully for polymorphism that's the only time i use inheritance is this shallow base class one level down that's it for the most part all right all right i hope this was fun i hope you guys enjoyed it if you have please give me a thumbs up and i'll see you next time

Channel: Shiv Kumar

Views: 1,399

Keywords: C#, .NET, OOD, OOP, Programming With Intent, .NET Core, Class Design, Class, Design, Seperation of concerns, State, Stateless, Statelesness, Statefull, Properties, Methods, Behavior, Data Transfer Object, DTOs, Value Objects, Immutable Classes, Records, Composition, Prefer Composition over inheritance, White box reuse, Black box reuse

Id: 80EYfd582PQ

Length: 24min 33sec (1473 seconds)

Published: Sun Dec 13 2020