Oop design principle

Oop design principle

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