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.
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.
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.
- 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 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.
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
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!
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'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❤❤
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 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.
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.
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!
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.
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.
Very good. I've heard the lecture from "uncle Bob" himself on RUclips, but he never went over the application of the principles. This is helpful. Thanks.
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.
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.
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?
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!
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.
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.
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: ruclips.net/video/LUv20QxXjfw/видео.html
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.
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!
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.
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).
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
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.
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 :)
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?
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.
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.
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! 👋
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
Hi Tim, I a little question arose during this interesting tutorial (tried to find it online but did't find any clear answer): Why would you use non-static classes that contain only static methods (and no other members), such as the PersonValidator? I thought that static classes have a little advantage over non-static classes because they do not require instances created for each new object, so that means, they consume fewer resources (no duplication of the same class or member is needed in memory) but that's probably seldom noticeable. Could you shed a little light on this issue (or maybe just say that it doesn't really matter)? Thanks in advance
You shouldn't. He just showed it as an example so it didn't really matter because you wouldn't use static methods if you followed SOLID principles anyway. You'd probably use something like dependency injection instead.
Great work MR.Corey it was really helpful. but I think this particular design pattern and what it means is so debatable, for example, on the validation class from my pov it makes two job one is validating input and another is displaying error messages . so i think there no easy answer for what is a single responsibility means and that is the problem that causes the arguments among developers.
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?
Hi @IAmTimCorey! First of all : Thank you very much for these videos, they give me hope to eventually become the developer I want to be. But while watching I had trouble understanding a specific thing about your exampe. Could you please explain to me in simple terms why you split the capturing, validation and the user itself into different classes? As far as I understood you did this to honor SRP so every class would have one responsibility (storing data, validatin and creation). But all of these classes worked with User only and ontop of that the methods all were static, making it impossible to properly override methods. I personally would have put the creation and validation into the User class, as all the methods are related to User. Thank you in advance!
I am a little confused, Can you explain this in terms of MVC Let's say we have a User controller and service, now In that controller and service we could have a route for find,update,insert,delete, and others, so should we break all of them into their own function or should we do in both controller and service. I am just confused about when should I stop breaking the code in new classes/functions. Please explain.
Controllers often break SRP. However, one way to have them not break SRP would be to extract all of the logic out of the controller. The controller's job should be to just provide the endpoints to the consumer. That's it. All of the logic should be in separate methods.
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).
Very good and clear explanation! But this AccountGenerator class. Is it an actual implementation of Factory Pattern so in the real world it will be called AccountFactory?
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
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.
I think it's because that way your class would do two things: create the person's information and validate that information. Using SRP a class should do one thing and one thing only. At least that's what I understood.
@@kevinmcculkin8877 Thanks for the clarification. But this doesn't really satisfied me! I hoped you would say that it was only a not-real example, and a developer should have to know when (not) to extract something to extra classes/interfaces according the specific domain needs. If I will ALWAYS need to perform something (here, validate) to my object (here, the person), which I would do, I would then follow the old-school (!) OOP way, i.e. build an object with all related methods. In a previous project we used a variation of CQRS, and when needed to validate a model, we inherited from say IValidate and implemented validation in the same model (not in an extra class!). Do we do it the wrong way the whole time!! Furthermore, let us take the .net FILE class as an example: It has f.e. encrypt & decrypt methods. If we would consider SRP as you described, there should be an extra class for that? May be this is a bad example from me, but just to mention that it makes no sense to extract every functionality to extra classes. Thanks in advance.
@@ghm7093 "It makes no sense to extract every functionality to extra classes", the same thought that crossed my mind. I can grasp the concept of SRP from this video but i need more real world example in more complicated project.
Thank you so much for that video, amazing the way you explained. I was just wondering if in some cases it is ok to apply SRP for the methods instead of classes. Trying to use for example the BankAccount class. It would be a class that might have many resposibilities and actions that are related to a bank account. Withdraw, Deposit, Transfer, Print Accounts, variables holding informations about the account and the Client, some getters and setters maybe, and so on. So in this case I will probably need to change this class for more than one reason, maybe change some code in the deposit process, maybe in the withdraw. Therefore my class it is not anymore in the SRP principle and it will be probably needed to scroll the class to view all its content. It would be really amazing to have classes so small in a way that I couldn’t even need to scroll and I totally understood how great and more organized this would keep the project, but at least for my current programming experience it is really hard to find a way to do that in some cases. Anyway, thanks for the great video, I am currently reading Clean Code and hopefully I will understand better that after finishing this book and of course a lots of practice 😁
Yes, you can definitely apply it to methods. That doesn't mean you should create messy classes with lots of responsibilities but you can be a bit more broad in the class's responsibility.
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.
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?
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
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)
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.
Excellent video. There must be a hierarchy of calls here that we can trace to make sure that our logic makes sense. What is the best way to go through the hierarchy. I displayed the hierarchy for each class and that is one way. But isn't there a tool or something that can help you to analyze the overall structure? Just a thought...
You can look at a stack trace after the fact, but trying to look at a hierarchy in the abstract is tough, since the number of options will be nearly infinite in a "real" application.
Love your videos Tim and I think that you make great clear cut examples! Even with complex cases like coding-principles where i feel that you need some first hand experience to realize how much unnecessary work you create for yourself if not adhering to them! I am very interested if you have any videos or thougths on how to approach taking a big project that stinks badly of design smell to a better place?
Very good video Tim! You gave me ideas to do some changes in an service i am developing right now. I had the wrong idea that if you want to do something as much parametrical and simple you can you should make as much less classes as you can This is absolutely wrong
Thank you, this video is very easy to follow. When you have a program with lots and lots of files, what is your strategy for structuring the directories that contain these files? How do you avoid either filling a few directories with tons of barely-related files, without creating a mess of subdirectories within subdirectories?
Hey Tim... Curious, is the mailing list no longer a thing? If it is, then just letting you know that the "Sign up now" button on the mailing list sign up page in the description of this video just leads back to that same page. Might wanna fix that up, or if it is no longer a thing then maybe change the descriptions on the videos that point to it, letting people know it is no longer functioning. Anyway, again, as always, great video. You really are a saint. My usual routine when I am looking at something in C# for the first time or after a long while since last using that particular feature is to Google it, get an overview of the topic from a few places, then check if you have a video on it. After a few different readings from websites and/or from the large collection of C# books we have at work I will watch one of your videos and it just ties it all together nicely, giving me a working understanding of the topic, enough so that I can then go and implement it into my current project confidently. Tim, I've said this before, and I will continue to say it, you are a real asset to the community, please keep up the great work.
@@IAmTimCorey The page loads fine, its the button on the page that doesn't go anywhere. I've tried it in Chrome, Edge, and Firefox. Clicking it just loads the page again, right clicking and selecting open link in a new tab just opens the same page.
@@nk361 interesting, it worked for me just now on my phone but when trying it previously on my work computer it didn't work. I'll have to try it again tomorrow. I definitely don't have JavaScript disabled but pop ups may be blocked.
Yes, it also extends to methods. Imagine you are doing an IFileService which is basically IO, but one of your methods in that abstraction is called "string CreateFileName(DateTime date, FileType fileType)" then your code will return the name of the file for example "10192021.txt" and that's it, that is the only responsibility, maybe you have another method that creates the file to a particular path but that method shouldnt create the name of the file, the CreateFileName method does that, and the CreateFile does the IO.
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've been watching your material for months, now. You definitely made me advance in my skill set.
I'm glad!
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.
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.
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.
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!
- 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 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.
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
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!
best practical way of showing SRP and clean oop structure I have seen! Thank you!
Glad it was helpful!
This is the way to learn programming. Thanks so much.
You are welcome.
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!
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.
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
Tim, you deserve a medal, thanks for all your effort
You are most welcome. Thanks for watching.
Tim ! You're the best; I learned a lot from you. Thank you for all what you do for us ...
Awesome!
Perfect for beginners, for professional a quick basic recap. I highly recommend this tutorial
Thank you!
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.
Literally, the best videos about solid principles, thank you a lot
You are welcome.
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
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!
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.
Your information providing technique is awesome. You make things clear and simpler. Thank you very much !!!
You're very welcome!
Thanks tim... You never stop to impress your viewers.... Another high quality video...!
Thank you!
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!
People keep complain about I have so many classes for simple job.
You just make my life more easier, thx bro
Awesome!
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.
Best SRP video I ever came accross. Thank you Tim
Thanks for watching!
Very good. I've heard the lecture from "uncle Bob" himself on RUclips, but he never went over the application of the principles. This is helpful. Thanks.
I am glad it was helpful.
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.
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.
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.
You make things so much simpler. Thank you!
You are so welcome!
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!
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?
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!
may you live a thousand years, you and your family,
these videos are unique and extremely useful
I am glad you found them valuable.
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.
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!
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!
Learning C# currently with Unity. Can't thank enough for these videos. Good job!
You are most welcome. Thanks for watching.
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: ruclips.net/video/LUv20QxXjfw/видео.html
I forgot to thank you for this playlist ... very well explained !!!
You are most welcome. Thanks for watching.
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
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.
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!
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).
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!
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.
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!
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 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.
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.
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.
I changed it and i really like it the way i did it, thank you Tim!
Great job!
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.
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 - ruclips.net/channel/UC-ptWR16ITQyYOglXyQmpzw
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.
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!
Now the SRP is clear, Thanks Tim for your effort (y)
Great!
Hi Tim, I a little question arose during this interesting tutorial (tried to find it online but did't find any clear answer): Why would you use non-static classes that contain only static methods (and no other members), such as the PersonValidator? I thought that static classes have a little advantage over non-static classes because they do not require instances created for each new object, so that means, they consume fewer resources (no duplication of the same class or member is needed in memory) but that's probably seldom noticeable. Could you shed a little light on this issue (or maybe just say that it doesn't really matter)? Thanks in advance
Hi Tim..can this be explained please?. I too would like to know
You shouldn't. He just showed it as an example so it didn't really matter because you wouldn't use static methods if you followed SOLID principles anyway. You'd probably use something like dependency injection instead.
@@LeMustache Thanks a lot
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.
Thank you Tim..
Respect from India
You are welcome.
Great work MR.Corey it was really helpful.
but I think this particular design pattern and what it means is so debatable,
for example, on the validation class from my pov it makes two job one is validating input and another is displaying error messages .
so i think there no easy answer for what is a single responsibility means and that is the problem that causes the arguments among developers.
Like with anything in development, you need to use your best judgement. This isn't about having a rule, it is about having a guideline.
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).
Hi @IAmTimCorey!
First of all :
Thank you very much for these videos, they give me hope to eventually become the developer I want to be.
But while watching I had trouble understanding a specific thing about your exampe.
Could you please explain to me in simple terms why you split the capturing, validation and the user itself into different classes?
As far as I understood you did this to honor SRP so every class would have one responsibility (storing data, validatin and creation).
But all of these classes worked with User only and ontop of that the methods all were static, making it impossible to properly override methods.
I personally would have put the creation and validation into the User class, as all the methods are related to User.
Thank you in advance!
I am a little confused,
Can you explain this in terms of MVC
Let's say we have a User controller and service, now In that controller and service we could have a route for find,update,insert,delete, and others, so should we break all of them into their own function or should we do in both controller and service.
I am just confused about when should I stop breaking the code in new classes/functions.
Please explain.
Controllers often break SRP. However, one way to have them not break SRP would be to extract all of the logic out of the controller. The controller's job should be to just provide the endpoints to the consumer. That's it. All of the logic should be in separate methods.
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.
Very good and clear explanation!
But this AccountGenerator class. Is it an actual implementation of Factory Pattern so in the real world it will be called AccountFactory?
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.
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.
Hi,
why not put VALIDATE() as a member method in the Person class? Would not this conform to OOP?
Why did you preferred an extra class?
Thank you!
i think coz this is just simple example ... u know just to clear the idea SRP
I think it's because that way your class would do two things: create the person's information and validate that information. Using SRP a class should do one thing and one thing only. At least that's what I understood.
@@kevinmcculkin8877 Thanks for the clarification. But this doesn't really satisfied me! I hoped you would say that it was only a not-real example, and a developer should have to know when (not) to extract something to extra classes/interfaces according the specific domain needs.
If I will ALWAYS need to perform something (here, validate) to my object (here, the person), which I would do, I would then follow the old-school (!) OOP way, i.e. build an object with all related methods.
In a previous project we used a variation of CQRS, and when needed to validate a model, we inherited from say IValidate and implemented validation in the same model (not in an extra class!). Do we do it the wrong way the whole time!!
Furthermore, let us take the .net FILE class as an example: It has f.e. encrypt & decrypt methods. If we would consider SRP as you described, there should be an extra class for that? May be this is a bad example from me, but just to mention that it makes no sense to extract every functionality to extra classes.
Thanks in advance.
@@ghm7093 "It makes no sense to extract every functionality to extra classes", the same thought that crossed my mind. I can grasp the concept of SRP from this video but i need more real world example in more complicated project.
Thank you so much for that video, amazing the way you explained.
I was just wondering if in some cases it is ok to apply SRP for the methods instead of classes. Trying to use for example the BankAccount class. It would be a class that might have many resposibilities and actions that are related to a bank account. Withdraw, Deposit, Transfer, Print Accounts, variables holding informations about the account and the Client, some getters and setters maybe, and so on. So in this case I will probably need to change this class for more than one reason, maybe change some code in the deposit process, maybe in the withdraw. Therefore my class it is not anymore in the SRP principle and it will be probably needed to scroll the class to view all its content.
It would be really amazing to have classes so small in a way that I couldn’t even need to scroll and I totally understood how great and more organized this would keep the project, but at least for my current programming experience it is really hard to find a way to do that in some cases.
Anyway, thanks for the great video, I am currently reading Clean Code and hopefully I will understand better that after finishing this book and of course a lots of practice 😁
Yes, you can definitely apply it to methods. That doesn't mean you should create messy classes with lots of responsibilities but you can be a bit more broad in the class's responsibility.
Thanks so much for the amazing playlist. You are saving my life :)
You are most welcome. Thanks for watching.
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. :)
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?
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
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!
This is Perfect, straight forward and clear explanation.
Thanks
What is the difference between moving code to different classes vs creating multiple helper methods?
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!
Excellent video. There must be a hierarchy of calls here that we can trace to make sure that our logic makes sense. What is the best way to go through the hierarchy. I displayed the hierarchy for each class and that is one way. But isn't there a tool or something that can help you to analyze the overall structure? Just a thought...
You can look at a stack trace after the fact, but trying to look at a hierarchy in the abstract is tough, since the number of options will be nearly infinite in a "real" application.
Very simple and clean explanation and at the end the patterns are to write a good quality and maintaneble code
Thank you!
You are a great teacher thanks for your tutorials
You are welcome.
Love your videos Tim and I think that you make great clear cut examples! Even with complex cases like coding-principles where i feel that you need some first hand experience to realize how much unnecessary work you create for yourself if not adhering to them!
I am very interested if you have any videos or thougths on how to approach taking a big project that stinks badly of design smell to a better place?
This video will at least get you started: ruclips.net/video/G1S6NZfFvOg/видео.html
Very good video Tim! You gave me ideas to do some changes in an service i am developing right now. I had the wrong idea that if you want to do something as much parametrical and simple you can you should make as much less classes as you can This is absolutely wrong
Give it a try
Thank you Tim for sharing your knowledge and experience
You are welcome.
Thank you, this video is very easy to follow. When you have a program with lots and lots of files, what is your strategy for structuring the directories that contain these files? How do you avoid either filling a few directories with tons of barely-related files, without creating a mess of subdirectories within subdirectories?
That's a tricky solution and it depends entirely on your specific situation unfortunately. There is no one "right" answer.
Well explained Tim Corey. Thank you for the beautiful video.
You are welcome.
Thank you!
The design pattern videos have been very helpful! any chance you would make one about "strategy pattern"? That would be awesome!
It is on the list. Thanks for the suggestion.
Hey Tim... Curious, is the mailing list no longer a thing? If it is, then just letting you know that the "Sign up now" button on the mailing list sign up page in the description of this video just leads back to that same page. Might wanna fix that up, or if it is no longer a thing then maybe change the descriptions on the videos that point to it, letting people know it is no longer functioning.
Anyway, again, as always, great video. You really are a saint. My usual routine when I am looking at something in C# for the first time or after a long while since last using that particular feature is to Google it, get an overview of the topic from a few places, then check if you have a video on it. After a few different readings from websites and/or from the large collection of C# books we have at work I will watch one of your videos and it just ties it all together nicely, giving me a working understanding of the topic, enough so that I can then go and implement it into my current project confidently.
Tim, I've said this before, and I will continue to say it, you are a real asset to the community, please keep up the great work.
HTTPS://signup.IAmTimCorey.com is still working (just checked). Could it be a browser issue?
@@IAmTimCorey The page loads fine, its the button on the page that doesn't go anywhere. I've tried it in Chrome, Edge, and Firefox. Clicking it just loads the page again, right clicking and selecting open link in a new tab just opens the same page.
@@mileswilliams527 It worked for me, you might have popups disabled or javascript disabled or something similar.
@@nk361 interesting, it worked for me just now on my phone but when trying it previously on my work computer it didn't work. I'll have to try it again tomorrow. I definitely don't have JavaScript disabled but pop ups may be blocked.
@@mileswilliams527 Hope it works :) I've accidentally disabled popups before and it confused me quite a lot lol
Does SRP only apply to making classes do one thing, or does it extend to making methods do one thing as well?
Yes, it also extends to methods.
Imagine you are doing an IFileService which is basically IO, but one of your methods in that abstraction is called "string CreateFileName(DateTime date, FileType fileType)" then your code will return the name of the file for example "10192021.txt" and that's it, that is the only responsibility, maybe you have another method that creates the file to a particular path but that method shouldnt create the name of the file, the CreateFileName method does that, and the CreateFile does the IO.