의존관계역전원칙 DIP Bridge pattern Layer architecture 에 관한 PT

1. DIPBridge patternLayer architecture Devrookie, http://cafe.naver.com/devrookie 최기원

2. DIP Bridge pattern Layer architecture

3. DIP Bridge pattern Layer architecture 설계

4. 소프트웨어 설계 왜 공부해야 할까? 개발중인 게임은 계속 바뀐다. 서비스중인 게임은 계속 바뀐다.

5. 소프트웨어 설계 왜 공부해야 할까? 개발중인 게임은 계속 바뀐다. 서비스중인 게임은 계속 바뀐다. 점프 만들어주세요.

6. 소프트웨어 설계 왜 공부해야 할까? 개발중인 게임은 계속 바뀐다. 서비스중인 게임은 계속 바뀐다. 점프 만들어주세요. 마영전 봐라 다음주부터 점프한댄다.

7. 다음달부터는 말탈지도 몰라.. 화살도 쏴야 하고.. 말타면서 화살도 쏘고.. 말타고 경주하는 레이싱 모드.. 날아다니는 개새 몬스터가 추가될지도...

8. 다음달부터는 말탈지도 몰라.. 화살도 쏴야 하고.. 말타면서 화살도 쏘고.. 말타고 경주하는 레이싱 모드.. 날아다니는 개새 몬스터가 추가될지도... 개새 이야기는 이창희님 PT를 보세요.

9. 어떻게 하면 유연하게 기능을 추가 할 수 있을까?

10. 응집도는 높게(High Cohesion) 의존성은 낮게 (Loose Coupling) 소프트웨어 디자인과 아키텍쳐 평가의보편적이고 일반적인 기준

11. 응집도 높게 하나의 모듈에 하나의 기능을 온전히 담게 하는것

12. 응집도가 높으면 뭐가 좋을까? ‘점프를 넣어주세요’ 라는 요구사항이 생겼을때.. 케릭터 기능만 수정 하면 된다. 될까? 현실적으로 ㅡㅡ;; 뻥치는거 같애 응집도가 와방 높다면 케릭터 쪽만 하면 되겠죠.

13. 의존성 서로 다른 기능의 모듈이 얼마나 얽혀 있는가. 상호 의존도가 얼마나 높은가

14. 의존성이 낮으면 뭐가 좋을까? ‘점프를 넣어주세요’ 라는 요구사항이 생겼을때.. 케릭터 기능만 수정 하면 된다. 될까? 현실적으로 ㅡㅡ;; 뻥치는거 같애 의존성이 와방 낮다면 케릭터 쪽만 하면 되겠죠.

15. 응집도 ∝ 의존성 어떻게 설계하면 응집도가 올라가고 의존성이 내려갈까?

16. OOP 설계 5대 원칙 SRP (Single Reponsibility) 단일 책임 원칙 OCP (Open Close) 개방 폐쇄 원칙 LSP (Liskov Substitution) 리스코프 교체 원칙 ISP (Interface Segregation) 인터페이스 격리 원칙 DIP (Dependency Inversion) 의존 관계 역전 원칙 OOP 설계를 할때 이것들을 한번씩 생각 하면 , 응집도는 높아지고 의존성은 낮아진다.

17. OOP 설계 5대 원칙 SRP (Single Reponsibility) 단일 책임 원칙 OCP (Open Close) 개방 폐쇄 원칙 LSP (Liskov Substitution) 리스코프 교체 원칙 ISP (Interface Segregation) 인터페이스 격리 원칙 DIP (Dependency Inversion) 의존 관계 역전 원칙

18. DIP Bridge pattern Layer architecture

19. Dependency 의존관계Inversion 역전Principle 원칙 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다.

20. Dependency 의존 관계 LightSwitch Light LigthSwitch는 Light의 기능을 사용하여 자신의 기능을 수행한다.

21. Class LightSwitch { … public: void on() { pLight->on(); } void off() { pLight->off(); } void setLight(Light* p) { pLight = p; } … private: Light* pLight; … } Class Light { … public: void on(); void off(); … }

22. …Light stand; LightSwitch stand_switch; // stand_switch에 stand를 연결 stand_switch.setLight(&stand); stand_switch.on(); // stand를 킨다. ... stand_switch.off(); // stand를 끈다. ...

23. Dependency 의존 관계 LightSwitch Light

24. Dependency Inversion 의존 관계 역전? LightSwitch Light

25. Class LightSwitch { … public: void on(); void off(); … } Class Light{ … public:void on() { pSwitch->on(); } void off() { pSwitch->off();} … private: LightSwitch* pSwitch; }

26. ? Class LightSwitch { … public: void on(); void off(); … } Class Light{ … public:void on() { pSwitch->on(); } void off() { pSwitch->off();} … private: LightSwitch* pSwitch; } 역전

27. 역전의 의미 인터페이스를 누가 정하는가!!!

28. 파란게 빨간걸 의존한다. <<interface>> ISwitchableObject Switch Light Switch는 Switch로서의 기능만을 Light는 Light로서의 기능만을 한다.

29. Switch가 인터페이스를 제공한다. <<interface>> ISwitchableObject Switch

30. Class Switch { … public: void on() { pSObject->on(); } void off() { pSObject->off();} void setSwitchableObject ( ISwitchableObject* p ) { pSObject = p; } … private: ISwitchableObject* pSObject; … } Class ISwitchableObject { … public: virtual void on() = 0; virtual void off() = 0; … }

31. Light가 인터페이스에 맞게 구현을 바꾼다. <<interface>> ISwitchableObject Light

32. Class Light : public ISwitchableObject { … public: void on(); void off(); … } Class ISwitchableObject { … public: virtual void on() = 0; virtual void off() = 0; … }

33. 파란게 빨간걸 의존한다. <<interface>> ISwitchableObject Switch Light Switch는 Switch로서의 기능만을 Light는 Light로서의 기능만을 한다.

34. …SwitchableObject pLight = new Light; Switch lightSwitch; lightSwitch.setSwitchableObject(pLight); lightSwitch.on(); lightSwitch.off(); ...

35. 뭐가 붙어도 Switch는 수정이 필요없다. 하지만, Switch 인터페이스 수정하면 대망, 확장은 상관 없다. <<interface>> ISwitchableObject Switch Light TV 이것저것

36. 뭐가 붙어도 Switch는 수정이 필요없다. 하지만, Switch 인터페이스 수정하면 대망, 확장은 상관 없다. OpenClose Principle <<interface>> ISwitchableObject Switch Light TV 이것저것

37. …SwitchableObject pTv = new TV(); Switch tvSwitch; tvSwitch.setSwitchableObject(pTv); tvSwitch.on(); tvSwitch.off(); ... …SwitchableObject pLight = new Light; Switch lightSwitch; lightSwitch.setSwitchableObject(pLight); lightSwitch.on(); lightSwitch.off(); ...

38. DependencyInversion Principle 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다. 복습 <<interface>> ISwitchableObject Switch Light

39. DIP Bridge pattern Layer architecture

40. 패턴 이란? 의존성은 낮게응집도는 높게 하다 보니 자주 사용되는 설계 패턴이 생겼다.

41. Bridge Pattern Client <<interface>> Implementor Abstraction RefinedAbstraction ConcreteImplemntorA ConcreteImplemntorB

42. Bridge Pattern 정적인 구조 보다는 패턴의 의도가 중요하다. Client <<interface>> Implementor Abstraction RefinedAbstraction ConcreteImplemntorA ConcreteImplemntorB

43. Bridge Pattern 의도 : 인터페이스를 통해 서브시스템사이의 의존성을 없앤다. 이는 한 서브시스템의 변화가 다른 서브시스템에 영향을 미치지 못하게 한다.

44. DIP를 Pattern으로 응용하면

45. ISwitchableObject 인터페이스를 통해 Switch와 Light사이의 의존성을 없앴다. <<interface>> ISwitchableObject Switch 인터페이스를 통해 서브시스템사이의 의존성을 없앤다. 이는 한 서브시스템의 변화가 다른 서브시스템에 영향을 미치지 못하게 한다. Light

46. 패턴에 대한 생각. 그냥 귀에 걸면 귀걸이 코에 걸면 코걸이 원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게응집도 높게만들자.

47. 패턴에 대한 생각. 그냥 귀에 걸면 귀걸이 코에 걸면 코걸이 원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게응집도 높게만들자.

48. DIP Bridge pattern Layer architecture

49. Dependency InversionPrinciple Architecture에 응용하면?

50. 아키텍처 가장 첫단계는 시스템을 추상화 수준에 따라서 구분한다.

51. 일반적인 게임의 아키텍쳐

52. 의존관계를 따지면 렌더러 게임로직 시스템

53. <<interface>> 렌더러가 사용하는 인터페이스 렌더러 <<interface>> 게임로직이 사용하는 인터페이스 게임로직 DIP 적용 시스템

54. DependencyInversion Principle 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다. <<interface>> 렌더러가 사용하는 인터페이스 렌더러 <<interface>> 게임로직이 사용하는 인터페이스 게임로직 시스템 또 다시 복습

55. 끝, 정리 오늘 이야기한 것들을 두개의 키워드로 정리하면 뭘까요? 질문???

56. 박일님 PT http://parkpd.egloos.com/3339098 공봉식님 PT http://www.slideshare.net/kongbong/3-4646419 Kasa 이창희님 PT http://dev3d.tistory.com/32 NDC2010, 김주복님 PT 46~55p http://ndc.nexon.com/150088595939