Martin suggests that we define each responsibility of a class as a reason for change.
If instead the class were broken up into several, highly cohesive classes, each would be used by fewer other elements of the system, and so a change to any one of them would have a lesser impact on the total system. Nonetheless, classes that depend on the class must all be retested as a result of the change, increasing the total surface area of the application that is affected by the change. If a class has poor cohesion, some part of it may change that only certain depending classes utilize, while the rest of it may remain unchanged. When other classes make use of a particular class, and that class changes, the depending classes must be tested to ensure they continue to function correctly with the new behavior of the class. All of the contents of a single class are tightly coupled together, since the class itself is a single unit that must either be entirely used or not at all (discounting static methods and data for the moment). Coupling refers to how inextricably linked different aspects of an application are, while cohesion refers to how closely related the contents of a particular class or package may be. The Single Responsibility Principle is closely related to the concepts of coupling and cohesion.
#Single responsibility principle java software
Martin in an article that later formed a chapter in his Principles, Patterns, and Practices of Agile Software Development book.
It was first cited in this form by Robert C. The Single Responsibility Principle (SRP) states that a class should have only one reason to change.
0 kommentar(er)
