Let's Talk - Separate State from Behavior - Yes PLEASE!

sometimes i catch myself wondering why people don't separate state and behavior in their classes what's up youtube in today's video we're going to be talking about state and behavior and separating these in your classes so when you design or define classes i design classes in such a way that i'd separate out state and behavior so what does that mean and why would i do that so this is one of my less talk series which means there's some sort of a controversy between those who do and those who don't and i'm all for it which is why this title says yes please for a change all the other titles so far have said no thank you however i've flipped the question which is why i can say yes please so because i know most people see objects as these real-life objects so if you have a vehicle then not only does it have some attributes or certain state like number of wheels number of cylinders etc etc make model here but also behavior you know start accelerate break turn all these kind of things people see or are trying to mimic these real world objects and sort of i think in many ways pretend now let me also just preface this whole thing by saying that i've done this i've been there most times when i'm against something it's because i've been there i've done it i've experienced it and i've been deformed since then so you will never find me talk about something or trash something that i've not done myself okay i don't just read about things i don't just play around for two minutes and kind of come to a conclusion i have lived the experience okay everything i talk to you about on this channel is a lived experience is an actual honest experience i may go towards that experience away from the experience depending on what my the outcome is over sometimes many years of following a certain practice this practice of trying to mimic or model classes like real world objects i have done that from the get go from from you know my beginnings of my objective programming kind of career and especially when i started to understand object-oriented programming even more than initially i was kind of just kind of tripping over myself and kind of getting stuff working i at some point in time maybe three four years into my career i started to actually design object-oriented systems i was very very proud of these systems [Music] these were pure object-oriented systems these were exactly model like the a purest design i would do it i mean i am not in the mode of wanting to compromise in most things in my life so when it comes to my work i'm just the same i do things the way i can perfect it or i achieve it i may not even get there but at least i keep trying to get there so these systems were extremely oh ish okay nobody could find fault and an object programmer could never find fault with these designs they were probably over the top some would call them over engineered we'll have a different take on that these days but what i'm trying to get at is i've been there i've done it i was i've had bought into it and very quickly i realized well not very quickly depending on your frame of context i've been doing this for 25 years so very quickly it could be you know five years away for a period of time from feedback from people on the team having my own thoughts about stuff as i'm maintaining building out these systems starting on new ones certain things came to my realization and of course it was as is normal you know we we don't like to hear certain things especially when it comes from other people but even in my my case i am finding certain problems with these systems and i'm refusing to accept them to be problems i would chalk it down to things like man should we just need to get with the you know this is you're just stupid too stupid to understand what's going on it's too big a system at this point so you know give yourself some space you're going to take time to figure this out you know because i'm not the only one writing code in the system this is the whole team there and so the code is growing in leaps and bounds and everyone is silently or sometimes vocally complaining about the clutter of classes the unable to understand what is going on in the system unmaintainable i mean everyone's proudly look at the code in in chunks oh my gosh these scenes are so beautifully designed you got classes they got state meaning attributes of properties that maintain state for every object every instance behavior you know so an order can go create itself in order to go delete itself and oh my gosh it looks so cool but over a period of time you at least the way i was going down that path was okay like you know it is fine there's the academic way of doing things and then there's the real world okay and in my past career electronics it was the same thing right in academia you are taught certain things just all this theory you know the practicals in the real world man you are on in a totally different planet you are not doing anything like you thought you were going to be doing when you were in school the understanding and learning you get by actually doing something is vastly different from the theory that you could the knowledge as i call it you could learn from by reading a book being in college online so there's a difference between information which is what you're going to get on google which you can get from my videos by the way this information for you to convert that information to knowledge you have to have had some experience you've got to take what i'm saying and you got to try it out for yourselves to understand that information which means now you're starting to get the knowledge from that information just reading or listening to me or reading somebody's blog or reading a book doesn't give you the knowledge it gives you the information you to convert that information to knowledge by some form of practical conversion maybe you take the same information and you dice it in ten different ways to understand to confirm your understanding you know so it was like this end would i get there was it like that and if i get there so you know you're playing these games in your hair saying playing through different permutations or in the case of programming you actually write some code you need to use different technologies to try and achieve the same thing whatever i'm saying now to convert or translate that information to knowledge knowledge exercised over a period of time gives you experience and it takes a long time many many years in decades sometimes so using that knowledge over and over again gives you experience and once you were done or got that much of experience like you know decades of experience you tend to become skilled at that thing now a skill is like the epiderm is the top of the throat of the chain meaning you don't get better than the skill of course you can get better and better at your skill but what i'm saying is that's where you want to be there's a problem with being skilled it's like you know if you don't know how to ice skate and you go and talk to you know the olympic champion he or she's gonna say well it's easy really you have a clue what it takes right there's no way in hell you're gonna get up and put those skates on and just fly through the skating rink and start doing all the tools and the twists and everything else like they do they have attained a skill by the time you attain a skill that complexity disappears it's automatic you're on autopilot so what i'm getting at i'll touch back on this basically i was just wanting to bring out the knowledge experience and skill there are different levels at different takes decades and decades each of these but information is not knowledge you have to convert this information that i'm giving you to knowledge by actually doing or playing with something and trying out different experiments okay and then you get the knowledge then you understand what i'm saying and then you do that many times you get the experience and then you do that many more decades and you get skilled at that thing okay so just go back i'm going back now to sorry deviated here so i was in a place where what i was doing made a lot of sense to me why because i built the thing i designed the system most of the classes were done by me most of my team were filling in the blanks of people in the implementations of things but i decided what last what name what method what arguments all of that and so it was making a lot more sense to me that was making sense to the team there was one problem the second problem was when you're debugging or just if you're new to the team to wrap your head around what is going on in the system and who is doing what is it in the ass i'm to say backside but i'll just say pain in the ass because it is now when i was when i put myself in their shoes when i was putting myself from their point of view a new person joining the team or somebody who's not been in the team long enough and trying to digest that system that i had been designing of those systems i had to accept that these are overly f and complex systems and the job our job our primary job in software engineering is to simplify not complify get it simplicate not complify and the reason or not there's no reason to it that's what our job is what we tend to do is we complify which is we take things that are fairly simple and make them even more complex like i used to do when i used to design my perfectly object-oriented systems i take a simple problem and i designed this beautiful system object with a pure object-oriented system and now it's overly complex to make simple it's not easy you might have heard me say that many times in other other videos simple is not easy and that has two meanings one is it is not easy to make something simple all right but simple and easy are not the same thing so going back to the ice skating example when you take any skill whatever that i've worked with people who are machinists you know they're working on these late machines you know um doing stuff with steel and metals and this one guy visually could you know shave off a towel a thousandth of an inch just yeah that's a towel i didn't believe it so i had to measure it and it was without less than it was before now that guy been doing it for 50 years so he knows what he's saying i was like just watching i said you know when you held you would know that how could you didn't you didn't even measure damn thing there's no way you could tell me that's that's how he said that's at how anyway complexity becomes easier as your skill level increases the complexity doesn't disappear just because i can do something that is complex with my eyes closed doesn't make it that it's not complex it's become easy but it's still complex for you the same complexity will not only be complex would also be difficult so easy and difficult are the opposites and complex and simple are the opposites so for me something can be complex but easy i can't hide the fact that it's complex i mean ice skating and tolling around and jumping up in the air with three you know twists and landing on your foot and not falling you can't tell me that's not complex that is complex but it's easy they've done it so many times they practice they got the skill they can do it for them it is easy for us it is difficult so the the problem is that when you do something for yourself design the system for yourself that complexity seems to be at least to you maybe you're fooling yourself like ours is also easy but if you were being honest you realize maybe maybe maybe you don't think it's really you know difficult but what if you thought of different ways to do it which is what i did and i said but there has to be another way to do this this guy it can't be so difficult right these are simple systems the problem we're trying to solve is simple the solution is complified so we need to be simplicating and so this talk is about that this is there are a few things that make our software objective programming uh software complex unnecessarily complex okay one of them the key parts is combining state and behaviors what is state and what is behavior behavior are methods right so in objects that there are methods that's behavior state is typically properties private members any way of maintaining state any way or maintaining information in an instance of a class and that information then sort of stays around until the class disappears so you can share that information with that class with other classes other classes can share information you can access property values from that instance in my systems for many many years now over a decade or so maybe more yeah actually quite a bit more um i have been separating out state from behavior which means i my dtos i call them data transfer objects or some people call them value objects they are immutable and let's see what immutable classes basically is the idea is that you once you create an instance of it you cannot change any properties so you have to set all the properties it has at the time of construction and from that point forward you can't change the properties okay so for example here's an immutable dto okay so this office is sealed it doesn't in descent from anything it's got these properties but they're all get only properties and of course this is the new syntax for c-sharp seven i think where you get um behind the scenes of the backing field that is defined as a read-only so you're almost uh forced into the fact that you have to set this title in it has to be said in the constructor it can't be set somewhere else and some by some other method so there's only a get but in the constructor you'll be allowed to be set all right so this is an immutable dto so i have details that are immutable and these are the classes that sort of move around these are classes that have been passed around your system they have no behavior and they cannot be modified why would you want to do that because it's easier to wrap your head around it's easier to comprehend your system when the stuff that's moving around is harmless it can't change state it can't do anything it's like it's like you know me giving you a key to a wall but the key is like a blanket can't do anything you still have the key it should be kind of useful for anything because it's not going to open anything right that safety the guarantee that you have and things are moving around your system the information is available yet cannot be modified and those things because we have an instance of that class at hand you cannot call methods on it to do some weird things like you know save itself in the database or delete yourself and all this sort of thing so immutable or dtos are immutable so that's one kind of class they're actually three kind of classes today we're gonna talk about two the third kind is statics this is going to talk after this one most likely called let's talk standard classes i'm going to say yes please exactly why that's another can of worms so i'm going to talk about that in the next in the next video okay so but moving back to this uh details immutable so there are details this they're stateful classes but they're immutable so they get once they have once you have an instance of it its state cannot be modified so even though it maintains state the state is unchanging which in itself has the benefit as i said you nothing can be done to it it's not magically going to transform itself as it moves around your system that allows you to reason about your system in a much better easier it just makes it easier the second kind of classes are those that have behavior but no state so these are classes that do things but have no state now some people relate states statelessness or statefulness to properties which is to some extent true i'm going to show you a class i'm going to explain to you why even though this class has properties it is stateless okay so i want to qualify what i'm calling stateless just to be clear it is stateless foreign purposes this stateless i just want to make sure people understand that you can't just correlate properties to mean statefulness and no properties to mean statelessness right so i'll show you that class but these classes are stateless and they do behavior they may get these dtos the other types of classes those immutable stateful classes as arguments or may return them as part of their return types in their methods but that's it there's no movement of behavior classes in your system you don't pass a behavior class to another another class there's also a behavior class that's like you know like some people design this item and see this all the time where the order class and the customer class okay who guess what does you do you get the customer to create the order do you give the order to the customer like and then they they have these classes that are beautifully or designed you know they've got attributes and they got behavior and you say okay i'm going to send the order the customer i'm going to send the customer the order and then the order class will call a method on the customer to coax data it is very difficult to understand very difficult to reason about your code when you pass classes around that have behavior because you don't know who or where it's going to call what method on it imagine you're on a team in a software team and each of us has certain work to do in this sprint the team lead or you know whatever your the scrum master is for the most part confident that you will do your part i will do my part something else to do that part pretty clear cut right and at the end of the spin you should all kind of merge it and fit together but if i did your part when you did somebody else's partner and somebody else did my part and i'm also doing 10 other people's parts and they're also doing the same things that's going to be chaos the team lead or the the scrum master is not going to understand what the heck is going on in this team like who's doing what because it's just impossible that's what happens when you mix behavior with state and because if you're passing these classes around these behavior classes around two methods it is impossible to understand who's calling what method on the class right so at a high level that's what it is behavior are classes that have methods but no state doesn't mean no properties so i'll show you the other class i was talking about here here's this class this is a movie manager it's a behavior class it has properties and it's got some private members here so you can see these are all properties right and you're going to say well then shift this thing has got properties how come it stayed less why do you call service p stateless because the state that it does have are nothing but references to other classes that are also stateless by that i mean here look if you look at this these are instances or references to other classes these classes themselves are stateless the same thing over here it's a reference to another behavior class but it's a reference but that behavior class is also a stateless class and therefore this class even though it has properties or members that reference other classes they themselves don't have properties i can call see these properties are all private so it's not like you can access the properties of this thing outside so just because you may have a reference to this thing here you can't call the properties right so you can't manipulate the state directly this these classes behavior classes are used internally by this class but they're not passed around there's no methods that have behavior classes that's the the dto or the immutable stateful class and these are also this that's it there's no you don't pass these behavior classes around you may use them in a composite like over here this class which is a behavior class in itself is using other classes that are also providing it some functionality some behavior they are themselves stateless these private properties are private sorry properties are private so you cannot access these properties if you even if you have a reference to this but you can call methods as far as your concern these this class is a behavior only class the properties it has even though it's maintaining state is simply maintaining a reference to other classes that are also stateless and they don't have any properties either so you can only call methods on those classes and so on okay so what i found once i started to do this took me a while like a couple of years to sort of fine-tune this but right away not only did i feel this thing but everyone on the team that had been working with me in the past would start to say oh my gosh this why are these systems becomes this so simple isn't it it's like also easy to understand like what what's going on and what's happening and who's doing what like which class is doing what and he said yeah don't you think and they said yeah it's like pretty simple now few things happened here one is the number of classes were cut down that was the other problem i found was when you try and model the real world and you have this whole single responsibility i'm sorry single responsibility is a thing yes it's a thing when you have problems it's not a thing when you don't have problems okay and uh uncle bobby did that too i think most people are misunderstood what he's been saying he's not been very clear right it's only when people sort of push him for an answer that's when he will kind of say well you only do that you know when you have problems you don't do it from the get go you don't start off building your system using solid principles it's when it comes time to doing some sort of refactor that's the time you need to apply these techniques okay but no no anyway i don't i'm not modeling the real world for me there's no real world when it comes to a software kind of model a business requirement what i'm modeling is the business requirement okay so for me an order is not a smart thing it's an order it's a piece of paper that has information on it that's it it's a dto it's an immutable dto that's an order it can't go save itself it can't go copy itself it can't go delete itself it can't go whatever it doesn't there may be some other person some other thing some of the class like this way in this case this um movie manager you saw it is the thing that operates on that dto let's say the order so there's a customer manager the problem with the mix of behavior and state is that there are many times in a renewable system let's say for example you have a department a department is not just working with one thing right it's working with multiple things multiple entities which are like these smart objects order customer there's that but the operations of the functions are across entities and you conveniently the operators will conveniently pass one object into another as if that's how it's supposed to happen right no but if you get it in the real world in the real real world not in the fake real world these people in the department are working with customers and orders let's say and they are operating on the data right they don't tell the customer to do something they get the information from the customer they create an order and they process the order to make it a thing like a real thing so if you were to look at it from that point of view there is a thing because there's a department that manages multiple entities such as customers and orders and performs some functions on them right it's not that the customer itself is smart or the order itself is able to do its thing it requires somebody else to coordinate and orchestrate across these two entities to then do the thing and that's what this manager i'm not going to go into the details of that the sort of style in which i create these systems of mine that use these principles i think it's very interesting i think it's very very simple to do if you would want me to make a video on that please let me know in the comments and i'll think about making a video where i go much more detail into this and give you some real world examples as well in the past i have made a couple of videos i'll put things to them up here i think i forget the names but something with information guidelines and the facade design pad or something i forget the names but many many years ago 78 years ago nothing much has changed since then of course things have been refined and improved on but uh for the most part they're the same but just getting back to this the idea is that you have some other entity like your team lead is coordinating all the devs on the team to get each of them to do things and then come back so that the team lead is working across the team to get work done right it's not like he tells you to go to the next person to send your code there and so on and so forth and finally just magic happens and it comes back imagine the the call chain in code right a calls b call c calls d calls pretty difficult the other way of doing it is a team lead works with b works with c works with d works with e works with f a is in control orchestrating all the different things that can do their work but a or this department as i explained before is the party is the thing that handles the coordination across multiple entities rather than the entities themselves being smart now the department in my case the manager doesn't need to maintain state so the state is given to it it gets a customer instance that's a immutable dtr gets an order instance that's an immutable ddo it manages these two increase in the customer order by our functions that it has methods behavior it has it's not relying on the customer to have behavior or the order developer right so that's the essence of this whole thing this may or may not make sense to some of you listening here some of these things are really hard to explain you gotta see it you gotta you gotta try it out okay then and compare the two and you will of course you know if you wrote it one way it was another way you may not do it the way i'm suggesting if you would like to do an experiment get in touch with me tell me a simple system that you would like to build the way you build it let's say oro style you know all purest style and we can work together and then come up with the two different versions of it if you would like to see you know what i would do with that sort of scenario then you know i can we could do that we can publish both the version of the code and github and i can make another video on this versus that and many other people can join and tell us what which one they prefer right all right this that brings us to the end of this video i hope you've enjoyed yourselves i hope you've done a few things please subscribe please comment please give me a like and look forward to seeing you in the next video which is on the statics let's talk static classes yes please and i'll see you next time

Channel: Shiv Kumar

Views: 1,473

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

Id: srCLY1n0HQI

Length: 29min 30sec (1770 seconds)

Published: Sat Dec 05 2020