Recommandé
데브루키 스터디 발표
- 1. DIP Bridge pattern Layer architecture Devrookie, http://cafe.naver.com/devrookie 최기원
- 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) 의존 관계 역젂 원칙
- 17. OOP 설계 5대 원칙 SRP (Single Reponsibility) 단일 책임 원칙 OCP (Open Close) 개방 폐쇄 원칙 LSP (Liskov Substitution) 리스코프 교체 원칙 ISP (Interface Segregation) 인터페이스 격리 원칙 DIP (Dependency Inversion) 의존 관계 역젂 원칙
- 19. Dependency 의존관계 Inversion 역젂 Principle 원칙 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화 는 구체적인 구현에 의존해서는 안된다. 구현이 추 상화에 의존해야 한다.
- 20. Dependency 의존 관계 LightSwitch Light LigthSwitch는 Light의 기능을 사용하여 자싞의 기능을 수행한다.
- 21. Class LightSwitch { … Class Light { public: void on() … { pLight->on(); } void off() public: { pLight->off(); } void setLight(Light* p) { pLight = p; } void on(); … private: void off(); Light* pLight; … … } }
- 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 { Class Light{ … … public: public: void on() void on(); { pSwitch->on(); } void off(); void off() { pSwitch->off(); } … … } private: LightSwitch* pSwitch; }
- 26. Class LightSwitch { Class Light{ … … public: public: void on() void on(); { pSwitch->on(); } void off(); void off() { pSwitch->off(); } … … } private: LightSwitch* pSwitch; }
- 28. 파란게 빨간걸 의존한다. <<interface>> Switch ISwitchableObject Light
- 29. Switch가 인터페이스를 제공한다. <<interface>> Switch ISwitchableObject
- 30. Class Switch { … Class ISwitchableObject { public: … void on() { pSObject->on(); } public: void off() virtual void on() = 0; { pSObject->off(); } void setSwitchableObject virtual void off() = 0; ( ISwitchableObject* p ) { pSObject = p; } … … } private: ISwitchableObject* pSObject; … }
- 31. Light가 인터페이스에 맞게 구현 을 바꾼다. <<interface>> ISwitchableObject Light
- 32. Class Light : public Class ISwitchableObject { ISwitchableObject { … … public: public: virtual void on() = 0; void on(); virtual void off() = 0; void off(); … … } }
- 33. 파란게 빨간걸 의존한다. <<interface>> Switch ISwitchableObject Light
- 34. … SwitchableObject pLight = new Light; Switch lightSwitch; lightSwitch.setSwitchableObject(pLight); lightSwitch.on(); lightSwitch.off(); ...
- 35. 뭐가 붙어도 Switch는 수정이 필요없다. 하지만, Switch 인터페이스 수정하면 대망, 확장은 상관 없다. <<interface>> Switch ISwitchableObject Light TV 이것저것
- 36. 뭐가 붙어도 Switch는 수정이 필요없다. 하지만, Switch 인터페이스 수정하면 대망, 확장은 상관 없다. <<interface>> Switch ISwitchableObject Light TV 이것저것
- 37. … SwitchableObject pTv = new TV(); Switch tvSwitch; tvSwitch.setSwitchableObject(pTv); tvSwitch.on(); tvSwitch.off(); ...
- 38. Dependency Inversion Principle 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화 는 구체적인 구현에 의존해서는 안된다. 구현이 추 상화에 의존해야 한다.
- 40. 패턴 이란? 의존성은 낮게 응집도는 높게 하다 보니 자주 사용되는 설계 패턴이 생겼다.
- 41. Bridge Pattern Client <<interface>> Abstraction Implementor RefinedAbstraction ConcreteImplemntorA ConcreteImplemntorB
- 42. Bridge Pattern Client <<interface>> Abstraction Implementor RefinedAbstraction ConcreteImplemntorA ConcreteImplemntorB
- 43. Bridge Pattern 의도 : 인터페이스를 통해 서브시스템사이의 의존성을 없앤다. 이는 한 서브시스 템의 변화가 다른 서브시스템에 영 향을 미치지 못하게 한다.
- 45. ISwitchableObject 인터페이스를 통해 Switch와 Light사이의 의존 성을 없앴다.
- 46. 패턴에 대한 생각. 그냥 귀에 걸면 귀걸이 코에 걸면 코걸이 원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게 응집도 높게 만들자.
- 47. 패턴에 대한 생각. 그냥 귀에 걸면 귀걸이 코에 걸면 코걸이 원리도 비슷하고 목적도 비슷하고 그냥 의존성은 낮게 응집도 높게 만들자.
- 50. 아키텍처 가장 첫단계는 시스템을 추상화 수준에 따라서 구분한다.
- 51. 일반적인 게임의 아키텍쳐 Lv3 렌더링 레이어 Lv2 게임 로직 레이어 Lv1 시스템 레이어
- 52. 의존관계를 따지면 렌더러 게임로직 시스템
- 53. <<interface>> 렌더러 렌더러가 사용하는 인터페이스 <<interface>> 게임로직 게임로직이 사용하는 인터페이스 시스템
- 54. Dependency 렌더러 <<interface>> 렌더러가 사용하는 인터페이스 Inversion 게임로직 <<interface>> 게임로직이 사용하는 인터페이스 Principle 시스템 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다. 추상화 는 구체적인 구현에 의존해서는 안된다. 구현이 추 상화에 의존해야 한다.
- 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