객체지향 원리
1. 변하는 것은 캡슐화하라
2. 구현에 의존하기보다는 인터페이스에 의존하도록 코딩하라.
3. 각 클래스는 변경 요인이 오직 하나이어야 한다.
4. 클래스는 행동과 기능에 관한 것이다.
객체지향 원리 추가!
원리 #1
OCP(Open-Closed Principle) <= 유연성
클래스 폐쇄와 개방
폐쇄 - private 등
개방 - 상속, 오버라이드, public 등
원리 #2
DRY(Don't Repeat Yourself) <= 중복코드 없세기
시스템의 각 정보와 기능을 말이되는 하나의 장소에 두는 것을 의미
원리 #3
SRP(Single Responsibility Principle) <= 하나의 책임만 같는 객체
책임 찾기 방법
1. ______ 이(가) 자신을 ______ 한다. => 객체(클래스) 이(가) 자신을 메서드 한다.
2. ______ 이(가) ______ 를 ______ 한다. => 객체(클래스) 이(가) 파라미터를 메서드 한다.
ex) 차가 자신을 운전 한다. (O)
ex) 차가 자신을 세차 한다. (X) => 세차장이 자신을 세차 한다? (X) => 세차장이 스스로 차를 세차한다.
원리 #4
LSP(Liskov Substitution Principle) <= 부모 클래스 대체
자식 객체는 부모 객체를 대신할 수 있어야한다.
상속(Injeritance)? or 위임(Delegation)? or 구성(Composition)? or 집합(Aggregation)
=> 상속(is-a), 위임, 구성, 집합(has-a)는 상속 대신하며 상속보다 대개의 경우 선호된다 :
위의 3가지를 쓸 경우 상속보다 대개의 경우 소프트웨어는 더 유연하고 유지보수성, 확장성, 재사용성이 좋아진다.
위임: 기능 확장(포함 관계), 구성: 전체와 부분의 생명주기 동일(interface사용), 집합: 종속적 관계(생명주기 다름)
위의 내용은 Head First OOA&D Chapter 8을 요약한 것이다.
추가된 객체 지향 원리 중 마지막 4번째 LSP 원리는 아직도 이해가 잘 되지 않는다;;
UML에서 구성(Composition)과 집합(Aggregation)을 따로 표시하는데 (속이 꽉찬 다이아몬드와 속이 빈 다이아몬드)
구현 상 어떻게 다른지 그리고 interface를 사용하여 구성을 구현하는데 꼭 interface를 사용해야하는지
뭐 이런점이 의문이 남는다
