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

Your explanation is SOLID! Thank you.

One thing I really appreciate about your videos is that you speak clearly enough for RU-vid's auto-generated captions to work accurately. Great information, thank you for the video!

Hey Tim, I was approached by a company for a senior position for the first time in my life, and the tech interview is tomorrow. I'm just going over the SOLID principles again and realized I never truly understood any of them. I'll probably get obliterated tomorrow, but still thanks a lot for this explanation! We use similar approaches in our current codebase, but now I'm able to at least put a name to the face of this principle.

Like Kaushik S, said you're the best when it comes to presentations. You always assume your audience may not know much or anything about the topic, so you go in details along the way. That's a wonderful approach. Thanks!

I really like these videos. I particularly appreciate the fact you show the actual implementation by showing/writing the code in a way that isn't overly abstract and simplified. Thanks a lot!

Loved this video, I have watched many videos and read many more articles on SOLID and C# and I haven't found an explanation that is as clear and concise as this one.

Thank you. You make sure to explain the reason behind every decision, and all the other details. I watch some a number of times, and am so glad to be learning C# and watching the contents of this channel.

Thank you for this series. I love the fact that you actually make a interesting example instead of only staying on the theory realm.

Great execution Tim, thank you! I've definitely been violating the O/C principle for a while now, but not anymore. I'm seeing more of why interfaces are a godsend.

Agree with previous comments...exactly what the type of tutorials one needs. Thanks for this.

Great job. Love that the application is not some abstract project. Making it as close as you can to real life helps to more easily understand the SOLID design pattern. Thank you.

I enjoy watching ur videos, it shows a lot of in-depth stuff that we miss, and that u explain what are you doing in order not to get lost.

Another Great video from Tim. Tim looks at things step by step to show this principle and the important practical benefits. Also, lots of good tips along the way to save you getting caught in traps unexpectedly, thanks Tim.

Excellent work, neatly and concisely explained I wish my University had a teacher like you

I like the way you teach, it's easy to follow your thought process, the explanation of why and how, and not too many presumptions.... good work!

I love this videos it so hard to find anything more than basic tutorials and this are just amazing. I understend everything, examples are practical and simple.

Thank you for share your wisdom. This isn't an easy concept, but your class was crystal clear. Love from Brazil!

Great teaching style Tim, so glad I've found this channel!💛💪

Really good and well explained with the code. Excellent work! Loving the series.

Thanks for explaining this principle. All the other videos which try to explain it in 3 minutes fail to explain it completely.

Wow, you amazed me, you have amazing content, very informative and interesting to watch, and you even keep answering question after month have passed. Great job man, you are wonderful person!

I have no word....its awesome, your tutorials changed my coding style.....Thank you Sir...Super Love for You

Hi Tim! Thanks for a good video! Just wanted to comment - that while I do think you're explaining the concept of the open / closed principle good with your example. I also think it shows as why you should be cautious about implementing this principle in the real world. I consider the amount of complexity added to the application a worser tradeoff than a bug or two in the long term. The bugs can be easily fixed when identified while the added complexity might be there forever :)

Great Tim .... you are doing a great job in making C# easier for people

Great and simple explanation of rather hard to get principle. Thanks for it.

Great video Tim. Easy to understand, good examples... Thanks for sharing that knowledge!!

Very nice video tutorials about the SOLID principles. Really liked and enjoyed. Could not refrain myself from subscribing your channel. Would love to see new things. Thank you very much Tim. Keep it up!!!!!

These are things my degree has never taught me. Practical Software Engineering. Thank you for your videos. This is what separates juniors from more experienced programmers and you are helping me with that step! I'm applying these to code in my current job

Ever since I started following you on RU-vid, I’ve become a big fan of your teaching methods. I’m a WPF Developer and I really wanted to know more about Design Patterns. Thanks to your video tutorial using practical examples. Looking forward for upcoming videos on Design Patterns. More power to you!

Hi Tim, thanks for the great videos. I am new and thus these videos are a great help. Plan to enroll in your courses next.

Simple, clear and useful, as usual. Thanks!

Tim, Thank you for making this video. Very clear explanation with examples.

Great explanation. And I finally understood the uses for interfaces. I mean, not how to use them for the advantages of using them. I'm looking forward to start implementing them from now on! Thanks, Tim. :D

HUGE EXPLANETION!! Like a lot your videos. Greetings from Cuba

Great instruction. Excellent, practical but not incomprehensible example app/code! Thanks!

you really do clear up the confusion and the frustration around learning c#. xD

Thank you very much for this video! This was very well explained, I have been able to make good notes from it, and I now feel ready to implement this principle in my future projects.

I really like the clear explanation and the examples used. Have a better understanding of open Closed Principle

Software entites( classes, modules, functions, etc.) should be OPEN FOR EXTENSION, but CLOSED FOR MODIFICATION. With the Open Closed Principle, the code is more robust and more future proof. I understood it all! Thank you Tim!

Practice! Practice! Practice its going to be my goal to be better programming, Thnks a lot Tim for this great video tutorial!

This basically kinda explains why interface is needed. Also what happens if there was no interface in a project!! Learnt a lot. When you first taught about interface and the reasons behind using them, it was actually telling about this OCP. Now it's all clear

A big thank you for your awesome tutorials. God bless you. Love and Respect from India.

Wowwww!!! What an amazing explanation. Highlight is practical examples, which makes this sooooooo goooooood!!!!

Thank you for explaining these principles. Ive done software dev for a fortune 500 company for 3 years and I realized we dont use solid. At. All. Our architecture is gross. Ive been looking to sharpen our apps and these have been a great starting point. Thanks again!

again great video TimCorey

Really great series..."As always"...I come away learning something new.

Really crisp audio in this one, Tim. Very easy to follow along with ( I know you mentioned trying to slow down a bit in your videos before). Well this one was great from that regard!

Awesome approach of explanation - step by step and reasons presented why not to follow a specific approach.

Thanks Tim! This video I liked a lot and I learned a lot from it.

You made a helpful explanation. Thank you, it was easier to understand.

Great video - you got through the video with out mentioning polymorphic once :)

Very nice how you show how to not mess with existing code-base.

Really great explanation. I now understand the concept much better 😊. Only thing that stands out in my view, is the line employees.Add(person.AccountProcessor.Create(person)). So person class injects itself as a parameter. This could be avoided if an abstract base class was used that had an applicant class passed as a parameter in the constructor.

Thank you very much, Tim. You explained SOLID pretty easy. I guess you've found the setting of interface\abstract autogeneration, but may be it will helpful for someone else:to avoid NotImplementedException for properties get;set; just go to Tools -> Options -> Text Editor -> C# -> Advanced -> Implement Interfaces or Abstract Class -> prefer auto properties. Thanks again!

Thank you so much Tim, that was helpful. like always.

Great explanation. Thank you so much.

As always, an excellent video! In your comment to me on the previous video regarding SRP, you mentioned making a follow up video and combining all 5 patterns in SOLID. I think it would honestly be a very good idea, since there is a massive difference between seeing all the "players in action at the same time" and then seeing each of them separately -- kind of like an orchestra; music always sounds better when you have more than one instrument, you know? You sure do explain this a lot better than my old teachers did back in the day. I had hoped that you would have explained the concept of Abstract classes and how they also tie in with interface, but given the way you went about this video, I sure can understand why you didn't -- there is more than enough "meat" on this bone as it stands -- which is good, there is a lot to cover! Also, regarding namespaces, you forgot to mention that when you use namespaces, the final point of the namespace, eg. "OCPLibrary.Accounts", then you cannot have a class called "Accounts" as those things will create conflicts. :-)

Mesmerizing video. You have made my day.

Hi Tim, this specific example made things a bit muddy for me but I still liked the video because I believe I got the message you were trying to communicate through. A great example I came across of OCP is when we were working with certain libraries or assets and essentially in order to expand what the library offers we can simply use an interface they already used in advance. If I'm not mistaken we used this principal on a node based slide system that lets you add new slides without modifying the original library but simply using its ISlide interface. That way you have a new slide node you can employ in the graph as it easily fits the entire system and other slides are not affected since nothing core changes. If it ever comes to it I would love it if you showed us real life scenarios from work you do or you've done that use OCP. Thank you for the videos and greetings from the Netherlands!

Great video Tim! 🙂

Congratulations! Good explanation, very clear.

Learning SOLID, this helped a lot, thanks.

beautiful explanation. Thanks!

Fantastic ! Thanks

I am beginner on .NET which I just started December 2018 but it seems gradually change my style of learning process on how to do full stack .NET web/dev in standard and best practices, all videos are pointing to a very neat and precise coding style. Can't wait new videos from you. Maybe gang of four (GoF) principle? Which I just read 3 days ago.

Excellent video, thanks for explaining this, I was a little concerned with all the copy and paste of the same code, breaking the S in the series, but completely understand why in the lesson, normally as you said you would create a base class :)

Heads up: time stamp through @14:00 explains the problem Open/Closed is there to SOLVE. That segment highlights what you woudl do if we didn't have Open/closed principle, edit your classes all the time to add new features. From @16:00 and on, Tim shows how to implement OpenClosed. I recommend watching the first part as it's a great example of the anti-pattern.

Good videos! I need to write more code to get into problems which requires this decoupling

Really good example!!!

Hi, Just want to commend your work. I've learned a lot from you.

Many thanks Tim :)

Good Explanation with real time

Quality content. Good tips.

Thanks for this!

The best explanation ever

Thank you very much !! your example helped me solve a problem in real life

Great video! To speed up things when implementing the interface, one could select the excerpt "=> throw new NotImplementedException()" and CTRL + H then ALT + A 😅

I love your chanel. Anyway, for those who don't know, Acme produced the anumation cells and its use in the Road Runner was an in joke by the WB animators.

Nice video, thanks! I think that writing code with OCP in mind, helps a lot, since it makes code a lot better. But if you start from a project that is already in production and not developed thinking about OCP, it will be really hard to make changes without changing what is already working. But, even if its working, you have to change code when you want to refactor. And, Unit Tests should be here to help us not to introduce bugs on working code. The point is, I think we have to write code with this principle in mind, but don't overthink or overdo it. Thanks for the video, it helped me a lot to clear this concept! :)

Great video!

Good explications, thank very much.

At 32:00 you could use “composition” and have ManagerAccounts take an Accounts class in its ctor which calls create. Could also be seen as a decorator.

Thank you! Good explanation :)

The video is published more than 2 years ago, but Tim still keeps replying to comments.

You are a hero :D

Awesome Tutorial

Hi Tim, this is your customer. Thanks for providing the new software version, it's great! Anyway, we just now realized that humans can have middle names! Could you please add middle name support by tomorrow morning? I know it's a tough deadline, but since we spent the whole last year refactoring everything to be SOLID, I'd assume such changes can be done much quicker now and there are fewer places to touch, so less stuff can break. Thx and keep up the great work! ;-)

Very good. With regards to keeping your interfaces alongside your concrete classes. Once you are writing a large Prism or similar 'modular' application I have learnt that is not best practice to do this. Normally we will put interfaces in a separate 'Infrastructure' project. This way once you are leveraging dependency injection & using an IOC container to inject dependencies you do not have modules being dependent on other modules, rather modules that need to resolve those types can reference the 'infrastructure' interface module and the concrete types are then resolved at run time. This way a module can be used by another application and achieves real separation of concerns. Obviously this is out of the scope of this small example application...

The best explanation on RU-vid!

Thanks Tim

Thank you!!!

This clarification really saved the day for me, Mr. Corey! I still learn, but feel like understanding quite well a lot more thanks to Your videos. Just to note: I think that it makes sense to use enum with flags in EmployeeModel class instead of those boolean properties like isExec, isManager etc. Is that a fine sollution?

Thank you!

great video and the comments are also helpful.

Thanks!

[48:03] I'm quite glad you actually mentioned using base classes, since it's how I create quite flexible, extensive things. I was honestly starting to think you were just all about turning everything into interfaces. That's no better than turning everything in C++ into templates. LoL

Hi Tim, I'm working through your C# App From Start To Finish, and digesting some of these other videos, and this is all great stuff; thanks for this. I'm a long-time VB hobbyist (I can't say I'm a pro developer even though I have quite a bit of code here and there in macros and smallish apps at work) and I'm trying to transition to C# and to think more in OOP. I'm struggling with Interfaces (saw your Interfaces vid) and this compartmentalization of the code. (I come from a world where *everything* was in the frmMain module... ;-) In this particular video, I would have approached it as using an Employee object, and used an employee.ActivateAccount(applicant, empType) method, where the empType is an enum. Then, instead of adding an entire set of interfaces and models for a different type of employee, you just add a new entry to the EmployeeType enum, and add a new entry to your case or switch block to implement differently where necessary. You're not necessarily changing code flow nor are you touching existing logic, but you are adding sections in a somewhat safe manner. I get that this is just a simple example, but if you have to recover from not allowing for different employee types (i.e., a big requirements hole) you're gonna have to tear into some code anyway. Also, while I understand that you should have different classes to represent your various objects, to have different classes to do different *things* seems strange to me -- wouldn't you just implement different methods or properties for the class? I have a nagging feeling that I'm missing some higher level understanding or approach; perhaps you need a few PowerPoint slides after all... Keep up this great work. I was floundering until I discovered you. Regards, Renny

Thanx for the excellent explanation. Even though the changes ofcourse are still perceptible to bugs as you had to rewrite everything to interfaces, and then did not change the original names of the 'base' classes which might make it easy to mistake (like PersonModel should have be renamed to StaffModel and the Accounts to StaffAccounts because otherwise in the future it could be mistaken for anything else). Also it's easy to say, now you are confident to add a new employeeType.. But to be honest, if the original Accounts was implemented with the switch, I also would be confident to if I had to make a change, as it wouldn't really matter if I had to create the original PersonModel with EmployeeType set, or if I had to set a new Model. The problem now is that if there is one slight change to the 'PersonModel' you have to change ALL your other classes too instead of just 2 classes (PersonModel/Accounts), so it might introduce some more bugs.. So yeah, it solves one problem, but it also creates another which you wouldn't have with the first way of implementing multiple employeetypes.. But maybe it's just me that IS confident in making changes to things like switches etc. and wanting to actually see what happens in different cases at that point (for instance the differences between emailaddress creation). Also if this was a big application, it would have been hell if you went from everything in one folder with the OCPLibrary namespace to separate folders and NOT have it have OCPLibarary. namespace and then later have some folders to have it as a namespace. That would make it really confusing, and in the end, changing namespaces of the library after it is in production you get the problem of the other projects might have to be rebuild again and having problems with the namespaces. Also in this case you called the folder Accounts, but we did have a class named Accounts and it created problems with the TechnicianAccounts class which was created in the Accounts folder, and that made the original Accounts class get a problem with having the same namespace as the original Accounts class wasn't in the Accounts namespace. If the Accounts class would have been names StaffAccounts it wouldn't have this problem BUT you would have problems of some ...Accounts classes be part of the OCPLibrary namespace and some of the OCPLibrary.Accounts namespace which ofcourse is very confusing. (Just like my text here, LOL). So in the end, you always have to be careful if you change code/namespaces after it's already in production, no matter which principle you use.

Great explanation

During your lessons i improve not only programming skills, but english skills too)