Single Responsibility principle [SRP]
This means that any software module just should have one reason to change and that is what is called as responsibility. Let's jump to an example quickly to get this started. In an Inventory Management System for a medicine export business, if there is a Product class then it might have some methods like showExpiryDate(), printReport(), savetoDB(). More than often what happens is that these methods land up being in the same class but they actually exist for three different reasons. Therefore, the showExpiryDate() method might change if the stock keeping department comes up with new stocks which let's say expire in a different way than traditional medicines do. Similarly printReport() will change if the report format changes for some reasons and same is true for savetoDB() if there is a DB related change then this method would also change. There are three methods and thus there are three reasons that these methods might change. What about depending classes ? Depending classes might change too. Simply put SRP emphasis on only one reason to change. If there are more than one reason for something to change then it's time that we take that out from the class.
It might lead to things like keeping the stuff which changes for the same reason together. This will of course will also lead to separating stuff which changes for different reasons. Now, having said that what comes to our mind is the number of classes we are going to deal with ? SRP looks like a recipe for disaster as it might make the place very crowded, isn't it ? How would you name so many classes , so many methods ? Well, it's the opposite which is true. SRP makes life much simpler. Imagine if we have tiny classes with tiny responsibilities then would it be difficult or easier to name them ? On the other hand what if I had a big class then what name can I come up with ? Big long names ? They are hard to think of and difficult to understand when you read them. How can you name something which does multiple things with one name ? Okay,let's take and example. Let's say we have a class by name DailyStockReportGenerator. When you read such names what do you expect it to do ? It might just generate daily stock report. It's precise. Having precise names for many small classes rather than big names from very generic classes might be a good way to start with SRP. This is also true when it comes to methods.
Tiny little functions rather than big huge lines of code in one method. Huge methods are difficult to maintain , bug prone and what not. So how little these functions could be ? Well, there are many ways of looking at it. Some folks say that if your screen starts scrolling it's time to write another function. So 30-40 lines ? Yes, that could be done or make them even more short. What about 10 to 15 lines ? Super focused methods. Another point - if your methods got a IF statement , try to keep that number low. Not more than 4 IF statements maybe. Same is true for while loops. Not more than 3 or 4 of them perhaps. When you do this as a programmer you will feel a bit different if this is the first time you are trying to do it. You are essentially trying to put a great deal of thought into programming. Just compare this with another approach where your method is 100 lines long with no indentation (or what the heck let there be indentation). If you look at that kind of code , it is a nothing but a nightmare ! It takes a long time to even understand this thing and it is very frustrating. I always used to think can't compilers throw this as a bad practice bug ? You know don't compile if there are more than 20 lines in a method :) . That would be something (does that kind of stuff exists ?). So to make a big pile of code understand we will have to cut through it, go deep inside the code. Make use of step modes. Make use of SOPs (in java world) and what not. Instead how nice it would be if you can just read the name of the method and say "Oh this method does this" .
This indeed is very very strong way of working from programming point of view.