"단일 책임의 원칙"
"객체는 하나의 책임만을 맡아야 한다."
억지로 책임을 나누지 않는다. 책임은 변화의 축이며, 하나의 요구사항 변경은 하나의 책임을 변경하게 하는 경우가 많다.
책임의 범위가, 크기가 클수록 변경에 대한 영역도 그만큼 커지게 된다.
하나의 클래스가 여러 책임을 맡는것도 곤란하다.
하나의 책임을 여러 클래스로 분리하는것도 곤란하다.
확실하게 책임에 대한 구현을 은닉해 놓았다면 한 클래스에 두개의 책임이 혼재하더라도 변경으로 인한 여파를 최소화 할 수 있다.
"객체는 하나의 책임만을 맡아야 한다."
억지로 책임을 나누지 않는다. 책임은 변화의 축이며, 하나의 요구사항 변경은 하나의 책임을 변경하게 하는 경우가 많다.
책임의 범위가, 크기가 클수록 변경에 대한 영역도 그만큼 커지게 된다.
변화에 효율적으로 대응할수 있는 크기의 책임을 할당하는것이 좋다.
하나의 클래스가 여러 책임을 맡는것도 곤란하다.
클래스가 여러 원인에 의해 변경되기 때문..
하나의 책임을 여러 클래스로 분리하는것도 곤란하다.
하나의 원인으로 여러 클래스가 변경되기 때문..
확실하게 책임에 대한 구현을 은닉해 놓았다면 한 클래스에 두개의 책임이 혼재하더라도 변경으로 인한 여파를 최소화 할 수 있다.
'Design Patterns' 카테고리의 다른 글
| "LSP", Liskov Substitution Principle (2) | 2012.02.26 |
|---|---|
| "ISP", Interface Segrehation Principle (1) | 2012.02.26 |
| "DIP", Dependency Inversion Principle (0) | 2012.02.26 |
| High Cohesion, Low Coupling. (0) | 2012.02.25 |
| 객체지향 소프트웨어 설계 원칙. (0) | 2012.02.25 |