![]() As a commonly used definition, "every class should have only one reason to change". The idea behind the SRP is that every class, module, or function in a program should have one responsibility/purpose in a program. The Single Responsibility Principle (SRP) We'll conclude this article by talking about the basics of object oriented design. The examples we will use in this article are going to be very basic. In this article, we'll start by defining each principle and then we'll see some examples to help you understand how and why you should use these principles in your code. Here is what each letter in the acronym stands for: Each letter in the acronym SOLID stands for a specific principle. Contact me before republishing this content.The SOLID design principles help us create maintainable, reusable, and flexible software designs. Remember, you’re optimizing for humans here, and the easier it is for you or another programmer to make changes the better off you’ll be down the road.įor more information about the Single Responsibility Principle, check out Principles of Object Oriented Analysis and Design by James Martin. Good code refactoring can really improve your development process. You should always go back and refactor your code at some point because business rules change, requirements change and things get added on and subtracted. In practice it’s not always easy and sometimes you just have to get your project finished. As you’re designing your application you should always keep this in mind. In theory you want to do this from the very beginning. When to implement the Single Responsibility Principle Just remember, if there is more than one reason to change, split it up. By separating them you give yourself a lot more freedom down the road to change and modify. If you want to create some html, you can create a method to do that, output some JSON, XML whatever, with the same data from the model. You can change the model to connect to any data source you want, and the Page class doesn’t care.Īnd the Page class is now free to output data any way it wants. The page doesn’t care what the model is doing as long as it takes in data (the article id) and outputs data (the article) as expected. The Page class generates web pages, and the Model gets data from your database. Once you break it into two classes you create a Separation of Concerns. Not to mention the fact that your designers and your DBA might both be dipping into the same class… is that something you really want? The Solution Where would that method go? Lumping it all together creates a huge mess later down the road. Plus, let’s say you want to display the output to JSON as well. ![]() This is bad design to have this coupled with your presentation code and even puts it at risk. You have now made drastic changes to the getArticle function, and maybe even the output that comes from the database. What happens when you change databases? This happens all the time. This is not only a violation of the Single Responsibility Principle but Separation of Concerns as well. The reason it’s bad is because it does two separate things, it gets and article from the database, then it outputs html. Why is this bad? It looks pretty simple, and it’s pretty easy to use. query the database for the latest article Take the following class from a blog app: With the MVC movement in full swing you don’t see as much of it anymore, but it still happens. ![]() Ok one of the biggest violators I have seen is mixing presentation with data. This is where extending and inheritance can really come in handy. I know OOP design usually dictates getting as much done in an object as you can, but this can lead to growing pains down the road. As a commonly used definition, 'every class should have only one reason to change'. Creating another class or method doesn’t cost a thing. The Single Responsibility Principle (SRP) The idea behind the SRP is that every class, module, or function in a program should have one responsibility/purpose in a program. Overloading can help there, but it’s still better to separate tasks as much as possible. The problem with that is, when part of that method changes drastically, you may have to modify the signature or output of the method. This goes for methods as well, as sometimes folks tend to cram a bunch of functions into a method. This is easier said than done of course, but the idea is if you have more than one reason to change a class, then you should break it into two classes. The Single Responsibility Principle guides simplicity, and the rule itself is strikingly simple: There should never be more than one reason for a class to change. It’s a good way to keep code working as expected, and to avoid painting yourself in a corner. SRP, or Single Responsibility Principle is one of the foundations building better software. This applies to many things in life and definitely in software development.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |