I appreciate your time spent putting this together. It was very helpful for quick review or teaching this concept to new developers. You are easy to understand because your speak clearly and you explain your thought processes. Well done.
Thank you for what you do Tim. You're one of those people that get to the top and throw the ladder down for everyone else. I hope you have a happy life.
0:00 - Intro 1:33 - Demo code overview 1:56 - Single Responsibility Principle: SRP explained 5:09 - Implementing SRP: Refactoring demo code 24:38 - Recap 25:28 - Summary and conclusions 29:45 - Why many classes is not a problem for your application 31:29 - How to keep a balance: creating to classes, when to split up a class 33:23 - Concluding remarks
"If you have to scroll you've probably done something wrong." I think this statement is a bit exaggerated because it's hard to have small classes in large programs, achievable in small ones. In some cases there is a lot of functionality revolving around a subject and moving code out of the class to keep it small would break another important principle, that is cohesion. I think of classes as nouns and of methods as verbs. In my opinion the single responsibility principle asks us to put the verb/method in the right class/noun. Before starting to write the code for you program, think about the nouns and verbs that are involved in your program and structure your nouns into systems and subsystems, in other words lay out the skeleton of your program.
The problem with long methods is that testing is a mess. If you have one branch in your method, you need to write two tests (one for each side of the branch - simplified, of course, since there may be more than that to write). However, if you have five branches, the number of tests you have to write to fully test things can be exponentially more (not just 10).
@@IAmTimCorey Thanks for the video on SRP. I am working on expanding my coding horizons and your videos do indeed help. I must agree with Janos. While I strongly agree with your sentiment to keep classes small, "If you have to scroll, you've probably done something wrong," is is simply not true for non-trivial programs. When I went to college in the late 80's, the rule-of-thumb was that a function, procedure or method should be no longer than a printed page. I try to maintain this guideline while writing new code and refactoring old. However, in more than 50% of the code I handle on a daily basis, this limit is difficult to accomplish. Complex algorithms require complex code at times. Trying to bend a large program into classes that will not scroll, in my opinion would be like watering my garden with a teaspoon. :-) On the other hand, I have literally twitched after first review of an old program with methods that were thousands of lines long. Yes... one method was more than 2000 lines by itself. Debugging was a nightmare. There is one other minor comment... You said nothing about multiple method exit points. To avoid confusion, especially in programs that have been heavily modified by several programmers, maintaining single exit points can be extremely helpful. Thanks again & keep up the great work!
Agree. This is excessive. We have an internal rule on methods being more than one scroll but having this policy on classes in just not right. SRP is basically just decomposition of your methods/classes into smaller and discrete units of work. The trick is to not go overboard with it and to find balance.
Hello Mr. Corey. I just found your videos and have found them most helpful. Thank you very much for sharing your knowledge freely and openly with the rest of the world. It is people like you that restore my faith in humanity. Best regards from Mexico.
I always disliked opening my old projects because I know the horror I will face trying to change something, this explains so much. I think it's time to revisit some old projects and try to apply this now. Thank you Tim.
LOL I Scroll On My Visual Studio Like a Book. Thank you for making me realize (in a simple and objective way) how much I have to improve, as a programmer!
Of all the videos I have watched on this channel, the Design Pattern series of videos has been the most helpful for me personally, and it explains why teams often fear making even small changes in code, they know that a minor change can easily cause a massive cascading effect. I have been in dev meetings where the decision was made to leave in dead code simply out of the fear that pulling it will have unknown long-term effects, even if all code testing indicates there are no calls being made to the dead code.
- Beautifully crafted explanation of Single Responsibility Principle. - Depth is what I like the most in your tutorials Tim. - Along with the principle, we would also like to hear your personal experiences on SRP. The challenges that you've faced while following SRP in live projects.
I appreciate the kind words. As for my experiences, I'll add that to the suggestion list. In general, my experience is that it really helps make the application easier to maintain. It is hard to do well sometimes and sometime you cheat, but doing it right pays off in the end.
I know this is an old video series, but I have been searching for a while now for explanations of design patterns, and just anything related to coding really. Trying to get a better grasp of reasoning and how to go about solving problems. You're videos explain things so well. I honestly think these videos have had the biggest impact on my skills over any course/videos I have previously watched. I genuinely thank you for these. You wouldn't happen to have a programming course by chance? lol
I do have a lot of programming courses at iamtimcorey.com. If you are looking for a beginner to advanced C# course then the Foundation in C# course is the right one to start with: www.iamtimcorey.com/p/complete-foundation-in-c-course-series
Incredible, recently I've spent a some of my time researching/learning new design patterns. Few days later, just when I needed it the most, this video appeared. Not too long ago I was struggeling with Unit testing and the same thing happened! Your timing with your videos just couldn't be better! Thank you so much for creating these educative videos for us over the years. I realy appreciate your efford.
Excellent. Well, there are more design patterns coming. I will finish out SOLID first but then I will be covering other patterns as well. I am not sure when the videos will come out yet. I am still working on my production calendar. I have so many videos I want to get out but I need the time to get them done. I am not done covering unit testing yet (I will be covering mocking next) and I am almost done the prep work for my .NET Core series too. Plus, if you are on my mailing list you know there are even more things coming that I can't wait to get out the door.
I think this "A class should have only one reason to change" is what causes a great deal of confusion and finding a means to explain this would most useful.
Thank you. Great explanations! Finally have found the SOLID principles tutorials where youtuber doesn't want to demonstrate how intelligent they are by introducing too complex examples that make learners/viewers even more confused than before!
I totally and completely agree with the practical approach to your teaching. For me personally, the theory comes into focus later when I have some chops practically doing the things around which the theory is built. Thanks for the videos sir - they are excellent.
I'm really lucky to find your videos here. I got my internet and curiosity back after watching your videos. I promise i won't miss any of your videos and thank you so much for sharing your knowledge..great ful to you❤❤
Wow, really well explained. Our class recently got introduced to SRP, and this is the ideal video, which ACTUALLY explained SRP in a nutshell. Thanks again!
This video reminds me of a conversation I had with a colleague. He was frustrated with the fact that a Matlab script we were using made numerous references to other files (i.e. methods or classes). I knew at the time that “that’s how programming is done”, but after videos likes this I could have defended the practice much more fervently.
I know it is not a principle as such -> But a method with a return type, should never have a "side-effect", and a void should always have a "side-effect" Got this nugget from Uncle Bob. Once it struck my how true this is, I have been preaching it :) I understood it as: Any void method, must have a direct consequence. A state change, for a later process must have happened. Some sort of effect must have taken effect. Any method with a return type, cannot have a side effect. Meaning that what ever is being returned, is unique relevant for the "getting" of this value being return, no effects can be applied anywhere else. That is responsibility of a method with a void. That make SRP easier to implement as a rule of thumb. I try to follow this religiously, and in my opinion it makes my code better. However, this is hard to prove is true always, and objectively. But I haven't bumped into a situation where it wasn't true yet.
Very good. I've heard the lecture from "uncle Bob" himself on TH-cam, but he never went over the application of the principles. This is helpful. Thanks.
Corey, Thank you for this video. The SRP principle helped me understand that the class should only perform one job. It also help me under the function of the main method. It should be the "guide" or "legend" sort of speak to my application. This is good for me . Thank again
Best explanation of SRP I have ever found. I have been trying to understand SOLID better, but it has been very hard for me, specially because english is my second language. I also appreciate that you use easy examples and explain very well what you are doing. Some examples online are really advanced and I don't have a clue what the code is even doing.
Excellent video. I’d always thought of SRP in relation to methods, but seeing it applied to classes as well was an eye opener. Definitely the better way.
day 3 on learning C#, my first language and was thinking of what this principle might be called. a few peeps told me single responsibility and your video was the first that showed up. im glad i watched it! thank you!
Great! Hey, if you are just starting out in C#, I put together a video on how to set up your C# learning path to learn things in an order that makes sense and fills in the gaps: th-cam.com/video/LUv20QxXjfw/w-d-xo.html
Someone could argue that the AccountGenerator should really be a UserGenerator until an AccountGenerator is necessary. That's because Account and User might be affiliated but not synonymous. It's likely the Account class would hold multiple classes and not just User and be a part of a service framework. But as mentioned in the video, the point of the principles is to get you to think of these kinds of things. Just an alternate perspective, not meant to criticize. I found this video to be very good and learned a few things from it. It's amazing to me how reviewing the fundamentals from other perspectives can really develop our understanding and give us new ways to implement those fundamentals.
Thank you so much, Good and simple explanation, one thing I wanna talk a bout is your ending statement, where you said if you can scroll down your class then probably it's big! well I understand your point but in my humble opinion i think it is a bit too much, because it depends on project, some times we are dealing with extreme big and complex projects which took many years to develop and still under development and basically it is impossible to have very short classes, we are dealing with thousands of classes, integrations between different systems, here is where you come to the point that some of the principles are more to the theoretic side of the equation. My opinion as you said is that, there will be a combination of principles and trade offs, balance and what would be best for the project, which can depends on many different factors.
I believe the phrasing I used was if you start to scroll in your class, you should evaluate to see if it is too big. That's a good time to check. It doesn't mean that checking equals "it is bad". It is just a good time to check in. As for the idea that huge applications will have huge classes, that's a dangerous thought to be ok with by default. Yes, it will be true sometimes, but it shouldn't be the majority of the time and definitely not if you are following SRP. Most of what I see happening, though, is teams that give up fully on this principle because it is "unrealistic" and so justify using one class to house LOTS of logic. I worked with a client that, in a redo of an application to modernize it, had form code-behinds that were 3,000+ lines of code because it was all code that supported the form. I think we can agree that this is bad (hard to maintain, hard to understand, lots of reasons to change, etc.) but they didn't start out to write 3,000+ lines of code behind a form. They started out by justifying why a little bit of logic behind a form was ok. At the end of the day, do what works best for your organization to write maintainable code. If that means that all of your files scroll, but it works for you, go for it. Like you said, there are trade-offs to be made in any situation. Hit the balance that is right for you.
This Is very good, I always used classes, but thanks to this video, now I can make my code readable and easy to rewrite. I did what you did In this video sometimes, but you gave me a better view and few points, some stuff I never did, appreciate It. Thanks Tim.
Hi @IAmTimCorey, I wanted to express my gratitude for your insightful videos. They serve as a valuable reference for individuals preparing for interviews or seeking to refresh their fundamentals Thank you for your outstanding work!
Hi @IAmTimCorey , firstly thank you for these helpful videos. I'm writing an application that takes data from one system, translates it into a different format, then passes it to another system. I'm holding the in transit data is a sinle class, with subclasses to represent the sub lines of the data. Currently the class is over 3,000 lines. We've got a load of local variables to hold the data, propeties for each variable (includ a check not null and error handling), then there are half a dozen constructors, accepting different types of data input. Next, we have a block of methods for easily navigating the sub classes (again each has only a couple of functional lines, then the try-catch stuff around it. Obviously the methods alone require scrolling to veiw them all and some of the constructors won't fit on a single screen (there might be almsot 100 fields in the data element that we're passing. How should the above be restructured to work with the SRP concept, please? Especially regarding not having to scroll to see the whole class?
Perfect explanation! I never learn from power point diagrams, but in this one tutorial, I can already see where I have gone wrong in the past, and how I can improve existing code and create new code in the future, thanks
I have a controller class which is basically 1000 lines of codes. It's time i start using SOLID principles effectively from now on because testing has being real struggle for me. Thankyou for this amazing series Tim :)
Thank you so much , Tim. I'm re-entering the sw dev field and this is just what I needed. I'm going to watch all your SOLID videos, reading about SOLID is to me, pretty boring. Seeing the code though, makes it all clear. Subscribed.
Congrats Tim, I really enjoyed your way to present SOLID. Very clean and simple way. In the first moment I thought this video is too long, but now I understand you go step by step in the explanation and this make sense. I will watch the other videos. Congratulations again :-)
Glad it was helpful! My goal is to educate, not just dump out information. For some that seems to be too much information, but I am glad you see the value and benefit of it. Thanks for the feedback.
Wow! One screen of code for me is more like the maximum size of a method (on a good day!). I do break down my code but more at the methods level, whereas the classes come more from my model of the problem. I think SOLID principles become more beneficial when dealing with much bigger and more complex applications, libraries, code that is expanded frequently etc Thanks for the video.
There is definitely a tipping point where certain SOLID principles make more sense. SRP is a helpful even in small applications because it isn't a bunch of setup, it is a mindset change. Having everything do only one thing allows your application to easily grow to that next level. Thanks for watching.
Amazing tutorial!!! I have to learn SOLID and I think I did it on the PERFECT WAY!!! I will go through the whole course and then watch all your other content
Great explanation on SRP, two classes still kinda break SRP because they had two reasons to change. The StandardMessages and AccountGenerator, both would need a change if A: the message needs a change and B: if the way we tell the user about the message needs a change, as both are tied directly into the Console. Now I know that this is a simple demo application, if this were a real application I would create an IMessager interface and a ConsoleMessager class that implements this interface, this last class would responsible for outputting messages to the console.
Very well explained, unhurried and very detailed, I had been looking for content of this type for some time. Thanks for the knowledge and availability Tim! 👋
Tim I can’t thank you enough for this video! I’m so glad I found your content! I’m just a bit confused on the .Substring(1,0) method, but that’s probably because this video was more about design concepts/OOP. Still learned so much!
He created the username TCorey, so that requires just the first letter of the first name. It's Substring(0, 1) not (1, 0). 0 is the startindex and 1 is its length.
This is the best way to keep the projects going for years :D Jokes apart. Tim, I am a big fan of your videos. I have an interview next week and I hope I will pull that off.
this class scrolls rule is pretty interesting. I am always struggling with lengthy and complex classes so this video and series in general is really helpful thanks
Hello Tim. Thanks for the more advanced videos. I was wondering on what is the difference between the single responsibility principle(SRP) and the separation of concerns(SoC) principle . The way I imagine it is that SoC dictates how to set up your project so for example we have our UI then we have our Business Logic and then we might have for example a data access layer/logic, while based on this video it seems that SoC cares more for how to build these modules more structured. So for example in a data access layer, we might have a class that retrieves data and another that saves data based on the SRP. So my question is , is SRP essentially a part of SoC or am I getting something wrong? Keep up the good work!
The TLDR; of this is you prefer maintainability over effectiveness EVERYWHERE and EVERYTIME. This is a super verbose way of writing stuff, but I guess (due to my lack of programming skills for now) it is very testable. I am coming from JavaScript, but this is all practically the same thing.
It isn't maintainability OVER effectiveness. It is effectiveness that is also maintainable. It may seem verbose at the beginning when you have just a little bit of logic in a test application but in the real-world, where applications have thousands of lines of code and lots of business logic, having something that is more maintainable makes you a lot faster. Being afraid to change something because of the add-on effects to the rest of the application is restrictive. It slows down development. This pattern is much more effective in the "real world" for that reason.
Well done Tim! I feel like I would put the validation inside the person class and treat it as a Value Object. The person class can encapsulate the business rules of what is a correct first name and last name. Then if I want to use my Person class elsewhere or using a different protocol I can be re-assured that having a Person object means that I have a valid object. In addition, I would validate the console input specifically before creating my Person class as that is specific to how the console works and to give me a chance at outputting or handling the interaction in a console-centric fashion. Another point that I would like to point out is that if you provided a test suite with passing tests before your refactoring you could prove to your audience that the application behaves the same way it originally did even after all the changes. Talking out loud here :)
What if your validation rules change? Let's say you used to have standard utf-8 encoding, but you now need an encoding type that can handled characters that aren't UTF-8 Now you validation rules for "IsLetter" might require an object, now the hardcoded validation, needs to be altered everywhere - And did you only include this string validation on names? What about addresses? Anything else you can think of that might need validation, that could be effected by such a change? I would recommend a deep dive at the IoC (Dependency injection) design principle, it fits nicely together with All the SOLID principles. Because software is ALWAYS subject to change -> it is why it is software, and not hardware, your code design must be change friendly, no matter the project. Change is always an option. if change wasn't an option, then you are just writing "hardware".
@@mortenbork6249 Doesn't change anything to my previous comment. There is nothing stopping you from injecting validation concerns to the Person Value Object or where you do your console-specific validation. I agree with you that coding for interfaces and not concrete classes is important, which is the I in SOLID and is facilitated through the use of dependency injection. My point here is that I prefer knowing that if I have a handle on a Person object, then it is valid by nature because I prevent the instantiation of an invalid Person object. And the validation in the Person class is specific to say, what a first name and last name should be. Whilst in the console I would do more generic validation(required input, encoding, etc).
Thanks for your videos Tim. I always learn something. It may not be strictly SRP, but I use ReSharper’s suggestion of using the Resources file to hold the static strings so that in your code you can just call things like Console.WriteLine(Resources.WelcomeMessage). This also has the advantage that if you have to translate the app you can just provide the Resources file in the various languages.
Yep, that works. It really does make those translations easier. I just had to do that for one of our UIs at work. Fortunately, I had set things up so that I could just do that extraction and then load a translation file based upon which language was requested.
Great video Tim. How do you best define a responsibility? For example if you have a person object; would the CRUD operations be defined as one responsibility or split into 4 classes.
I typically define them as one because the only reason those CRUD operations need to change is if the table changes (in theory - you could also decide to get different information from the database, which is why sometimes CRUD is split between reads and writes).
Great video as always, keep up the amazing work Tim, please!! I have a question, it would be great if you answer it. 32:34 here you mentioned keeping the class size as small as possible and not scrolled off the screen, but in real-world applications, I see lots of classes that violate that rule. Does it mean most of, even the experienced ones, developers don't care about this rule? What is your advice to junior developers on this one?
When a class scrolls is a good time to check in and see if you are doing too much. That doesn't always mean what you are doing is bad. However, a lot of real-world applications totally ignore this advice and just blaze right through that checkpoint. I've seen applications with thousands of lines of code that was all considered "necessary". Because there was never a check early on, code just kept getting added until it was an avalanche. Do the check early and keep checking to see if you are doing too much.
@@IAmTimCorey Thanks for the fastest answer. As I understood we should always consider applying this principle when we first start to create each class as opposed to most developers do. Thanks, Tim, you are the best.
Great video! Regarding 31:55, let's assume you have a class "Binary". The class has methods to parse binary into different numeral systems, like decimal or hexadecimal, which would looke like Binary.parseDeicmal(binaryValue) or Binary.parseHexadecimal(binaryValue) and would return the corresponding value. So far so good, but given you can also parse binary into other things(Unicode, base64, ASCII etc.) you can easily implement multiple methods, which would lead to hundreds of lines of code. However, the class would still only have one responsibility: parse binary value into another format. How would you approach this using the Single Responsibility Principle?
Could you touch on naming conventions for classes and the methods inside of those classes? Should class names be object+verb and methods +actionverb+object? How would go about working through this?
thumbs Up! thank you so much, now I really understand why should we have one class per single task? The SRP, I have a very large application which uses some classes, objects and connections strings, users authentication etc. I will try slowly to convert all my tasks in different forms and codes in-line with SOLID design principles. (It's a BIG job)
Well Tim, I work on an Application where foreach loop has 300 LOC, and class consists of over 10000 LOC. I just hate to debug 😔. But this SRP thing could bring a great comfort in Developers life. Thank you very much for this informative tutorial
For the PersonDataCapture.Capture() method, doesn't it make more sense to put the Console.WriteLine() statements in a method in the StandardMessages class since we likely want to standardize the prompt that the user receives when they populate the Person object's fields?
Thank you for this video. One question though regarding timestamp 20:55 : wouldn't it be better to pass the Standardmessage.DisplayValidationError() as an argument? Doing it they way you did, you created a dependency in the PersonValidator.cs of StandardMessages.cs ?
StandardMessages is a dependency, but I'm not sure what you mean by pass it as an argument. If you mean dependency inversion, that is covered later and I didn't want to confuse the topic. This topic is focused on SRP and since displaying a message was not a part of the class, I passed off that functionality to something else that just concentrated on the messaging. At the end of the day, almost everything has dependencies (especially if you follow SRP). In the "D" lesson, we will cover how to invert those dependencies (DIP) and later on I'll cover Dependency Injection but for now, having a dependency isn't a problem.
Having someone like Tim Corey in the C# community is beyond essential. Thank you for all you do. Greatest C# teacher there is
I appreciate the kind words.
I appreciate your time spent putting this together. It was very helpful for quick review or teaching this concept to new developers. You are easy to understand because your speak clearly and you explain your thought processes. Well done.
I appreciate the kind words.
Thank you for what you do Tim. You're one of those people that get to the top and throw the ladder down for everyone else. I hope you have a happy life.
You are most welcome. Thanks for watching.
I've been watching your material for months, now. You definitely made me advance in my skill set.
I'm glad!
0:00 - Intro
1:33 - Demo code overview
1:56 - Single Responsibility Principle: SRP explained
5:09 - Implementing SRP: Refactoring demo code
24:38 - Recap
25:28 - Summary and conclusions
29:45 - Why many classes is not a problem for your application
31:29 - How to keep a balance: creating to classes, when to split up a class
33:23 - Concluding remarks
Thanks again
"If you have to scroll you've probably done something wrong." I think this statement is a bit exaggerated because it's hard to have small classes in large programs, achievable in small ones. In some cases there is a lot of functionality revolving around a subject and moving code out of the class to keep it small would break another important principle, that is cohesion. I think of classes as nouns and of methods as verbs. In my opinion the single responsibility principle asks us to put the verb/method in the right class/noun.
Before starting to write the code for you program, think about the nouns and verbs that are involved in your program and structure your nouns into systems and subsystems, in other words lay out the skeleton of your program.
The problem with long methods is that testing is a mess. If you have one branch in your method, you need to write two tests (one for each side of the branch - simplified, of course, since there may be more than that to write). However, if you have five branches, the number of tests you have to write to fully test things can be exponentially more (not just 10).
@@IAmTimCorey Thanks for the video on SRP. I am working on expanding my coding horizons and your videos do indeed help. I must agree with Janos. While I strongly agree with your sentiment to keep classes small, "If you have to scroll, you've probably done something wrong," is is simply not true for non-trivial programs. When I went to college in the late 80's, the rule-of-thumb was that a function, procedure or method should be no longer than a printed page. I try to maintain this guideline while writing new code and refactoring old. However, in more than 50% of the code I handle on a daily basis, this limit is difficult to accomplish. Complex algorithms require complex code at times. Trying to bend a large program into classes that will not scroll, in my opinion would be like watering my garden with a teaspoon. :-)
On the other hand, I have literally twitched after first review of an old program with methods that were thousands of lines long. Yes... one method was more than 2000 lines by itself. Debugging was a nightmare.
There is one other minor comment... You said nothing about multiple method exit points. To avoid confusion, especially in programs that have been heavily modified by several programmers, maintaining single exit points can be extremely helpful.
Thanks again & keep up the great work!
Agree. This is excessive. We have an internal rule on methods being more than one scroll but having this policy on classes in just not right.
SRP is basically just decomposition of your methods/classes into smaller and discrete units of work. The trick is to not go overboard with it and to find balance.
I’ve been learning SOLID this week and I’m really happy I found this.
Excellent!
This is actually the most comprehensive analysis of SRP examined in practical manner, great video, thanks!
Glad it was helpful!
Hello Mr. Corey. I just found your videos and have found them most helpful. Thank you very much for sharing your knowledge freely and openly with the rest of the world. It is people like you that restore my faith in humanity. Best regards from Mexico.
You are most welcome. Thanks for watching.
I always disliked opening my old projects because I know the horror I will face trying to change something, this explains so much.
I think it's time to revisit some old projects and try to apply this now. Thank you Tim.
You are welcome.
LOL
I Scroll On My Visual Studio Like a Book.
Thank you for making me realize (in a simple and objective way) how much I have to improve, as a programmer!
You're very welcome!
Of all the videos I have watched on this channel, the Design Pattern series of videos has been the most helpful for me personally, and it explains why teams often fear making even small changes in code, they know that a minor change can easily cause a massive cascading effect. I have been in dev meetings where the decision was made to leave in dead code simply out of the fear that pulling it will have unknown long-term effects, even if all code testing indicates there are no calls being made to the dead code.
Truth! I think I was in some of those same meetings.
- Beautifully crafted explanation of Single Responsibility Principle.
- Depth is what I like the most in your tutorials Tim.
- Along with the principle, we would also like to hear your personal experiences on SRP. The challenges that you've faced while following SRP in live projects.
I appreciate the kind words. As for my experiences, I'll add that to the suggestion list. In general, my experience is that it really helps make the application easier to maintain. It is hard to do well sometimes and sometime you cheat, but doing it right pays off in the end.
I know this is an old video series, but I have been searching for a while now for explanations of design patterns, and just anything related to coding really. Trying to get a better grasp of reasoning and how to go about solving problems. You're videos explain things so well. I honestly think these videos have had the biggest impact on my skills over any course/videos I have previously watched. I genuinely thank you for these. You wouldn't happen to have a programming course by chance? lol
I do have a lot of programming courses at iamtimcorey.com. If you are looking for a beginner to advanced C# course then the Foundation in C# course is the right one to start with: www.iamtimcorey.com/p/complete-foundation-in-c-course-series
Incredible, recently I've spent a some of my time researching/learning new design patterns.
Few days later, just when I needed it the most, this video appeared.
Not too long ago I was struggeling with Unit testing and the same thing happened!
Your timing with your videos just couldn't be better!
Thank you so much for creating these educative videos for us over the years. I realy appreciate your efford.
Excellent. Well, there are more design patterns coming. I will finish out SOLID first but then I will be covering other patterns as well. I am not sure when the videos will come out yet. I am still working on my production calendar. I have so many videos I want to get out but I need the time to get them done. I am not done covering unit testing yet (I will be covering mocking next) and I am almost done the prep work for my .NET Core series too. Plus, if you are on my mailing list you know there are even more things coming that I can't wait to get out the door.
I wish you good luck!
This is the way to learn programming. Thanks so much.
You are welcome.
Tim, you deserve a medal, thanks for all your effort
You are most welcome. Thanks for watching.
I think this "A class should have only one reason to change" is what causes a great deal of confusion and finding a means to explain this would most useful.
Yep, that can be tricky to identify clearly.
Tim ! You're the best; I learned a lot from you. Thank you for all what you do for us ...
Awesome!
Thank you. Great explanations! Finally have found the SOLID principles tutorials where youtuber doesn't want to demonstrate how intelligent they are by introducing too complex examples that make learners/viewers even more confused than before!
Glad it was helpful!
best practical way of showing SRP and clean oop structure I have seen! Thank you!
Glad it was helpful!
Literally, the best videos about solid principles, thank you a lot
You are welcome.
Perfect for beginners, for professional a quick basic recap. I highly recommend this tutorial
Thank you!
I totally and completely agree with the practical approach to your teaching. For me personally, the theory comes into focus later when I have some chops practically doing the things around which the theory is built. Thanks for the videos sir - they are excellent.
You are welcome.
Same! Too many times we see tutorials teaching solutions for problems we haven't encountered yet
Thanks tim... You never stop to impress your viewers.... Another high quality video...!
Thank you!
I'm really lucky to find your videos here. I got my internet and curiosity back after watching your videos. I promise i won't miss any of your videos and thank you so much for sharing your knowledge..great ful to you❤❤
You are welcome.
Best SRP video I ever came accross. Thank you Tim
Thanks for watching!
Wow, really well explained. Our class recently got introduced to SRP, and this is the ideal video, which ACTUALLY explained SRP in a nutshell. Thanks again!
Glad it was helpful!
Rahul Bhai kyaa haal h?
Arre, bhai! big fan sir!
great video and explanation! Much better to see and go through code THAN some powerpoint presentation. This kind of teaching is much more enjoyable
I am glad you found it so valuable.
Man i hope you are teaching college or somewhere cause it fits you so much , much love brother u the best !!!!!!
Not anymore. I teach on iamtimcorey.com now.
This video reminds me of a conversation I had with a colleague. He was frustrated with the fact that a Matlab script we were using made numerous references to other files (i.e. methods or classes). I knew at the time that “that’s how programming is done”, but after videos likes this I could have defended the practice much more fervently.
I am glad my content is helpful to you.
I know it is not a principle as such ->
But a method with a return type, should never have a "side-effect", and a void should always have a "side-effect"
Got this nugget from Uncle Bob. Once it struck my how true this is, I have been preaching it :)
I understood it as:
Any void method, must have a direct consequence. A state change, for a later process must have happened. Some sort of effect must have taken effect.
Any method with a return type, cannot have a side effect.
Meaning that what ever is being returned, is unique relevant for the "getting" of this value being return, no effects can be applied anywhere else.
That is responsibility of a method with a void.
That make SRP easier to implement as a rule of thumb. I try to follow this religiously, and in my opinion it makes my code better. However, this is hard to prove is true always, and objectively.
But I haven't bumped into a situation where it wasn't true yet.
Thanks for sharing.
You have done what many others haven't !
Simple, understandable - user friendly ;)
Thank you!!
Thanks for the support and encouragement
Very good. I've heard the lecture from "uncle Bob" himself on TH-cam, but he never went over the application of the principles. This is helpful. Thanks.
I am glad it was helpful.
Corey, Thank you for this video. The SRP principle helped me understand that the class should only perform one job. It also help me under the function of the main method. It should be the "guide" or "legend" sort of speak to my application. This is good for me . Thank again
Glad it was helpful!
may you live a thousand years, you and your family,
these videos are unique and extremely useful
I am glad you found them valuable.
You make things so much simpler. Thank you!
You are so welcome!
Best explanation of SRP I have ever found. I have been trying to understand SOLID better, but it has been very hard for me, specially because english is my second language. I also appreciate that you use easy examples and explain very well what you are doing. Some examples online are really advanced and I don't have a clue what the code is even doing.
I am glad it was so helpful to you.
Your information providing technique is awesome. You make things clear and simpler. Thank you very much !!!
You're very welcome!
I forgot to thank you for this playlist ... very well explained !!!
You are most welcome. Thanks for watching.
Thank you so much!! This is what I am looking for. You are a great teacher Tim. Keep creating the awesome content.
You are welcome.
This is the best and clear explanation with example that I have seen in the Internet, Kudos!!
Thank you very much.
Excellent video. I’d always thought of SRP in relation to methods, but seeing it applied to classes as well was an eye opener. Definitely the better way.
Glad it was helpful!
day 3 on learning C#, my first language and was thinking of what this principle might be called. a few peeps told me single responsibility and your video was the first that showed up. im glad i watched it! thank you!
Great! Hey, if you are just starting out in C#, I put together a video on how to set up your C# learning path to learn things in an order that makes sense and fills in the gaps: th-cam.com/video/LUv20QxXjfw/w-d-xo.html
Someone could argue that the AccountGenerator should really be a UserGenerator until an AccountGenerator is necessary. That's because Account and User might be affiliated but not synonymous. It's likely the Account class would hold multiple classes and not just User and be a part of a service framework. But as mentioned in the video, the point of the principles is to get you to think of these kinds of things. Just an alternate perspective, not meant to criticize. I found this video to be very good and learned a few things from it. It's amazing to me how reviewing the fundamentals from other perspectives can really develop our understanding and give us new ways to implement those fundamentals.
Thanks for sharing!
Learning C# currently with Unity. Can't thank enough for these videos. Good job!
You are most welcome. Thanks for watching.
Thank you so much, Good and simple explanation, one thing I wanna talk a bout is your ending statement, where you said if you can scroll down your class then probably it's big! well I understand your point but in my humble opinion i think it is a bit too much, because it depends on project, some times we are dealing with extreme big and complex projects which took many years to develop and still under development and basically it is impossible to have very short classes, we are dealing with thousands of classes, integrations between different systems, here is where you come to the point that some of the principles are more to the theoretic side of the equation. My opinion as you said is that, there will be a combination of principles and trade offs, balance and what would be best for the project, which can depends on many different factors.
I believe the phrasing I used was if you start to scroll in your class, you should evaluate to see if it is too big. That's a good time to check. It doesn't mean that checking equals "it is bad". It is just a good time to check in. As for the idea that huge applications will have huge classes, that's a dangerous thought to be ok with by default. Yes, it will be true sometimes, but it shouldn't be the majority of the time and definitely not if you are following SRP. Most of what I see happening, though, is teams that give up fully on this principle because it is "unrealistic" and so justify using one class to house LOTS of logic. I worked with a client that, in a redo of an application to modernize it, had form code-behinds that were 3,000+ lines of code because it was all code that supported the form. I think we can agree that this is bad (hard to maintain, hard to understand, lots of reasons to change, etc.) but they didn't start out to write 3,000+ lines of code behind a form. They started out by justifying why a little bit of logic behind a form was ok.
At the end of the day, do what works best for your organization to write maintainable code. If that means that all of your files scroll, but it works for you, go for it. Like you said, there are trade-offs to be made in any situation. Hit the balance that is right for you.
People keep complain about I have so many classes for simple job.
You just make my life more easier, thx bro
Awesome!
This Is very good, I always used classes, but thanks to this video, now I can make my code readable and easy to rewrite.
I did what you did In this video sometimes, but you gave me a better view and few points, some stuff I never did, appreciate It.
Thanks Tim.
That's great!
Thank you Tim..
Respect from India
You are welcome.
Hi @IAmTimCorey,
I wanted to express my gratitude for your insightful videos. They serve as a valuable reference for individuals preparing for interviews or seeking to refresh their fundamentals
Thank you for your outstanding work!
I appreciate the kind words.
Hi @IAmTimCorey , firstly thank you for these helpful videos.
I'm writing an application that takes data from one system, translates it into a different format, then passes it to another system. I'm holding the in transit data is a sinle class, with subclasses to represent the sub lines of the data. Currently the class is over 3,000 lines. We've got a load of local variables to hold the data, propeties for each variable (includ a check not null and error handling), then there are half a dozen constructors, accepting different types of data input. Next, we have a block of methods for easily navigating the sub classes (again each has only a couple of functional lines, then the try-catch stuff around it. Obviously the methods alone require scrolling to veiw them all and some of the constructors won't fit on a single screen (there might be almsot 100 fields in the data element that we're passing.
How should the above be restructured to work with the SRP concept, please? Especially regarding not having to scroll to see the whole class?
Perfect explanation! I never learn from power point diagrams, but in this one tutorial, I can already see where I have gone wrong in the past, and how I can improve existing code and create new code in the future, thanks
Excellent!
I have a controller class which is basically 1000 lines of codes. It's time i start using SOLID principles effectively from now on because testing has being real struggle for me. Thankyou for this amazing series Tim :)
That will definitely give you a lot of benefits.
Thank you so much , Tim. I'm re-entering the sw dev field and this is just what I needed. I'm going to watch all your SOLID videos, reading about SOLID is to me, pretty boring. Seeing the code though, makes it all clear. Subscribed.
Awesome!
12:05 a bit out of topic but, I didn't know this trick. I've been using ctrl + R, R . Thanks for the tip!
You are welcome.
Congrats Tim, I really enjoyed your way to present SOLID. Very clean and simple way. In the first moment I thought this video is too long, but now I understand you go step by step in the explanation and this make sense. I will watch the other videos.
Congratulations again :-)
Glad it was helpful! My goal is to educate, not just dump out information. For some that seems to be too much information, but I am glad you see the value and benefit of it. Thanks for the feedback.
Wow! One screen of code for me is more like the maximum size of a method (on a good day!). I do break down my code but more at the methods level, whereas the classes come more from my model of the problem. I think SOLID principles become more beneficial when dealing with much bigger and more complex applications, libraries, code that is expanded frequently etc Thanks for the video.
There is definitely a tipping point where certain SOLID principles make more sense. SRP is a helpful even in small applications because it isn't a bunch of setup, it is a mindset change. Having everything do only one thing allows your application to easily grow to that next level. Thanks for watching.
IAmTimCorey also, small applications tend to grow into big applications, so you might as well start off right.
I changed it and i really like it the way i did it, thank you Tim!
Great job!
Amazing tutorial!!! I have to learn SOLID and I think I did it on the PERFECT WAY!!! I will go through the whole course and then watch all your other content
Thank you!
Great explanation on SRP, two classes still kinda break SRP because they had two reasons to change. The StandardMessages and AccountGenerator, both would need a change if A: the message needs a change and B: if the way we tell the user about the message needs a change, as both are tied directly into the Console.
Now I know that this is a simple demo application, if this were a real application I would create an IMessager interface and a ConsoleMessager class that implements this interface, this last class would responsible for outputting messages to the console.
Thanks for sharing from your experience
Very well explained, unhurried and very detailed, I had been looking for content of this type for some time.
Thanks for the knowledge and availability Tim! 👋
Glad it was helpful! Please consider checking out my other videos - th-cam.com/channels/-ptWR16ITQyYOglXyQmpzw.html
Tim I can’t thank you enough for this video! I’m so glad I found your content! I’m just a bit confused on the .Substring(1,0) method, but that’s probably because this video was more about design concepts/OOP. Still learned so much!
He created the username TCorey, so that requires just the first letter of the first name.
It's Substring(0, 1) not (1, 0). 0 is the startindex and 1 is its length.
This is the best way to keep the projects going for years :D Jokes apart. Tim, I am a big fan of your videos. I have an interview next week and I hope I will pull that off.
Good luck!
Thanks for these lessons Tim! As a student from college these SOLID principles are somewhat of a game changer for me!
Excellent! I'm glad they helped.
this class scrolls rule is pretty interesting. I am always struggling with lengthy and complex classes so this video and series in general is really helpful thanks
Glad it was helpful.
Tim you are a very great teacher..
I learnt a lot from your videos.
Thank you so much. You are really an inspiration for me to learn.,👍👍
You are very welcome!
Hello Tim. Thanks for the more advanced videos. I was wondering on what is the difference between the single responsibility principle(SRP) and the separation of concerns(SoC) principle . The way I imagine it is that SoC dictates how to set up your project so for example we have our UI then we have our Business Logic and then we might have for example a data access layer/logic, while based on this video it seems that SoC cares more for how to build these modules more structured. So for example in a data access layer, we might have a class that retrieves data and another that saves data based on the SRP. So my question is , is SRP essentially a part of SoC or am I getting something wrong? Keep up the good work!
Hey Tim...can't wait to watch rest of the videos ..(sOLID)...
Open/Closed Principle should come out on Monday.
Thanks so much for the amazing playlist. You are saving my life :)
You are most welcome. Thanks for watching.
That was brilliant. Thanks Tim
You are welcome.
This is Perfect, straight forward and clear explanation.
Thanks
Well explained Tim Corey. Thank you for the beautiful video.
You are welcome.
Thank you!
The TLDR; of this is you prefer maintainability over effectiveness EVERYWHERE and EVERYTIME. This is a super verbose way of writing stuff, but I guess (due to my lack of programming skills for now) it is very testable. I am coming from JavaScript, but this is all practically the same thing.
It isn't maintainability OVER effectiveness. It is effectiveness that is also maintainable. It may seem verbose at the beginning when you have just a little bit of logic in a test application but in the real-world, where applications have thousands of lines of code and lots of business logic, having something that is more maintainable makes you a lot faster. Being afraid to change something because of the add-on effects to the rest of the application is restrictive. It slows down development. This pattern is much more effective in the "real world" for that reason.
@@IAmTimCorey Yep I gotcha. Thanks for the vid. :)
love your content and how you make our lives a lot easier
Thanks!
Thank you so much for your detailed explanations. Please group videos on the topic of SOLID into a separate playlist.👍👍👍
OPS .. It turns out these videos are grouped into the "DRY" playlist. Thank you, I have not noticed this with it.
You are a great teacher thanks for your tutorials
You are welcome.
Very simple and clean explanation and at the end the patterns are to write a good quality and maintaneble code
Thank you!
Well done Tim! I feel like I would put the validation inside the person class and treat it as a Value Object. The person class can encapsulate the business rules of what is a correct first name and last name. Then if I want to use my Person class elsewhere or using a different protocol I can be re-assured that having a Person object means that I have a valid object. In addition, I would validate the console input specifically before creating my Person class as that is specific to how the console works and to give me a chance at outputting or handling the interaction in a console-centric fashion.
Another point that I would like to point out is that if you provided a test suite with passing tests before your refactoring you could prove to your audience that the application behaves the same way it originally did even after all the changes.
Talking out loud here :)
What if your validation rules change?
Let's say you used to have standard utf-8 encoding, but you now need an encoding type that can handled characters that aren't UTF-8
Now you validation rules for "IsLetter" might require an object, now the hardcoded validation, needs to be altered everywhere -
And did you only include this string validation on names? What about addresses?
Anything else you can think of that might need validation, that could be effected by such a change?
I would recommend a deep dive at the IoC (Dependency injection) design principle, it fits nicely together with All the SOLID principles.
Because software is ALWAYS subject to change -> it is why it is software, and not hardware, your code design must be change friendly, no matter the project. Change is always an option.
if change wasn't an option, then you are just writing "hardware".
@@mortenbork6249 Doesn't change anything to my previous comment. There is nothing stopping you from injecting validation concerns to the Person Value Object or where you do your console-specific validation. I agree with you that coding for interfaces and not concrete classes is important, which is the I in SOLID and is facilitated through the use of dependency injection. My point here is that I prefer knowing that if I have a handle on a Person object, then it is valid by nature because I prevent the instantiation of an invalid Person object. And the validation in the Person class is specific to say, what a first name and last name should be. Whilst in the console I would do more generic validation(required input, encoding, etc).
Thanks for sharing.
Díky!
Thank you!
Thank you Tim for sharing your knowledge and experience
You are welcome.
Thanks for your videos Tim. I always learn something. It may not be strictly SRP, but I use ReSharper’s suggestion of using the Resources file to hold the static strings so that in your code you can just call things like Console.WriteLine(Resources.WelcomeMessage). This also has the advantage that if you have to translate the app you can just provide the Resources file in the various languages.
Yep, that works. It really does make those translations easier. I just had to do that for one of our UIs at work. Fortunately, I had set things up so that I could just do that extraction and then load a translation file based upon which language was requested.
Now I really understood the SRP, Thanks
Awesome!
Great video Tim. How do you best define a responsibility? For example if you have a person object; would the CRUD operations be defined as one responsibility or split into 4 classes.
I typically define them as one because the only reason those CRUD operations need to change is if the table changes (in theory - you could also decide to get different information from the database, which is why sometimes CRUD is split between reads and writes).
Your videos are awesome and inspiring, keep making these videos. It helped me made my code lot cleaner
Will do! I'm glad you are getting a lot of value out of them.
Great video as always, keep up the amazing work Tim, please!!
I have a question, it would be great if you answer it.
32:34 here you mentioned keeping the class size as small as possible and not scrolled off the screen, but in real-world applications, I see lots of classes that violate that rule. Does it mean most of, even the experienced ones, developers don't care about this rule? What is your advice to junior developers on this one?
When a class scrolls is a good time to check in and see if you are doing too much. That doesn't always mean what you are doing is bad. However, a lot of real-world applications totally ignore this advice and just blaze right through that checkpoint. I've seen applications with thousands of lines of code that was all considered "necessary". Because there was never a check early on, code just kept getting added until it was an avalanche. Do the check early and keep checking to see if you are doing too much.
@@IAmTimCorey Thanks for the fastest answer. As I understood we should always consider applying this principle when we first start to create each class as opposed to most developers do. Thanks, Tim, you are the best.
Good, clear explanation. Thank you.
You are welcome.
Congratulations Tim for 200K Subs. Stat SOLID ! :D
Thanks!
Great video! Regarding 31:55, let's assume you have a class "Binary". The class has methods to parse binary into different numeral systems, like decimal or hexadecimal, which would looke like Binary.parseDeicmal(binaryValue) or Binary.parseHexadecimal(binaryValue) and would return the corresponding value. So far so good, but given you can also parse binary into other things(Unicode, base64, ASCII etc.) you can easily implement multiple methods, which would lead to hundreds of lines of code. However, the class would still only have one responsibility: parse binary value into another format. How would you approach this using the Single Responsibility Principle?
That may be a case where a large class is reasonable. Or, you might further break it down by category (if it were to make sense).
Thanx alot. So simple clear and clean. Thanx again. Please keep goooooing
You are welcome. I can't wait to get the next one out the door.
Could you touch on naming conventions for classes and the methods inside of those classes? Should class names be object+verb and methods +actionverb+object? How would go about working through this?
I will add it to the list. Thanks for the suggestion.
thumbs Up! thank you so much, now I really understand why should we have one class per single task? The SRP, I have a very large application which uses some classes, objects and connections strings, users authentication etc. I will try slowly to convert all my tasks in different forms and codes in-line with SOLID design principles. (It's a BIG job)
Excellent!
Love the way you explained it!!!
Thanks!
I've always love your explanation, easy to understand
Glad you like them!
Great video! If you need to scroll the screen to read the code in a class, you may need refactor it. I agree with that.
Thanks!
I'm not sure I agree with this, surely there are times where you have to write substantial amounts of logic?
Well Tim, I work on an Application where foreach loop has 300 LOC, and class consists of over 10000 LOC. I just hate to debug 😔.
But this SRP thing could bring a great comfort in Developers life.
Thank you very much for this informative tutorial
Yep, that should help.
How you made the changes over there then??
@@kumarshivam888 shivam AKP JSR?
@@kumarshivam888 slowly and carefully breaking those classes in smaller classes and using interface
helping me a lot to improve the developer in me :) Thank you Tim!
You are welcome.
For the PersonDataCapture.Capture() method, doesn't it make more sense to put the Console.WriteLine() statements in a method in the StandardMessages class since we likely want to standardize the prompt that the user receives when they populate the Person object's fields?
i was in middle of my class, but this vid kinda attracted me
lol
Thank you for this video. One question though regarding timestamp 20:55 : wouldn't it be better to pass the Standardmessage.DisplayValidationError() as an argument? Doing it they way you did, you created a dependency in the PersonValidator.cs of StandardMessages.cs ?
StandardMessages is a dependency, but I'm not sure what you mean by pass it as an argument. If you mean dependency inversion, that is covered later and I didn't want to confuse the topic. This topic is focused on SRP and since displaying a message was not a part of the class, I passed off that functionality to something else that just concentrated on the messaging. At the end of the day, almost everything has dependencies (especially if you follow SRP). In the "D" lesson, we will cover how to invert those dependencies (DIP) and later on I'll cover Dependency Injection but for now, having a dependency isn't a problem.