Applying the Single Responsibility Principle in Industry: Modularity Benefits and Trade-offs

Refactoring is a prevalent technique that can be applied for improving software structural quality. Refactorings can be applied at different levels of granularity to resolve 'bad smells' that can be identified in various artifacts (e.g., methods, classes, packages). A fundamental software engineering principle that can be applied at various levels of granularity is the Single Responsibility Principle (SRP), whose violation leads to the creation of lengthy, complex and non-cohesive artifacts; incurring smells like Long Method, God Class, and Large Package. Such artifacts, apart from being large in size tend to implement more than one functionalities, leading to decreased cohesion, and increased coupling. In this paper, we study the effect of applying refactorings that lead to conformance to the SRP, at all three levels of granularity to identify possible differences between them. To study these differences, we performed an industrial case study on two large-scale software systems (more than 1,500 classes). Since SRP is by definition related to modularity, as a success measure for the refactoring we use coupling and cohesion metrics. The results of the study can prove beneficial for both researchers and practitioners, since various implications can be drawn.