What are some code smells that indicate a violation of the single responsibility principle?

To address this code smell, the extract method refactoring technique can be applied. By breaking down a long method into smaller, focused methods with descriptive names and clear responsibilities, we can improve code readability, maintainability, and reusability. For instance, in a method that validates, formats, and sends an email, we can extract separate methods such as validateEmail, formatEmail, and sendEmail, each handling a specific task, and then call these extracted methods from the original method. This approach enhances code organization and adheres to the SRP by ensuring that each method has a single, well-defined responsibility.

Code smells indicating a violation of SRP: 1. Large Classes/Functions 2. High Cyclomatic Complexity 3. Frequent Changes 4. Inconsistent Naming 5. God Classes 6. Feature Envy 7. Code Duplication 8. Mixing Interface and Implementation 9. Tight Coupling 10. Lack of Cohesion. Addressing these enhances code maintainability and adherence to SRP.

Sometimes the function name alone can indicate it had more than one responsibility. Especially if there is `_and_` in the name.

In my experience, a high cyclomatic complexity of a method is also a good indicator that the method is doing too much. If there's a static code analysis tool like Sonarqube in place, it can do a good job at highlighting such areas of code.

One indication of violating the Single Responsibility Principle (SRP) is the presence of large classes that encompass an excessive number of fields, methods, or responsibilities. Large classes tend to be challenging to comprehend, test, and maintain, leading to complexity and reduced code quality. Moreover, they often breach the principle of encapsulation, which advocates for concealing internal details within a class and exposing only its public interface. Large classes can intensify the coupling between different components of a system, creating dependencies where modifying one class impacts multiple others.

To address feature envy and improve code modularity and clarity, the move method or move field technique can be applied. This technique involves relocating the method or field that exhibits feature envy to the class where it logically belongs. By doing so, the codebase becomes more organized, and responsibilities are appropriately distributed among classes, enhancing cohesion and reducing dependencies.

To address the drawbacks associated with switch statements and enhance code maintainability and flexibility, the replace conditional with polymorphism technique can be employed. This technique involves creating subclasses for each case represented by the switch statement and implementing the specific behavior related to each case within the corresponding subclass. By leveraging polymorphism, each subclass can encapsulate its unique behavior, promoting a more modular and extensible design.

To rectify shotgun surgery and enhance code maintainability and flexibility, the move method or move field technique can be employed. This technique entails relocating methods or fields associated with a single responsibility to a centralized class or module. By consolidating related functionality within a cohesive unit, such as a specific class or module, developers can streamline code modifications and reduce the need for widespread changes across the codebase.

Another symptom of violating SRP is having a class with multiple functions that tends to serve different actors. This point is just class-specific, not functions. Let’s look again at the definition of SRP from an actor's point of view. A software module should be responsible for one and only one actor. When you have a class with multiple functions that serve different actors of your system, sooner or later, the code inside one of the functions (or more than one) tends to change. At the end of the day, it is the actor of the system who decides how the system should behave. Things like business needs and user behavior tend to change the software behavior all the time.

Another thing I've found useful that indicates violation of SRP is the number of dependent classes injected into the class in question. If the overall number of dependencies is higher than a particular number, it warrants a deeper dive to find out if the class is handling too many responsibilities.

Overly Complex Classes or Methods: If a class or method is responsible for multiple unrelated tasks, it's a sign of a violation of the Single Responsibility Principle (SRP). For instance, if a class handles both user authentication and database interaction, it violates SRP. High Coupling Between Classes: If modifying one class requires changes in several other classes, it indicates a violation of SRP. This coupling makes the system less maintainable and harder to understand. Violation of the Open/Closed Principle: Violating SRP can often lead to a violation of the Open/Closed Principle (OCP). When a class has multiple responsibilities, it's more likely to be modified for various reasons, breaking its stability and extensibility.