So you want to be a Code Reviewer?: #2 - Levels Of Abstraction

what's up video in today's episode we're gonna be talking about levels of abstraction now this is a complicated topic or subject to explain certainly and it so happens that once you see it you seem to get it but that takes experience and time and a lot of code and a lot of looking at code to just get a sense of what I'm talking about but I'm hoping to try and explain that or simplify demystify abstraction and then certainly levels levels of abstraction this topic is also very closely related to code views design and so on so forth so I'm gonna put this video as part of my so you want to be a code of your aspect because when you're looking at code you also want to make sure that the things that you see are at the right levels of abstraction and I'll explain of course what that is now from the English meaning of the word abstraction it essentially means removing or extracting the complexities or structures or properties of something and decoupling it from where it is originally that's from the English meaning of the word and code as many versions of meanings of that essentially that boils down to something like you're dealing with the ideas rather than the concrete implementations of things or ideas well then the nitty-gritty details of how something is working in software that works very well because in software we are always talking in terms of concretions and implementations and such that then and such things so in software abstraction and those abstraction okay the two different things abstraction is the concept of decoupling from decoupling or hiding the details of something from where you are at so we want to abstract something away from here you're saying let's take this out let's move it out and decouple it from here so we're not having to deal with the details or the implementation details of the thing right levels of abstraction go quite a bit deeper than that abstraction and levels of abstraction is a key programming concept it's it applies to whatever kind of programming you're doing whether it's procedural programming or structured programming object and programming functional programming however you want to look at it the ideas are the same and the concepts are the same but it's also one of those things that people don't seem to focus on they don't understand or maybe they understand but they don't they don't pay a lot of heat to it more attention is paid to things like single responsibility and you know design and classes and all that sort of thing where the problem starts at the sort of foundation if you will where the idea of abstraction and then the second aspect in the idea of levels of abstraction is so key because if you get that aspect then automatically things start to fall in place otherwise you're designing classes but you're not paying heed or paying attention to the way these things are implemented and whether you should have abstract something to a class or not in itself questionable so just because you have a bunch of classes doesn't mean your system is designed well and certainly even if it's designed well is it implemented well the implementation part is really where we have to deal with in our code because that's what we maintain a bit on maintaining the design per se by maintaining the code that we see and that is the implementation levels of abstraction is pertinent more to the implementation of things but certainly also helps you understand the design and specifically this applies to or at least this talk is about method design and of course method design implies class design and class design implies system design and so on and so forth the way I would like to explain levels of abstraction is by way of again hardware and I'm hoping this is not too deep for some of you but you should be able to make sense of it but I'm talking about computer now we are working on a computer as programmers at a certain level abstraction this is a very high level abstraction c-sharp they also call it a high level language so it's a high level abstraction which means the abstraction is so high or so much that you're not able to see the real thing the real thing is that CPU working with bytes and bits in CPU registers and in memory and so on so forth but we now see that we know even think about that and that's the point of abstraction and that's also levels of abstraction in this case your C sharp code is at a much higher level of abstraction than the hardware even before the CPU so the CPU is comprised of logic gates is comprised of capacitors resistors and all that baked into a chip that what we call a CPU and the CPU in turn is on a motherboard and so on so forth with memory chips and hard drives and all the other components of a motherboard what we do in the c-sharp level up here at the high-level abstraction is really happening down here at the hardware level and there are many layers in between because from c-sharp you got the C shop compiler that takes our human readable c-sharp language code to aisle or intermediate language then the jitter or the just-in-time compiler takes that aisle and converts that to machine code then machine code or machine instruction sorry so x86 or arm or whatever and that is then compiled to machine code that that's the what the CPU understands and the CPU takes that and it's working with bits and bytes in in its ql1 l2 l3 cache or as main memory or registers and what have you for your application to work it goes from C sharp to these different levels of abstraction each level abstraction is getting closer and closer to the metal closer and closer to the thing that actually does the work if you get this you're gonna get levels abstraction very easily I'm going to try and explain some other ideas that are closely related to levels of abstraction but I'm going to show you code as well the core issue here is as I said is related to the code review process or so you want to be a code reviewer series and I'm gonna explain my reasoning so imagine you are looking at this code and you're doing a review what Falls do you find and how would you fix it and now I'll give you of course my perspective on what I'm seeing and why would I want to fix it but focus mainly on levels of abstraction not design all right so in this episode so leaves I'm talking about level abstraction I'm gonna try and keep my focus and your focus on levels of abstraction without getting too caught up and should this be another class or should this be you know 10 other classes what have you so that's not really where I'm going to go in this this episode and the code I'll make available to you on my github I'll put a link down in the description below but stay focused on the levels of abstraction which is the topic of this video all right says it before I even start with that I want to show you or talk to you about certain things that I work with in my systems maybe you'll start using the same ideas but it's important only because the code I'm going to show you is structured in that fashion and so you need to understand that part before I can show you the code when I start doing the refactor I might go a bit fast without trying to explain all the details of all the different classes you might see all right so what you're seeing here is the system this dark green box here is the system the cells interface layer if you remember from one of my other videos the core API principles design principles or API design principles I talked about the civil or the service interface layer and then the system so this is the block box here's the system now within this system I have in my systems I have a class called the domain facade I'm not going to try and explain that to you what it does or doesn't do but think of it as the the point of entry the only class that is available if you would imagine this green box to be an assembly then for the most part concept Lee speaking the only class you can see from our side this assembly is the domain facade of course there are exceptions you might be really you should be able to see and any details that are going in and out of the system but for the con for the purpose of this conversation just think of it this way the domain facade is your point of entry in the system is the only public class so that's the only thing the service interface layer is going to see all right I have there could be one or more managers and the managers have one or more helpers and they could be sharing helpers now I'm using the word helper as a generalized term I never have a folder or a class that has the word helper in it but when I speak when I'm talking about some managers helper it just implies it's a class that is a subordinate to a magic lass so rather than trying to define what kind of thing is doing I say generally it's a helper but there's no folder called helper there is no class called helper or the word helper is not part of the class name and then we have a data facade which is the the facade or the entry point into the data layer how could this is one assembly but I still have the idea that there's a data layer here so there's a demarcation between the business layer of the domain layer and the data layer and then the data layer has a similar structure there's a data manager that has one or more helpers and then eventually the managers as you can see from these arrows here the managers are the ones talking to the database now helpers can have helped us as well so we manager as in more helpers one or more of those helpers can have additional helpers now that's to the extent that I've ever gone and almost every one of my saw fit oven experiences it's not something that I even do often but sometimes a helper has helpers what you're gonna notice now is I've put these dotted lines here these classes are arranged in a specific manner as in this vertical sort of structure here to indicate levels of abstraction these levels of abstraction also manifest themselves at least in my projects or solutions as physical folders on the file system and of course in solution explorer a level of abstraction I'm gonna explain the differences but I'd the idea is that a level of abstraction is indicating a certain level of implementation detail so certain classes are doing certain work and then they elicit the help of other classes that are subordinate or down level from them that do more intricate work or detail work that is closer to the metal just like the c-sharp and the CPU aspect and all all the stuff in between c-sharp the compiler the jitter and machine code and so on so these classes like I call the domain facade level zero just because I'm not wanting to talk about that in this system in this video level one is it a certain high-level abstraction in my systems the managers are the essential point of entry even though the domain facade is the point of entry from the outside the domain facades not doing anything so effectively the core then I'm gonna write is going to be in the manager and the manager is the point of entry into my system that's the first of abstraction at that level abstraction it is instructions get these things done not how they this is the what are you doing but not the how you're doing it and I'll talk more detail about that class at a certain level of abstraction is using another class then that class has to be at a lower level of abstraction it cannot be at the same level in other words managers in this case don't talk to each other managers don't talk to each other any sibling siblings in terms of the levels but also in terms of a folder structure siblings don't talk to each other do you have a sibling you talk to dis kidding for this video of this episode siblings don't talk to each other so if a manager needs to make use of a class that classes by force a lower level abstraction from the manager it is also in a folder one level down from the managers folder level it's non ously in this doesn't have to be a child of the managers folder but if you can imagine certain folders at a certain level and subfolders at a different level then this class of these classes need to be in a level down from the manager in the folder system folder in the valve in the file system and also in solution explorer right and there's a reason for that so anytime you see an arrow going from class say some class to some other class you can you will know that that class is going to have to be found in a subfolder or a folder down from the class you're talking about and that's why it's important if this helper what do you make use of another helper as another class then that class also have to be in a subfolder below it or a folder level below it and it'll be in this case level three which I'm not showing here but so we have loved one and level two right now in my mind the way I think of these systems since this is a domain facade this is again a subsystem if you will that's combined in the one assembly and the level start again so this will be level zero then these class will be in level one and these classes will be in level two and if these classes require additional helpers as well and there will be a level three but once again is the manager the data manager in this case that talks with database the helpers don't they'll help us have no idea about the database but they're doing other work for the manager with the same idea here the managers are the ones that talk to the data facade these other classes have no notion of a data facade their helpers so the mayor talks to them they talk back them I don't go and talk to something else and something else at least the database so it's important to this is how I design systems so but this is not the primary topper I want you to understand that the way I diagram the system is also adhering to those levels of abstraction so in my mind the levels of abstraction manifest themselves in classes and or in folders but also in methods within the class so it's a bit confusing so I'm going start I'm going to show you some code so that that confusion hopefully will disappear all right so I have this solution open up here I'm gonna just zoom in into the folder structure so you can see what I've been talking about we have a solution I'm calling it movie service and it has a domain layer so this is one assembly at one project and that's another project so this is my silver cells individual er in this case it's just a Web API layer we're not gonna be talking about that today we're more focused on the domain layer so in the domain layers root folder there is my domain facade and that's for most parts that's the only class available in this folder level as you could have seen from the diagram then I have a folder called manages and then when I expand the manages folder there are a number of subfolders you can already tell first of all in this manages folder I should see a manager somewhere and we have a manager called movie manager and the manager is potentially using other classes and so these are all the other subfolders so this manager sitting here in this folder can talk to any classes in these supporters I said so if there are multiple managers they'll all reside in this folder siblings to this class and any of the managers could access the services of any one of these classes in these subjects but only classes and this apart this idea that a class at a certain level of abstraction can talk only one level down is very important you don't want a class at a certain level abstraction jumping down more than one level right if that's happening there's an issue in the way you decompose your your system the way you design a system if you need siblings to talk to each other same thing there is a problem in the way you decompose a dick design your system such that you are finding that two classes in the same level abstraction need to talk to each other so you could take out that commonality and abstract it into other class and put that class one level down and now these two managers or the two siblings can then talk to that one common class and that's why you may have a helpers helper as well because there could be two helpers that need certain common functionality and you say you know what I'm gonna extract this functionality out or abstract it out into another class because at that level the next level abstraction is lower it's closer to the metal is probably doing a lot more detail is a highly specialized thing and there could be two or more helpers requiring that specialization the help of that specialization so all right I'm gonna try and keep this simple but I'm hoping you understand and please follow along when you see some code immediately start to look for how would I fix it if you want to be a code reviewer your attention should be going to immediately what can I do to fix this code does this code need to be fixed how am I gonna fix it all these sorts of things alright so let's take a look I'm gonna focus your attention to certain pieces of code only so that we don't end up doing a whole lot of code view here in this episode I'll use the same code base for my next episode where we do some more code reviews so for now or for this episode just focus on the methods I'm pointing out to all right so this movie manager has a method called create movie given a movie which is a simple DTO as you can Talia is an immutable class it's got two string properties as genre property which is an enum and a hint property which is a year but it's relevant for this well somewhat relevant to the this talk but not that element my PWI talk my programming with intent talk on method design if you haven't watched it please watch it here because these talks are all gonna be focused more on what you've learned there or what I've talked about there and so I'm sort of reinforcing that in these talks so you want to be a cold viewer as well as this one validate all my data at the point of entry so this might sound a little weird it's not weird to me but maybe sounds weird to you I don't allow any bad data to come into my system so I'm gonna block it at the point of entry which is I call the front door and you probably heard me say this another episodes and certainly you'll hear me say this in the PWI talk I say if you lock the front door and you lock the back door you're safe in the house which means if you clean your data up before you let the data come into your system from the front as in from let's say from the UI side or API side or the back door which could be external services your database what have you if the front door and the back door a lock that no data can come no bad data can come into the house so you're safe in the house you don't have to worry about data being bad or incompatible or nas and s or thing okay so since this is the public method of the manager manages the point of entry into the into this system then the first thing I'm gonna do is validate the movie whatever that would mean to the business so all of these methods here are doing the validation there's not methods I mean all of the court lines of code here is doing validation okay so I check to see the movies null life if it's null throw an exception if it's not null validate every one of the properties the shaundra the title the image URL the year and if all of those are okay then if they're not okay throw an exception and if they're all okay I can then go ahead and save the data to my database now just for information say here the way I do validations is I validate rather than throwing an exception soon as I find the first problem in the lesson the movie let's say the title is incorrect I just throw an exception I accumulate all problems with any input data and throw one exception that details all the different problems that I might have encountered okay so to be more useful to be more user-friendly to have a better user experience or even from an external systems perspective father system is calling you then that team is gonna thank you saying my you give us one exception that told us everything was wrong and I suppose we fixed all of these things it just worked right in so saying it gives you a title that's the problem then the fix the timely server years of problem then they fix the error and I say also answers problems so the idea here is that it's going to do that not so relevant to this talk but I thought you should know since I don't want you to spend time trying to understand the code just know what it is that I'm doing here and then I open a database connection i well i create a connection open a connection i start a transaction i create a command for a specific store proc this case create movie oh and in my system that is the way i design systems method names have got the name of the business as if whatever that business might call it alright and as you can see the art are requests flow through the system right they an event is going to go out to a database or a service or whatever it is when I have a method called create movie here let's assume that's the what the business of the system calls it then there will be a store truck also called create movie and all the calls that this method will call will have not talking at helper classes or classes that are doing extra specialized work but once the manager is done with cleaning up and doing his thing it's not doing it here yet but it might call enter data manage it was hey can you please you know create this movie the data management method also going to call create movie the data manager is then going to use a store proc called create movie and so on so it's important to keep the names the same so that they don't start changing as the flow goes through the system that's going to be really confusing all right so without and understand all the details of this this is all the data data as we dissolve the code that is required in order to save this data into a database right so that's time and once that's done that's it so that's what the system this matter is doing in order to in order to create a movie validate the movie DTO and of DT of the valid if and of the DTS valid save it in the database that's it now if you can see what's happening here some of it could just be the the way I described the core to you you would know that there are at least two different things going on validation and database so right away we can say okay well one of the key aspects of levels of abstraction the way I design classes is every public method of every class is striving is trying to orchestrate any public method you have in a class the first thing you will see the only thing you would see in the implementation of this class is orchestration oxidation I mean in order to create a movie we just set it in order to create a movie you need to first validate the movie and then you can save the movie the orchestration representation of that is two steps step one validate step to save the movie into the database that's it I don't want to see the clutter all this code this is way too much detail for a manager now think of managers as your managers at work the typical hierarchy or structure is there's a manager then there is a a lead maybe it's a dev lead or a tech lead and then there's the developer right so there's three levels of abstraction at every level the people responsible or in that position do certain kinds of work only they don't go and into the detail their managers not gonna write code for for you hopefully have had that happen in one of my jobs with the CEO was writing code and I said this is ridiculous you should be doing your work let us do our work name but think of it that way as well the managers have a responsibility the managers delegate so managers might have multiple leads under them and each might the managers gonna say okay you leave so and so you get this done get your team to do this part for me and you leave so and so you get this part done for me the leads are a little more technical if not very technical and they will probably decide which of their developers is going to do what part they understand the developers okay this person is good in this thing or this person hasn't had an experience in this area we have some time and we're gonna give this work to this person so he or she can gain an extra experience on that in that area that they don't have any experience with and so on so the managers are deciding certain things and they orchestrate okay you do this you do this you do this the leads come and say okay I'm going to make some decision based on what I understand the system is sourced little bit like what technologies may be used and so their view you go do that and they view you to this and so on so forth different kinds of decisions but at the same time orchestration this key term were the orchestration parts are all public methods of all of my classes those strive to orchestrate and no matter how mundane or simple something might seem if it's in a class and the class hopefully is doing some useful work for you it has some complexity that needs to be factored out or needs to be abstracted from the public method in two steps and those steps are orchestration so effectively what I want to see here is I want to see let's say validate movie okay now if you're starting out with this idea our suggests very strongly to refactor in the same class don't think about the design of the system at this point and the setting is where the people make most people make a mistake they're immediately saying oh this should be a class that don't worry about them that'll all work out and will play out automatically if you can decompose your methods at the right level of abstraction once you can see groups of methods that probably belong into a separate class just copy pasted but at this point don't try and design the system just clean up the implementation from the perspective of levels of abstraction every method should it be at a certain level that matters that this method calls should be at a lower level of abstraction and if that those methods are calling other methods then those methods in the level three should be at even lower level of abstraction all right so I'm to save time I'm gonna speed things up a little bit I'm going to kind of jump ahead but keep in mind normally you should have just done this at in the same class itself I know in my systems I typically have validators that will do this work all right so I'm going to just delete this code out of here and I'm going to define a new folder under my managers folder I'm going to call it validators I also have a naming convention that is backwards from I'm guessing most of you if I have a movie validator you've probably called the glass movie validator white well I call them validator movie and the reason is the Alpha ordering in which the solution Explorer in Visual Studio and other IDs shows your classes so if I had a bunch of classes that were doing the same kind of thing like validation for example then if I had a movie validator and then add a ticket validator and I had a person validator and so on so forth they'll be ordered in alpha order and they could be all over the place and there could be other kinds of classes so while embedded in between them so rather than get all confused my validate is if I named them Delta way Valerie your movie validator person validator ticket and so on so forth the validator classes will all show up together so I called my classes I named them backwards a bit so I'm going to create a new class called validate a movie now with the help of some magic I've got my move evaluator validate a movie class here and I think that's good I'm just saying there's no compile errors okay now just to go a little deeper in the validation part this public method is called ensure movie is valid now ensure prefix of a method name and this is following the dotnet framework as well implies is called so an exception so if this says ensure movie's valid it implies if the movie is not valid is not throw an exception right I program two exceptions if you haven't seen that video of mine please take a look at it over here put a link up on there it's called programming two exceptions anyway in this video the understanding is that the movies not is going to throw an exception and if other issues exist then it's going to accumulate all the errors and finally throw an exception for all possible errors it might have found the public method they in turn have helper methods and so on so I've just pushed them all here they're all in the manager class I'm gonna actually remove them from the manager so I'm going to call this now validator movie I don't include the namespace and show movies' valid and give it a movie okay then all the other method that I copied over from here now however zero reference I can happily take them out from here okay so that's that so what you're also seeing because this is a manager class it's simply wanting to orchestrate managers should not be getting into the weeds of how to do something that's back in their pure worlds another that's our job the devs get in the weeds the leaves and the managers stay at a certain higher level abstraction they've got their own roles their own responsibilities but it's not coating the coating is our job we're down to the metal we actually get the code work done the leaves are making sure the entire team is working towards a certain goal to get that to a certain deadline and so on so they've got different responsibilities they do their work differently they're not dealing with or don't want to for the most part deal with the detail at which we are dealing with and conversely we don't want to be dealing with the detail they're dealing with so every class is at a certain level abstraction is a specialist at that level of abstraction and it's not meddling with or mixing and matching different levels of abstraction but it's also methods so I mean in a smaller system all of those this will have been a separate method right so this instead of saying validated a movie dot and show movies valid I would have actually just had a method in this class called ensure movies valid there's nothing wrong with it you should start here take my word you should start here once you're familiar things start to happen I think your brain starts to work in a certain way I'm not sure what happens but this is just or maybe this experience you know I think it's experience because I can since I've done it so many times I can see far ahead and so I already know that it's gonna be other class right but if you haven't done this little thing you know you're learning this thing I would say just refactor it into another method every method we call a method a calls method B it has to be in a lower level abstraction from method a and if B calls us C then C has to be at a lower level of abstraction lower level abstraction just means getting closer and closer to doing the real work a high/low obsession is I just want to know the the what not the how step one do this I don't wanna know how step two do that so if you were to look at the class in the future you're saying okay create a movie how does it do that don't want to know how what is required in order to create a movie well you can see here now they haven't reacted yet but step one validate the movie step 2 create the movie done so that's all it takes right so you don't want to get caught up in the in the how things are being done you want to know what has been done at every level even when this ensure movies call this method is called you still want to go into that method and say what do you need to do to validate a movie not the how part the what part every method is trying to explain to the viewer ours you know feed yourselves what are we doing not the how we doing it and you'll find yourself cleaning up your code and kind of getting more and you start will understand that certain methods just because the code you've seen these methods are at a certain level of abstraction and this part doesn't belong here or that part doesn't belong there because of these things okay so as I said this is a difficult concept to explain so I'm gonna try explain to you via code and hopefully that'll make sense okay this part here is very database centric so I'm going to move this since I already have a data manager via the data facade I'm going to move all this code into the Data Manager so in my data layer here as you can see we have a data layer over here so the data layer has a data facade so we just at the top level if you didn't do that you could see that structure and so I'm going to add a method here that says create movie so this create movie will be public it's definitely gonna be asynchronous and it's gonna return a task which means void that's gonna call me call create movie we all said the names don't change we don't invent names and this is going to take a movie okay because this is a facade it doesn't do much it's gonna call on to the movie didn't manager I can ask it to create a movie there it's gonna pass in the same movie no decision-making logic no validations in this case validation is not required remember if I lock the front door and I lock the back door I'm safe in the house so I'm never ever gonna validate arguments parameters coming into my methods I just assume it's okay if it's not okay it's your problem if you watch my PW video L say call us data call us problem all right so I need to do this asynchronously I have define a method in this class the movie my data manager class and this should be public tasks returning here okay and this should be a thing as well okay so here of what I'm sorry gonna do is gonna copy the call from the manager class here all of this database related code remove from here and put it into my data manager and here I'll just say data facade dot create movie and record great movies wrong this should be create quality movies as there's a singular and it should be a sink okay yeah should be called a movie good movie okay so the movie manager and here typically for a seamless methodology should also do a configurable weight false it's not about a single age so if you haven't watched that if you don't know sign anything away please watch my other video on YouTube on acing of it honey so that orchestration so before I forget let me paste all the code in here all my data access stuff all right now we don't have air browser methods that would be in our movie manager somewhere [Music] and it's got zero references we can take that out because this court has already been defined or implemented in a certain way that is almost there in terms of levels abstractions so I'm trying to save some time but if you were to write this code from scratch you'd find it be quite a mess by mess I mean all kinds of things happening this one method then there each one at a different level abstraction here to decide whether this is level 1 level 2 or level 3 so I've done some of that work already here all right and I got a method here I've had about a DB powder the exception honey okay so I've got my movie manager that in order to create a movie is two steps validate the movie create the movie done right I don't want to know the how just to what if there's a problem in the validation alcohol there's the problem in the creation I'll go there so I'm not getting muddled with everything else now going with the levels abstraction and orchestration every public method of a class should strive should try it's best to do orchestration in the public method all right so I'm going to go in here and come here say okay well what's this as a code reviewer tell me what's wrong with this balls and then come back and I will continuing to give you the solution here but my my way of thinking about this stuff so what I have here is I mean it's pretty clean for what this mother is trying to do this doesn't fit in here I don't mean that you shouldn't do it I'd time what I mean is this Court does not belong here and not as this for that matter so what I would like to do is have a method that says ensure movie is not now my so I'm just going to refactor this into another method here you remember ensure implies cultural exception so we have that is private and static as it should be and there's a movie here ok so that's good so that's our orchestration coming to life this method here is what's our doing it's ensure no validation error messages okay so we refactor this also into another method and we've got a product ensure no validation validation messages all right so that's that cool so then now suddenly this is looking at a place this is the the fun of refactoring in a methodical manner but you understand abstraction you understand levels of abstraction and suddenly you start to see that said it comes with practice we start to see oh there's no something all right here it doesn't look good in my mind is just saying that doesn't look right I can't immensely explain it even though I'm trying explain it to you I just know there's a problem here it's not like I have to think about it so hopefully that'll come as you do more and more of this work so this should also just be abstracted into another method that says in error messages or something a lot you oops the show HD pen this is a little more complicated so I'm just gonna fix all of this essentially I need all of these messages coming back from here so let me just fix that and get back to you all right so essentially I've just called a method create a method define a method you call validate properties that takes the movie and returns a string and this method is accumulating the error message isn't returning the cut the the concatenated version of that and then the ensure errors in this case only because it's going to if you concatenate null strings better you're gonna get an empty string and I don't like empty strings I don't allow empty strings in my system so that's a big no-no for me but in this method in this example I'm gonna be little relaxed will just mean more work so the insurance saying okay is the length equal not equal to zero if it's if the length is not equal to zero to the problem it can't check for nulls I delete this method here should say okay I'm going to concatenate it and if the length is not lies zero return another instead and then over here on the insurer I just say if the error message is no it is not null throw an exception simple number I'm just simplifying it for now not that it takes time to do that part here anyways anyway the point of this exercise was this public method orchestration again how do you ensure in movies valid well is it no no are all the properties okay cool if there are any error messages from the properties validation throw an exception orchestration steps the what not the how the what not the half alright so you could tell already from our original they say if the manager was level one then this method is level two these methods are then conceptually at level three right but um when I was talking about the three levels could exist as more at the class level but every class even if it's doing a small amount of work can have three four methods that it the one method calls method two calls method 3 it is possible depending on the complexity the idea of levels of abstraction are is not connected to single responsibility or design or where else once you decide that this functionality belongs in a class how do you implement that class you have to follow these ideas levels of abstraction matter what is he doing levels of abstraction apply within the class applies we know across the methods in a class a prize AK applies across classes in a system and so on so it's a universal idea it is disjoint it from design of the system per se it's more towards the implementation of what it is you're doing so we've refactored that our movie manager now looks pretty cool it's just got the the the what's being done not the how that's good all that detailed code has come out of here hmm this is this method not looking right either okay we'll do this as an exercise well but let's check the the path from here to here to the end to see what we can do to fix things if we need to fix anything so facade doesn't do much so we can just close that out because it's just a simple call-out all we need to do a configure weight here as well just an optimization on a problem all right and if you go to the data manager you can see that yeah great movie so here traction perspective one other way to identify is when you're making database calls when you're making service calls when you're making file system calls sending out emails these are the detailed and specialized they are at a lower level of abstraction now you could still have our castration and all the sort of thing there and within this class the data managers working with the database connections and transactions it will still have helper classes to get extra work done not extra work some of its work done that it feels I don't want to know you do it I don't want to know how you do it I'm gonna tell you what I do okay the other aspect that comes clear hopefully when you're working with levels of abstraction the kinds of decisions being made are changing slightly if you remember they manager lead and dev example I gave we're all making decisions just the kinds of decisions we're making are very different when the manager tells the lead to get this work done the lead doesn't question why there's no decision-making process at that level the manager decide that my must have gone through some process in their head and said okay I need to get this lead to get this woman when the magical entails the lead to get this work done the lease not questioning the manager the Lea is going to make other kinds of decisions as to who will get the work to what what should be done next attack cetera and then their lead tells this Pacific dev get this all done and the devs not asking why this has to make other decisions because M you know my writing software there's all kinds of decisions you have to make so but the kinds of decisions we're making are different at different levels for the most part you don't question why you get the job done and while it can't get the job done we're asking questions relevant to that part of the job that level or abstraction so here we are this looks is not bad but that'll like that that there is the command stuff so this does not belong here is to just look at this code here and he says create connection open connection start begin transaction execute the non query commit the transaction that's really all I want to see it I don't want to see this part here still well laid out the code except at this part all of this command part to do with that store prop doesn't belong here so I'm going to be factored that and I'm gonna now have a naming convention for these things I call it create command for and the name of the store power symbols this method is gonna be called create command for create movie so it might sound weird but that's a naming convention I've been following for all my command factories so I'm going to call this come on for create movie create movie being the name of the store prank that's gonna be working for if I look at this and I change the order that I don't like the way it's done this year for me the connection comes first order of parameters or arguments matter at least they do matter to me the connection comes first the transaction comes second and the movie will come third that's all I would alright so create come-on for movie I'm just gonna sort these out okay all right so I went back here okay now this is not typically I would even abstract the exception handling out to our class that's a specialist in knowing what to do with exceptions and hard wood dig into the exceptions I'm gonna leave that in this system for now there are still some code review issues in this code we will talk about then in this specific kind of code and that would be in a different video right now I'm focusing more on abstractions and levels of abstractions and refactorings that are driven by that thought process so from a low abstraction perspective I'm good uses all single things it's not like I don't need to know the how clear connection I don't want to know how you create one just create one open a connection and then care to know how but open it begin a transaction I don't really care to know how you do that but just do it create a command for the store prop I don't care to know how just do it execute don't care to know just do it commit done end of story simple they're at the same level of abstraction but as this method here this method is at a different level of abstraction from the other method which was simply doing the the what and not the how except this was like the how oh well in order to create the c'mon you give me a connection you do this and I said the primer is too much did too much detail for that level so even though this data manager is much lower in the system in terms of levels of abstraction every class has its own idea of at what level it is and again you start from zero so I'm in this graph I don't care to know where this classes in the entire system BAM here and now I need to get some work done I am at tau 0 then and I'm gonna off castrate I might use a helper class to get help me with that that functionality in fact this method here Ashley will be in most of my systems this will be in a different class that's a command Factory and you know systems have thousands of store proc so you can't put all of that in this classiest too much for this one class the data manager so you abstract that out for that reason as well but if you remember I said first refactor to a method right one of my other pet pieces people are always trying for reuse like this sort of imagined reuse I'm saying don't if this was the first one first thing I did in the system I'd say I'm going to put it in this class this method here I'm going to put it in this class yes I may have more of these kinds of things happening in this class I'll do it again for the second one have a rule of thirds I'm essentially saying wait before you start to refactor for reuse in imagine reuse when it occurs for the third time does copy pasting then you have a much better understanding of what it is that you need in your system what the variances are across these three different methods and then maybe your choices not like a method maybe it's polymorphism maybe it's composition you don't know if you leave your decision making to later you have the option to go in different direction in different ways if you immediately say oh that should be a function you're locked in you're married to your solution and not going to change so I'm saying apply the rule of thirds when you do a copy base for the third time at that point sit back think design with the team whatever it is and come to a conclusion D this is you make then would be more informed because you have experienced this for the third time now you can have a sense of where this system is going where the requirements are going and based on that your decision for whether it should be a method or a class is it using polymorphism is it using composition that's all going to be informed by the experiences you've had that 3/3 time over so wait don't jump to a class I see this happening a lot you know people say oh that should be in the class but hang on especially when you've been none of us experienced like that business or whatever it is the vertical you don't have no idea where you're gonna go eventually right even with the user experience I have I let the decision-making I wait on the decision I have an idea I got I'm saying here I know this is going to eventually go into a class called some come on factory run with a wait because if I just did the same thing I've been doing for the last 20 years then how am I gonna grow maybe in this one system something is different and that gives me an idea to go a different out I want that opportunity I want the option to say you know what yes I've been doing this for 20 years but I'm gonna do this differently in this system so I'm gonna way anyway so we've talked about and discussed levels abstraction I've been giving you a code example I'm hoping this code example has further solve the file what does I've been trying to explain here with regards to levels of abstraction and I'll put the I'll put the original code up on my github original meaning the unbe factored version if you want to use that as an exercise to arrive at the same conclusion yourself to kind of see tor happening step by step maybe you can watch this video and repeat so you can kind of see it all happening then that'll be cool nonetheless I hope you enjoyed this video I hope has been helpful I hope I did a good job trying to explain levels abstraction if you like this video please give me a thumbs up please subscribe here and subscribe you can help me help you and you can certainly help me by inviting your friends colleagues subscribing reading comments so my comments ask me questions I'll be happy to answer until next time I will see you what is that No I will see you I will see you next time

Channel: Shiv Kumar

Views: 3,798

Keywords: Code Review, Code Reviewer, Clean Code, Code Quality, Programming with Intent, Programming to Exceptions, C#, .NET, Levels of Abstraction, Async/Await, Quality, Testing, Unit Testing, Design, Design Review, Architect with Intent, Architecture, Code Formatting, Refactoring

Id: Tlu6kAkhXys

Length: 56min 24sec (3384 seconds)

Published: Sun Feb 02 2020