![]() Certainly in my university classes, Java was our language of choice and most of our exercises and lessons used it. In the early 2000's, Java and C++ were king. I'll dive into each letter below and explain its original meaning, as well as an expanded meaning that can apply outside of OO programming. As a whole, the SOLID principles make arguments for how code should be split up, which parts should be internal or exposed, and how code should use other code. It was proposed as a way to think specifically about the quality of object-oriented (OO) programming. SOLID is a set of principles distilled from the writings of Robert C. ![]() But in a world of multi-paradigm programming and cloud computing, do they still stack up? I'm going to explore what SOLID stands for (literally and figuratively), explain why it still makes sense, and share some examples of how it can be adapted for modern computing. Contact me before republishing this content.The SOLID principles are a time-tested rubric for creating quality software. 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. Creating another class or method doesn’t cost a thing. 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 |