The Single Responsibility Principle (SRP)

A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE.

하나의 클래스는 변화에 오직 하나의 이유만 있어야 한다.

You’ve probably read the nonsense about objects needing to know how to draw themselves

in a GUI, or save themselves to disk, or convert themselves to XML, right? Beginning

OO texts like to say things like that. Ridiculous! Classes should know about only one

thing. They should have a single responsibility. More to the point, there should only be

one reason for a class to change.

 Consider Figure 6-1. This class knows way too much. It knows how to calculate pay

and taxes, how to read and write itself on disk, how to convert itself to XML and back, and

how to print itself on various reports. Can you smell the Fragility? Change from SAX to

JDOM and you have to change Employee. Change from Access to Oracle, and you have t

change Employee. Change the format of the tax report and you have to change

Employee. This design is badly coupled.

하나의 클래스가 너무나 많은 역할(responsibility)를 가지고 있어 coupling이 극도로 증가한 상태

In reality we want to separate all these concepts into their own classes so that each

class has one, and only one, reason to change. We’d like the Employee class to deal with

pay and taxes, an XML related class to deal with converting Employee instances to and

from XML, an EmployeeDatabase class to deal with reading and writing Employee

instances to and from the database, and individual classes for each of the various reports.

In short, we want a separation of concerns. A potential structure is shown in Figure 6-2

위의 복잡한 것을 각자의 역할을 가지는, 변화에 대해 단 한가지 이유를 가지는 개별의 class로 나누어야 한다.

Violation of this principle is pretty easy to spot in a UML diagram. Look for classes

that have dependencies on more than one topic area. A dead give-away is a class that

implements one or more interfaces that endow it with certain properties. Careless use of an

interface that endows an object with the ability to be stored on disk, for example, can lead

to classes that couple business rules with issues of persistence.

잘못된 interface의 상속구조의 사용한 향후 coupling의 문제를 야기시킨다.

Consider the two diagrams in Figure 6-3. The one on the left couples Persistable

tighly into Employee. All users of Employee will transitively depend upon

Persistable. This dependence may not be great, but it will be there. Changes to the

Persistable interface will have the potential of affecting all users of Employee.

좌측의 구조는 Employee와 Persistable interface가 강하게 coupling된 상태로,

Persistable의 변화가 모든 Employee 클래스에 영향을 줄 수 있다.

The diagram on the right side of Figure 6-3 leaves Employee independen of Persistable,

and yet allows for persistence just the same. Instances of PersistableEmployee

can be passed around the system as Employees, without the rest of the

system knowing about the coupling. The coupling exists, but is hidden to most of the system.

우측의 구조는 Employee가 Persistable에 독립된 구조로,

시스템 상에서 coupling이 없는 상태로 Employee의 형태로만 사용될 수 있다.

coupling은 존재하지만, hidden으로서의 이점이 있다.