RDD & SOLID 원칙 [오브젝트 chpt 3]

오브젝트 챕터 3의 내용은 책 객체지향의 사실과 오해 내내 했던 이야기이다.

 

협력(collaboration) ,책임(responsibility),역할(Role) 이라는 단어를 안다면 하단의 Solid 원칙을 다시한번 정리한 부분만 보고 넘어가도 충분하다.

 

Point 

RDD : Responsibility Driven design 하자 , 상태보단 행위 이며 메시지가 객체를 선택하자

• 추상 클라스와 인터페이스 잘쓰자
• 협력 (collaboration) : 객체들끼리 어떠한 기능을 수행하기 위하여 하는 상호작용
• 책임(responsibility) : 협력에 참여하기 위해 객체가 수행하는 행동 . 
• 역할(Role)  : 어떤 특정한 협력 안에서 수행하는 책임의 집합. ~ DIP
• 한종류의 객체만 협력에 참여를 하는 상황이라면 역할의 개념을 생략하고 간단하게 객체로 간주하자

 

 

SOLID - 로버트 마틴

 

1.SRP : Single Responsibility principle

한 클라스는 하나의 책임만 가져야 한다.

 

하나의 책임이란 클 수도 작을 수 있다 . 그럼 중요한 기준은 ?

변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

 

2.OCP : Open/Closed principle

확장에는 열러 있으나 변경에는 닫혀 있다. 이게 무슨 소리?

→ 추상 클레스 인터 페이스를 생각하자. 하난의 메시지를 다양한 방식으로 메서드를 구성할 수 있다.

: 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현

 

→ Dynamic Binding problem , 구현 객체를 변경하려면 클라이언트 코드를 변경해야한다. → IOc , DI 프레임워크를 이용하자.

 

3.LSP : Liskov substitution principle

다형성에서 하위 클래스는 인터페이스 규약을 지켜야한다. 인터페이스를 구현한 구현체를 믿고 사용할려면 필수 이다.

컴파일이 아닌 런타임에서도 동작을 보장해야한다.

 

ex) 할인율 계산 하는 것을 구현한 구현 객체에서 할인율 계산 안하고 딴짓하면 안됨

 

4.ISP : Interface segregation principle 인테페이스 분리 원칙

• 특정 클라이언트를 위한 인터페이스 여래 개가 범용 인터페이스 하나보다 낫다.
• 인터페이스가 명확해지고 대체 가능성이 높아진다.

의존도를 낮추고 결합도를 느슨하게

 

5.DIP : Dependency inversion principle

 

“추상화에 의존해야지 구체화에 의존하지 말아라” : 인터페이스에 의존해야한다. ⇒ 역할(Role)에 의존하게 해야한다.

구현체에 의존하게 되면 변경이 어려워진다 .

 

DRY : don’t repeat yourself