2. 대원칙 - 높은 응집도, 낮은 결합도
• 응집도 : 하나의 클래스가 하나의 기능
(책임)을 온젂히 순도 높게 담당하는 정도
– 기능적 응집, 순차적 응집, 교홖적 응집
– 젃차적 응집, 시갂적 응집, 논리적 응집
• 결합도 : 클래스갂의 서로 다른 책임들이
얽혀 있어서 상호의졲도가 높은 정도
– 자료 결합, 스탬프 결합, 제어 결합
3. S.O.L.I.D.
• S : SRP(Single Responsibility)
– 단일 책임 원칙
• O : OCP(Open Close)
– 개방-폐쇄 원칙
• L : LSP(Liskov Substitution)
– 리스코프 교체 원칙
• I : ISP(Interface Segregation)
– 인터페이스 격리 원칙
• D : DIP(Dependency Inversion)
– 의졲 관계 역젂 원칙
4. 하지만 발표는 S.I.O.L.D. 순서로
• S : SRP(Single Responsibility)
– 단일 책임 원칙
• I : ISP(Interface Segregation)
– 인터페이스 격리 원칙
• O : OCP(Open Close)
– 개방-폐쇄 원칙
• L : LSP(Liskov Substitution)
– 리스코프 교체 원칙
• D : DIP(Dependency Inversion)
– 의졲 관계 역젂 원칙
8. Modem 인터페이스 분리
• 인터페이스는 분리, 구현은 그대로(ISP)
– COM 에서 많이 하던 거
• 불필요한 복잡성에 주의
9. GOD 클래스는 항상 나쁜가?
• 응집도를 높혀준다
– 모듞 작업을 한 눈에 확인할 수 있다
– 데이터 연관성을 알기 쉽다
• 결합도를 낮춘다
– GOD 클래스가 decorator 역할을 한다
– 각 part 를 연결하는 whole 의 역할
• player
– inventory -> item
– skill
– party…
• 그래서 ISP 가 필요하다
13. SRP vs ISP
• SRP : Extract Class, Extract Subclass
• ISP : Extract Interface
– 클라이언트가 클래스의 특정 기능만 이용한다면 그런
기능의 부분 집합을 별도의 인터페이스로 추출하라
• ISP 는 한 클래스에서 여러 기능을 통합 제공할 수
있음을 인정하되(façade), 각 서비스를 별도로 제
공하는 인터페이스를 노출
• javax.swing.JTable
– extends JComponent
– implements TableModelListener, Scrollable,
TableColumnModelListener, ListSelectionListener,
CellEditorListener, Accessible
15. OCP : 개방-폐쇄 원칙
• 결국에는 약속(표준안)을 만드는 것
– interface, protocol, standard
• HTTP 표준을 rendering 하는 각종 browser 들
• TCP/UDP 로 통싞하는 여러 OS 들
• C++ 0x 를 지원하는 일부 컴파일러
• 확장에 대해 열려있고 수정에 대해 닫혀있다.
18. interface(표준)의 문제점
• 변경 비용이 비싸다
– interface 가 변경되면 모듞 구현 클래스에서
컴파일 에러 발생
– concrete class 이 뭔지 알기 어렵다
– BlueRay vs HD-DVD
• 충분히 안정될 후 interface 로 뺀다
– 미리 바꾸지 않는다. 첫 번째 총알 맞기
– 어쩌면 게임 하나가 완성된 다음에야?
– EPIC 의 Unreal Tounament?
20. LSP - 리스코프 교체(치홖) 원칙
• 하위타입(subtype) 은 그것의 기반 타입
(base type) 에 대해 치홖 가능해야 한다
• is-a 관계를 만족하는가?
• S형의 각 객체 o1 에 대해 T형 객체 o2가
있고, T에 의해 정의된 모듞 프로그램 P 에
서 T 가 S 로 치홖될 때, P 의 동작이 변하
지 않으면 S 는 T 의 하위타입이다
– 바바라 리스코프(Barbara Liskov). 1988
23. 문제는 어떻게 쓰느냐…
• 부모클래스를 받는 함수는 원칙적으로 어떤
concrete 클래스를 받았는지 모른다
• concrete 클래스 자체에는 논리적 결함이 없어 보
이더라도, 잘못 쓸 가능성이 있다면 문제가 있다
• 같이 로직이 반복되면 up-class 하고 싶겠지만
욕심을 참아야 한다
– 코드 재사용은 상속이 아닌 포함으로
– LSP 에 문제 없거나 composite pattern 이 필요하면
상속으로 해결
– 실보다 득이 많다면, LSP 가 깨지더라도 협약
(convention) 으로 해결할 때도 있다고 저자가 소개함
24. LSP vs OCP
• OCP
– 인터페이스만 같으면 어떤 객체듞 들어올 수
있다
• LSP
– 인터페이스도 같아야 하고, 의미적으로도 동
일해야 한다
30. 결론
• 구조를 잡을때는 싞중하게
• 실제로 써 본 뒤에 구조를 잡는다
• 안정화 단계란 영원히 오지 않을지도?
– 안정된 코드는 오래된 코드가 되어 버린다
– 언제가 “적당”한가?
• 라이브러리보다는 라이브러리를 사용하는
layer 에 초점을 맞춘다
• 젃대적인 법칙은 없다
