Design Patterns: Open Closed Principle Explained Practically in C# (The O in SOLID)

when you were writing code are you doing it right that's the question that worries a lot of people and should probably be at least something that every developer thinks through design patterns are best practice concepts that we can implement in our code to make it better in some way think of them as guardrails to keep our code safe in today's video we're going to be looking at the second entry in the famous solid principle the O stands for the open closed principle it states two objects should be open to extension but closed for modification we're gonna look with what that means practically we will also discuss when this principle applies and when does not and how far we should take it for those of you who don't know me my name is Tim quarry and it's my goal to clear up the confusion and frustration around learning c-sharp because learning software development shouldn't be so hard if that sound it's something that would interest you I think you would benefit from subscribing to my channel you'd probably also benefit from join my mailing list where they get exclusive content and insider access the link is in the description below so let's start the conversation on the open closed principle which we're going to call OCP from now on by looking at some code as you know instead of doing PowerPoint and cool images to try and represent this principle in theory I like to dive into the code itself to see in action in the real world so here I have a project I created in visual studio in c-sharp now the principle is this video apply to any software development language but since this channel focuses primarily on c-sharp that's the language around use so I have here one solution to projects I had a console user interface and I have a class library if after this video you want to see the source code no problem there's a link in the description below that will take you to a blog post that I wrote that has the download for this project as well as some snippets pulled out to kind of highlight what we did so the job of this console user interface is fairly simple we have here you is we're creating a list of people we're calling them applicants okay so this person model is just a very very simple first and last name that's it so we're gonna create three of these people and add them to the list now if you haven't seen us before in one line I'm initializing my list of person model and adding three new instances of the person model to that list next I'm moving up a couple of items first of all list of employee model which is right now empty and this account processor called accounts so let's look at employee model first employee model has three things first name last name and email address now again this is a demonstration it's not a full-featured application but I want to give you something you could actually kind of see and think about in the real world so what's gonna happen is this account processor it's gonna take these people and it's going to convert them into employees think of it as these people who applied at our company and now we're gonna give them jobs and so because we're gonna hire them we have to give them an employee account and so we'll take their information we have the first and last name and we'll create an account which again is simply first and last name and an email address I have a tool to do that for me it's called the account processor and it's got one method in it called create so let's look at that under accounts we have this method called create that takes in a person model and returns employee model and all it does is creates a new employee model it adds the first and last name from the person model as the employee models first and last name pretty simple and the email address it says okay well take the first that substring zero comma one just as the first letter of the first name and then right away the last name and then at Acme comm I just chose Acme a Tran that's a big Looney Tunes thing as a kid so if Tim Cory comes through this we're gonna get tea from my first initial and then Cory so it's getting T Cory at Acme calm it's my email address so that's all it does if you look down below we have us for each that loops through and now created employees say first loop through and and took every applicant and turn them into an employee I didn't create an atom to the employees list so I take every create employee and I just loop through and say show me your first and last name and your email address that's it so if we run this it's pretty standard let's actually run that again so the fonts a little bigger I'll change the defaults and there we go so it's pretty standard it says you know Tim Cory has now tcorrea Acme com Sue Storm has s storm acting calm and Nancy Roman has and Roman at Acme calm all right so that's our setup that's where we're starting from today now the open closed principle says that we should have the ability and let's just focus for right now on the accounts class that's that's me our focus for today that this should be closed for modification but open for extension ok so what that means is that we shouldn't be changing this stuff once it's in production ok it works so if a new situation a new scenario comes along we shouldn't have to change this we should just extend it but let's see first what that new scenario might look like so let's say this is an application that's running in production we're creating your returning applicants into employees it's processing that's great probably it's account methods actually doing more things we're just again right now simulating this doing more so we're creating all this account information that's great but the boss Commodus and says well actually we need to make a change it's ok what's a change well some of these employees coming in are management and we want to have a way of identifying that an employee is a manager now right away you may be thinking well we can create a different class called me manager model where that inherits your employee model that has extra managerial stuff we could do that we can go really deep into inheritance which can cause some nightmares and that's really not the focus of this so I'm gonna say we're not going to go into changing everything at how we do things but I could implement some time inheritance system we're not going to have multiple layers of things instead we're going to do is all to really need is to have two extra properties here actually is one exit property right now the 1x your property is going to be this ok a boolean that just says is manager that's all I really care about and the one other thing we're going to do is we're going to set this to have initial value of false so by default you won't be a manager now right away you may be thinking wait a minute didn't you just violate OCP in some ways yes I did because this class was needing modified it's an existing class is running and I modified it and this is where you start talking through when is it a good idea and when it's not a good idea to implement OCP the very first thing i want to talk about is if you're in the develop process this doesn't really apply and by that I don't mean you shouldn't design your application to be compliant OCP but you're in a develop process things are going to change all across the board in your development and that's okay what you want to do is once something goes to production the only reason it should change is because there's a bug in the system or at least that's the general rule and that would still be okay because obviously it's not functioning ways intended therefore it should be changed in easy modified but in this case I'm making a change that is a minor change and from my perspective it's okay and here's why if I run this application right now having added this boolean watch what happens nothing has changed and the reason why is because I'm map I'm not depending on this property in here it doesn't change how I processing works nothing okay now there is some changes and it does require recompile but it would anyways so with this being a minor change I'd be kind of okay with let's change the model it's okay but you can say you know I don't want to do that in which case I'd recommend changing the model anyways but instead of changing the model here you just create an interface for this model and then create another interface called say you know I'm manager that has the extra property or something like that so there's ways you can do it it all depends on how much of a change it is and whether or not it's gonna cause some braking issues down the road so in this case it's not gonna cause braking issues so I'm like you know what it's okay but what I can do here is I can modify my console output just to reflect whether or not they're employees so I'll do a space and I'll say I'm sorry managers I'll say is manager and then the value alright and that's just more for our purposes so we can see whether or not they're a manager and of course all three or false they're not managers so the bosses come to us and says we need a manager flag added so you come in here and say okay well the accounts processor needs to somehow know their manager and that means we need to tell it some way so he can come here to a person model and we'll need to add some kind of identifier well let's do that so let's create a new so we'll add a new class this is how I do a news I call the class in news and I delete the class itself okay not the file just a class and then I have a file over here called a neumes that always has all of my anu Merivel section that way it's really easy to find and I don't really think that in news need their entire an entire class file dedicated to them but that's again up to you so let's create a public in oome and we'll call this the employee type and we'll start with a general employee which was gonna call staff and they'll have a manager cool so now over here we can say prop and it will be that employee type and we'll just call this type of employee don't just call it type that's a little too on-the-nose can cause some some conflicts in the naming so let's call it type of employee all right and again by default let's go ahead and set this up to be a staff member so yeah nothing has changed so far in our application if we run this everything still runs as expected so again another one less changes that definitely break anything but we need to have some way of saying okay if their damn manager we need to set that flag to true so this is where that open closed principle we want to really target in on this and look adds how can help us so in here in this logic we now say if and this is person dot type of employee equals employee type manager then out spell output dot is manager equals true okay so the that now makes our change but we have violated OCP by modifying this method so we can do now is just to demonstrate this works let's set su to be a manager so is our type of employee equals manager and now if we run this sure enough sheathe and marked as a manager so it works but we've had to modify the code that was running just fine to make a new change and now our manager comes back to us and says you know what we actually have a third type that would be the executive and say okay so you come out order enews or an ad executive cool and you go in your employee account employee model and just to represent it we're gonna say public bool I pressure that problem there you go bool is executive and again not a huge change it's not gonna break anything if we run this right now you know nothing changes and if we let's go over here to the end and we'll do the same thing as before we'll say is in executive EMP dot is executive and again that it's demonstrates to us whether or not we've processed this person as an executive and both of those are marked as false so we've got this issue now we're looking at and say ok now we got a modify existing code which already works and that's in this this class so we go ok so now we have to have you know another ifs in and then we have the brilliant idea wait no we don't we could comment this out and we can do a switch tip so you say switch on person dot employee type of employee miss the cool thing hit enter and it creates all three of those different level because that's the ANU and it's ok you know for for staff member we're gonna do nothing for manager we're gonna do output let's pretend like we we've forgot to do this just bear with me go executive ok we need to do output dot is executive equals true cool and we hit start and this is what happens everybody's false well sue was a manager what happened well we forgot to put that code back in we took it out because we were gonna do a different way and so he took code that was working in production that we had relied on and now uh so we've we've had to modify it and reintroduce bugs into it and that's a problem so we have to come back in here and say ok output dot is manager equals true they also say you know what actually an executive is Amana therefore we should also say he is manager equals true for an executive and now we're back to working for Sue and let's go ahead and change Nancy Roman to be an executive and we'll hit f5 and now we have Tim Cory as nothing just a staff member Sue Storm is a manager but not an executive and Nancy Roman is both a manager and an executive so we've made a modification of the code the code works but we've introduced bugs into an existing system and we've endangered what we already have working in order to add a new feature and that's what really what the open closed principle OCP is trying to help us prevent and that's the idea of if it you know the ain't broke don't fix it so if it's already working don't modify it in such a way that you introduce potential new bugs into your system so let's reimagine how we could do this accounts processor in a way that will allow us to not violate this principle now the first thing I want to do before I just start saying okay we're out implement OTP I want to think through what really has happened that's caused these issues like where have I started make changes and compromises and I changed a lot of stuff if you notice that I had to change the accounts class I had to change the employees model I had to change the person model and I had to change this program CS that's a lot of changes to a system that's already working so let's go step back from it and look at can we do this in a different way that allows us to keep things from changing too much or at all when we bring something new in like for example if they say ok we're gonna have technician be a new person type well now I gotta add our own you know add to the Noom we've got to modify the accounts controller you gotta modify the employee model and so on now the employee model let's start there the employee model I'm using those ministration I'm saying you know this is what happens when an employee gets created and so I'm using this is manager is executive to identify that yes these things are changing as part of the process but really actually the truth and baked in originally and also maybe it's not but you have a flag called is manager but maybe you do some other tasks that we're not really reflecting here but you could be doing like going out and creating different accounts for ism this manager or setting up a system in HR to allow them to have direct reports all that kind of good stuff we're just representing it by the the boolean is manager is executive so I'm going to leave that those changes because that's just more of an indication for us what's happening but all the rest of stuff this is messy okay and you saw how quickly my really simple application went from simple to messy so we're going to kind of undo as many these changes as possible so let's start off by knocking these people back down to just normal employee we'll leave the the for each console.writeline these are gonna keep those those flags there to tell us what's going on but then I'm gonna come over to accounts and we're going to say you know what no get rid of all this stuff here because this is just way too complicated and we're making too many changes because of a change in circumstances in fact the ANU that's gonna go away we don't need to have the ANU Mets get rid of that as well and the actual anemia anymore all right so it kind of back to square one before the boss came to us and asked for us to make a change to allow managers and then executives now the first real big way to make sure that you can implement the OCP is to not tie yourself directly to classes and I've tried to avoid that too much because we're gonna get into that really heavily in the D in solid okay so that's video five in this series but if we're not tied directly to a class we can make some modifications and how we do that is I actually create an interface an interface will allow us to add on to this with other classes actually use other classes for implementation so let's do this let's go to a person model I'm gonna show you a quick tip or trick if I select the class and I hit control dot or drop down this little lightbulb here one of the options is extract interface this is really helpful because you've start going on this path a Korean class and you realize you know what I don't want to have that firm coupling I want to have an interface that I work through and so I extract an interface and I'm going to call it instead of I person model let's call it AI applications better I probably should name the person model the applicant model but that's okay I'm not going to change that because that's how we started and I'm simulating the idea that with coming to applications already working and one of things I wouldn't want to do is change a models name halfway down the road after it's already working unless I had a real reason to so this exact create the I advocate model if you don't know much about interfaces I'm gonna do a dedicated video to it at some point I do have a much older video that sorry about the quality it's kind of poor beause actually for just my on-premises class I was doing a quick and dirty hey here's interfaces so you can check that out it's on my youtube channel kind of buried but essentially an interface is as a contract and so I create a contract for an applicant model and it's gonna have the first and last name properties and that's it they create it for us so now we have our interface which again as a contract and we can actually implement that on the person model which is already done which is really nice it's ok the person model is an eye applicant model or implements the eye a pleco model not sorry that is it implements the eye applicant model but there's one more thing I want to do and that's come over to the accounts controller and do something very very similar first I'm gonna say instead of taking a person model we're going to take in that eye a packet model again the contract but that doesn't change anything here it still all works but now I also want to do one more thing I want to create an interface for accounts so again then select it I'll hit control dot this time extract interface so I accounts you know just to have that create method in there we hit ok that's now our interface and accounts has implemented it okay so got we just extracted interfaces for our two classes and now the one last thing gonna do to kind of make some modifications okay actually gonna add one property here and yes I have to make a modification to my model it would have been good if I had done at the beginning but I didn't think through how to implement OCP now I'm coming back here and simulating implementing osep and yes I have to make a modification but I'm gonna make one that should not cause any problems with my existing code as a prop and I'll say I accounts I will say account processor okay so that's gonna be my my one extra thing in fact I'm going to put this into my contract as well so let's just actually copy this and go to my contract which is my I applicant model and add there as well so now every person model will have an account processor I'm sorry every applicant model so for this one I'm just gonna say equals new and this is going to be the actual accounts okay so that's an actual firm implementation of the I accounts interface is that accounts we've been using before alright so hopefully I haven't lost you yet but essentially I've done is just create extracted interfaces for everything and then in my person model I said I'm gonna have this accounts processor property which again I put in that in my contract as well it's an I accounts and for the person model which is again that base employee I set that to be the accounts class how this gonna help us well right now we have again still tie to the person model not I person model so we'll work on that but instead of having this nude up accounts processor variable ray get rid of that and instead of a counts processor we're gonna say person dot accounts processor dot create person okay so we're using the class instance that's in that class model now I haven't change anything else yeah I haven't even set us to eye personnel which I will do but let's just run this and see that it works okay it works everything works as it used to which is good that's we want to do we won't have any disruptive changes so now let's set this to be the I accounts model I'm sorry I applicants I applicants model all right and it's yelling at us and that's because we have a firm implicate implementation over here so again we'll say the I a platoon smaadahl and now we're good notice we haven't changed the new person models those still go right into the I applicant model list because they implement the I applicant interface how does this help us well now when the boss comes to us and says I need you to give me now managers no problem boss I'm gonna take the I right-click on my prop my project and say add class I will call this manager alright our manager model I make it public and manage your model implements the I applicant model I hit control dot here to implement the interface and there we go now the one thing it does which I'm not a big fan of is it sets the get in the set to have thrown ooh not implemented exception so we can just take those out what's trying to do is make sure you review are getting set to make sure that we don't need to change it to something else okay so there we go but now remember in our I person mop or item tire a person model we set that equal to new accounts we're not going to do that here we're not gonna go into the accounts class and make changes to it that's gonna stay unchanged when I got to touch it instead we got right click on my project and say add class and we're gonna call this the manager accounts let me get public you know how to implement the I accounts interface again control dot implement the interface and there we go so now I can put code in here for how we create a manager so we can do but you actually go over to our accounts class and let's just start with the COBE already has let's copy this and I know I hate copy/paste and so don't don't freak out on a copy paste because yeah that's a problem that's not something should do if it unless it really makes sense in this case both for Speed purposes and also because we're gonna keep a similar logic what that also means right now is since I copy and paste it this now isn't totally dry compliant don't repeat yourself and so actually thinking about maybe creating a class of the method that has you know base creation I could inherit from a base class but I don't want to do that in this case I don't want to have a base class called a count and then have you know staff account employee or manager account and executive account but I could do that have some base logic in the base class and then implement extra logic down here but the reason that one do that is because I'm thinking there's gonna a couple changes first of all for a manager maybe you want to have something a little different for a name for example mate we want to do is we want to put add them at a different domain you know Acme Corp is there a corporate alright so now I have to change that as well and so that's that's why I don't want to have that inheritance in place but I also want to do the output dot is manager equals true there we go so now I've created a manager accounts that sets the manager up the way we want during the creation process okay so now in my manager model I say equals new manager accounts it still implements that interface so we're all good so now over here instead of person model for Sue Storm I can say well actually if this is a manager model though as it still implements the I applicant model interface and therefore it goes right in no problem if I run this notice that Sue Storm is now mark as a manager okay so the existing code still works but now we've added new code and we haven't made modifications especially not to our account model that's all stay the same or yeah I'm sorry account class that's almost there saying we haven't changed how it works instead we've done is we've worked against interfaces which we're going to do a whole lot more I think I said as we go on in these practices but what that allows us to do is it allows us to say well instead of having a list of person model we have a list of I a pleasent model and they can put any type of model in here in type of class that implements the I applicant model interface so now we can have both a person model and a manager model and so when the boss comes to us and says actually now we have executives no problem boss right click on the project add class executive model and we're make it public and will say this is the i-ight applicant model again control dot there's my my three things again I'll take these out I could have copied and pasted from another one I probably showed us because it's kind of pain it cleans up but that's okay this is Microsoft's way of saying let's make sure you're safe about this you need to at least look at every one of these things and that's a good thing they're trying get you a look at all these things and make sure that you've done them right okay so now I enter again right click on my library alright sorry my project and say add class and it called this the executive accounts so it's going to create executive accounts instead of manager accounts or regular app or people accounts whatever they're called just accounts there you go subject counts so this is the I accounts interface so I implement the interface and we have let's go accounts we're gonna grab the same again this shows me I needed to have some dry work done we're gonna cover that in another video but if you have this copy-paste going on at least think about how you can eliminate that as much as possible if not entirely sometimes you just have to have a same code more than once it's okay but if you're doing a lot or if you're don't have a great reason why you're doing it then you probably should look at refactoring again this person is Acme Corp but because they're you know such bigwigs where I use their first name dot their last name so instead of having it be you know T quarry or it's gonna be instead Tim dot quarry at Acme Corp calm and again we're going to say outputs dot is manager equals true output dot is executive equals true though it's not endangering and existing code is all I do all that I'm going to do is change this person to be an executive so it's an executive model so Nancy Romo is now an executive with that change if I run this I throw an exception excellent and they catch why all right think about for a second and I'll show you all right go back to the executive model I set up this I account account processor but never actually initialized it equals new executive accounts alright that's that's what actually does the processing of the account now this time we started Tim Cory is not a manager is not an executive and his email addresses tcorrea Acme comm sue storms email addresses s storm at Acme Corp comm and she is a manager but not an executive Nancy Roman has an email address of Nancy dot Roman at Acme Corp comm and she's a manager and an executive so that's how we can implement the open-closed principle the idea that we're not going to dip into accounts and start making changes every time we have a difference of of what we want to do so you know this used to create just basic ounce and then you add managers let me add executives we shouldn't be coming back in here over and over again making changes making changes making changes if we are that's we call a code smell the idea that there's a problem here so instead we work off interfaces and interfaces allow us to change out the actual implementation so for the accounts we now have just the accounts implementation we have the executive accounts and we have the manager accounts each of these does something different in the create method and yet all can be called by saying you know I accounts dot create because that interface says yes this is the contract they have a create method and on the person's side we do the exact same thing instead of having person model we're now I can't model and that's extracted way so we don't really know is this person a person model are they a manager model are they an executive model doesn't matter because we know they implement this contract and this contract says they have a first name a last name and email address and is manager and is executive and so because that I'm sorry they have a first thing that last name and that's it right yeah so because they have those two things there you go in the account processor because they have those things in the contract we can use those right here to build our employee model which now this is tied to an actual model this is not tied to an interface that might be something to go back and change but for right now it's okay so I hope you've followed along this is a little bit more of a complex example because I wanted to get beyond just the examples that that are really neat and tidy and don't really fit because when you get into the real world this is the kind of stuff you got ran to you got to look at and go oh man it's a mess but how I ever implant OCP in this situation the first thing is is take a step back you know breathe think it through look at what's what's gonna have to be changed every time one of these situations comes up and then think through is there way I can stop this really tight coupling of you know this used to be person model and so how can we stop this tight coupling so that we can do things like have a manager model or executive model instead of a person model so we never change person model again and so the same thing can be true for our account processor how can we disconnect that from a specific implementation and allow us to say well for just a person model that's the accounts class but for an executive model that's actually gonna work on the executive accounts system now one thing you noticed is this stuff really got I would say more complicated it may it did but it got more larger as far as files go we now have a bunch more files we used to first of all I wouldn't keep them all here and in fact let's do some cleanup here so I'm gonna right click and say add folder this first folder I'm going to call let's call it accounts and then I'm gonna drag accounts in there and I'm going to drag executive accounts in there and I'm gonna drag the manager accounts in there and even the aiya counts into there and then I'll right click again on the project and say add folder and this one we're going to call the applicants and I will drag the employee model I'm sorry I didn't pull out the executive model the eye applicant model the manager model and the person model all right so now that's a little more organized so now we're talking about the account processors or how we create accounts that's all in the accounts folder we're talking about different types of applicants that's in the applicants folder including their interface now you could put all the interfaces together but I find that just grouping grouping things by type doesn't really give you a whole lot of benefit there's some but I really like to have the things that work together close to each other now one thing a note before I go on this it just wants the side notes that it's gonna help you because you're probably on stumble across this if you use this system let's say I'm gonna create a new type of applicant called technician so I right click on the folder now and say add a class and I call this the technician model and I'm going to make it public and it's going to implement the I oops implement the I applicant model now instead of doing the control dot here I'm gonna learn from my previous issues and is copy and paste and now that satisfies a contract and let's pretend for a minute that the technician doesn't have a different processor yet so I'll leave that alone the one thing I want to point out let's do a comparison let's close all the others first let's do a comparison between this and the person model I'm gonna put them up on top of each other so a new horizontal tab group okay do you notice anything different about these two models I know it's a little little tight here but take it take a minute to look at this there's one change that is significant and that change is the technicians model up here the namespace is OCP library dot down here is just OCP library and the difference is did I drag the item into the folder or did I create the item in the folder already so because I the folder already existed and then I created this item inside the folder it changed the name space to include the folder so now it's OCP library which is the project name and then applicants which is the folder name and then your class that will that may throw you for a loop sometimes just make sure that you know the difference between a two but here's the cool thing namespaces you can change them okay so I say you know what I want them all to be the same or may I go the other way and say I really want to have that structure so I'll do it for all the items in this folder so go back through and change all of these to say dot applicants so it's up to you just know that will mess with your using statements you'll have some some issues there so just think that through how you want to do it but just note that it will be different if you create something new in here versus if you create the root and then drag it in okay so that's the open closed principle it talks about the idea of being open to extension but closed modification so our and we really focus on the accounts part of this the account dot create so our accounts class initially when we started making those changes we changed everything okay we we modify as we had if statements and switch statements and we're changing things left and right or making or introducing bugs and all the rest but when we went back and kind of redesign up a piece of this application so we actually didn't modify some things but once we did now our accounts class doesn't have to change ever unless there's a bug and instead now it's closed for modification but it's open for extension so the idea is if we add new type of account where it's processed differently we can use the interface to allow us to bring a new class that use the same structure but has those new features this is not the only way to implement the open closed principle we could have a guess to create a base class and then have different things inherit from it and said okay accounts implements is is a child of this based abstract class called may account you know singular or a count processor or something like that and then we have you know the the base account we have the executive account we have the manager counts they all implement from that one base class that's another way of doing it I'm not as big a fan of that usually because it doesn't give you as much flexibility as say the interface method does with that being said it's not about the concrete way you do this because even different languages may handle things differently it's more about the concept and the concept is we don't modify the account class instead we extend it or change it or we either inherit from it or we use the same interface so that we can grow our application and add new features without changing working code now one thing I'll point out is that this really works hand in hand with our first video in the series on solid and that's a single responsibility principle instead of having a class who is responsible you know account was becoming for this create method it was becoming responsible for creating regular employees managers and executives so it would change for three different purposes it would change if the way to create normal employees changes it would change if if the way we create managers changes and it would change if the way we create executives changed and so now what we've done is we've separated those into three separate classes accounts executive accounts and manager accounts and now each of these will only ever change for one reason and that's if the way we create say in this case I think an executive the way we create an executive changes that's the only reason we'll change this so now we are better implementing single responsibility principle and we're also implementing the open-closed principle in that these things don't change when new features get added all right so that's it that's that's OCP my my encouragement to you is to practice I know it could be a little bit complicated sometimes I know it can be a little daunting to see oh my goodness there's tons of changes yes that's because I wrote the application poorly and I had to make some changes to allow it to implement OCP correctly once I did that then there wasn't all these changes I mean you could probably feel pretty confident right now in adding that technician because all you do is create a processor for the accounts and then instead of an executive model or you know or a person model we say technician model and we're done that's it so this really us to make our applications more robust and allows us to be more confident Cody right and all the code we're writing is very very small we're just making small changes based upon our new circumstances so I hope you've enjoyed it practice practice practice the more you practice this the better off you'll get the more comfortable you will be starting off with OCP already in your code and it also SRP don't forget that one so these two things imp main your code your code will be cleaner leave it'll be more streamlined and be more future-proof when it comes to changes I hope you enjoy it leave me a comment down below what you thought and as always I am Tim quarry

Channel: IAmTimCorey

Views: 128,668

Rating: 4.9134774 out of 5

Keywords: .net, c#, c# training, c# tutorial, code, design patterns, design patterns c#, practical design patterns, programming, s.o.l.i.d, s.o.l.i.d design, s.o.l.i.d principles, s.o.l.i.d principles c#, s.o.l.i.d. design principles, solid, srp, tim corey, training, tutorial, visual studio, ocp in c#, open closed principle, open closed principle c#, open closed principle explained, open closed principle tutorial, uncle bob, uncle bob martin, solid design principles video, open closed

Id: VFlk43QGEgc

Length: 52min 32sec (3152 seconds)

Published: Mon Apr 02 2018