Tag Archives: Single Responsibility Principle

The Rule I Followed to become a Great Developer

DISCLAIMER: The article is in no way an intention of bragging about my development capabilities. The intention is only to emphasize in so many ways on a rule which can surely, in my opinion, help developers improve quite a notch and become a better developer. I would like to reach as many developers as possible with an intention to create a belief in them regarding the principle I spoke. Thanks for reading the blog. Please feel free to share. For several years that I spent in IT industry while working on a different roles and responsibilities such as developer, technology lead and architect, I was looking for that ONE THUMB …

Continue reading

Posted in Software Quality. Tagged with , .

Stay Single and Get Admired for Your Code

You might be wondering on the relationship between staying single, getting admired and coding! And, then, staying single forever 🙂 is something which may not be liked by most of us. So, what is this blog all about? Well, with “single, I am trying to point at “Single Responsibility Principle” and with “stay single”, I am pointing towards writing code based on “single responsibility principle”. Well, as the title of this blog goes, if you keep the “Single” responsibility principle (SRP) in mind while writing your code, there are high chances that you will end up with a great piece of code which will get liked by many including your …

Continue reading

Posted in Maintainability, Reusability, Software Quality. Tagged with , , , .

Multiple Classes with Single responsibility VS Single Class with Multiple Responsibilities

While taking a session with a set of mobile developers, one of them asked a question that made many of them curious. Why multiple classes when single class can do? The main reasoning for single class was that one would be able to save some lines of code. Also, one would be required to create just one object for multiple functionalities. Lets look at some of the key advantages of multiple classes, each one of them having single functionality. High in cohesion, and hence reduced coupling. This tends to make the class reusable. Lesser costly to change than single class. Following explains the cost structure related with a change: Let’s …

Continue reading

Posted in Maintainability, Software Quality. Tagged with , , , .