Oop design principle

5,932 views

Published on

Published in: Technology, Education

Oop design principle

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

×