oop design principle
TRANSCRIPT
OOP 설계의 법칙
박일parkpd.egloos.com
AnDStudy.comhttp://cafe.naver.com/architect1.cafe
대원칙 - 높은 응집도, 낮은 결합도
• 응집도 : 하나의 클래스가 하나의 기능(책임)을 온젂히 순도 높게 담당하는 정도
– 기능적 응집, 순차적 응집, 교홖적 응집
– 젃차적 응집, 시갂적 응집, 논리적 응집
• 결합도 : 클래스갂의 서로 다른 책임들이얽혀 있어서 상호의졲도가 높은 정도
– 자료 결합, 스탬프 결합, 제어 결합
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)– 의졲 관계 역젂 원칙
하지만 발표는 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)– 의졲 관계 역젂 원칙
SRP : 단일 책임 원칙
SRP(Single Responsibility)
SRP : 단일 책임 원칙
• 한 클래스는 하나의 역할만 맡는다.
• 책임 : „변경을 위한 이유‟
• 실제로 변경이 일어낼 때 적용한다
좋아지는 점?
Modem 인터페이스 분리
• 인터페이스는 분리, 구현은 그대로(ISP)– COM 에서 많이 하던 거
• 불필요한 복잡성에 주의
GOD 클래스는 항상 나쁜가?
• 응집도를 높혀준다– 모듞 작업을 한 눈에 확인할 수 있다– 데이터 연관성을 알기 쉽다
• 결합도를 낮춘다– GOD 클래스가 decorator 역할을 한다– 각 part 를 연결하는 whole 의 역할
• player– inventory -> item– skill– party…
• 그래서 ISP 가 필요하다
ISP - 인터페이스 격리 원칙
ISP(Interface Segregation)
ISP - 인터페이스 격리 원칙
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
OCP : 개방-폐쇄 원칙
OCP(Open Close)
OCP : 개방-폐쇄 원칙
• 결국에는 약속(표준안)을 만드는 것– interface, protocol, standard
• HTTP 표준을 rendering 하는 각종 browser 들• TCP/UDP 로 통싞하는 여러 OS 들• C++ 0x 를 지원하는 일부 컴파일러• 확장에 대해 열려있고 수정에 대해 닫혀있다.
관련 패턴 : strategy pattern
interface(표준)의 문제점
• 변경 비용이 비싸다– interface 가 변경되면 모듞 구현 클래스에서
컴파일 에러 발생
– concrete class 이 뭔지 알기 어렵다
– BlueRay vs HD-DVD
• 충분히 안정될 후 interface 로 뺀다– 미리 바꾸지 않는다. 첫 번째 총알 맞기
– 어쩌면 게임 하나가 완성된 다음에야?
– EPIC 의 Unreal Tounament?
LSP - 리스코프 교체(치환) 원칙
LSP(Liskov Substitution)
LSP - 리스코프 교체(치홖) 원칙
• 하위타입(subtype) 은 그것의 기반 타입(base type) 에 대해 치홖 가능해야 한다
• is-a 관계를 만족하는가?
• S형의 각 객체 o1 에 대해 T형 객체 o2가있고, T에 의해 정의된 모듞 프로그램 P 에서 T 가 S 로 치홖될 때, P 의 동작이 변하지 않으면 S 는 T 의 하위타입이다
– 바바라 리스코프(Barbara Liskov). 1988
„하위 호홖성‟ - DirectX
• dll 이 바뀌어도 문제가 없다
직사각형을 상속받은 정사각형
문제는 어떻게 쓰느냐…
• 부모클래스를 받는 함수는 원칙적으로 어떤concrete 클래스를 받았는지 모른다
• concrete 클래스 자체에는 논리적 결함이 없어 보이더라도, 잘못 쓸 가능성이 있다면 문제가 있다
• 같이 로직이 반복되면 up-class 하고 싶겠지만욕심을 참아야 한다– 코드 재사용은 상속이 아닌 포함으로
– LSP 에 문제 없거나 composite pattern 이 필요하면상속으로 해결
– 실보다 득이 많다면, LSP 가 깨지더라도 협약(convention) 으로 해결할 때도 있다고 저자가 소개함
LSP vs OCP
• OCP
– 인터페이스만 같으면 어떤 객체듞 들어올 수있다
• LSP
– 인터페이스도 같아야 하고, 의미적으로도 동일해야 한다
stack
• java.lang.Object– extended byjava.util.AbstractCollection
• extended byjava.util.AbstractList– extended byjava.util.Vector
» extended byjava.util.Stack
DIP - 의존 관계 역전 원칙
DIP(Dependency Inversion)
왜 의졲 관계 역젂인가?
Button 은 Lamp 에의졲관계다
DIP - 의졲 관계 역젂 원칙
• 게임 엔짂의 문제
– 한참 개발하던 도중, 엔짂에 엄청 좋은 기능이추가되었다는 소식을 들었다면?
• interface 를 누가 결정하고 관리하는가?
– OS 업체?
– Printer 같은 주변기기 업체?
관련 패턴 - Template Method
결론
• 구조를 잡을때는 싞중하게
• 실제로 써 본 뒤에 구조를 잡는다
• 안정화 단계란 영원히 오지 않을지도?
– 안정된 코드는 오래된 코드가 되어 버린다
– 언제가 “적당”한가?
• 라이브러리보다는 라이브러리를 사용하는layer 에 초점을 맞춘다
• 젃대적인 법칙은 없다
Reference
• 실젂 코드로 배우는 실용주의 디자인 패턴• 소프트웨어 개발의 지혜 - 야스미디어• zdnet - 객체지향 SW 설계의 원칙
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039134727
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039135552
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039139151
– http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039137043