View
913
Download
2
Category
Preview:
DESCRIPTION
dip,bridge pattern,layer architecture,의존관계 역전 원칙에 관한 PT
Citation preview
DIPBridge patternLayer architecture
Devrookie, http://cafe.naver.com/devrookie
최기원
소프트웨어 설계
왜 공부해야 할까?
개발중인 게임은 계속 바뀐다.
서비스중인 게임은 계속 바뀐다.
소프트웨어 설계
왜 공부해야 할까?
개발중인 게임은 계속 바뀐다.
서비스중인 게임은 계속 바뀐다.
점프 만들어주세요.
소프트웨어 설계
왜 공부해야 할까?
개발중인 게임은 계속 바뀐다.
서비스중인 게임은 계속 바뀐다.
점프 만들어주세요.
다음달부터는 말탈지도 몰라..
화살도 쏴야 하고..
말타면서 화살도 쏘고..
말타고 경주하는 레이싱 모드..
날아다니는 개새 몬스터가 추가될지도...
다음달부터는 말탈지도 몰라..
화살도 쏴야 하고..
말타면서 화살도 쏘고..
말타고 경주하는 레이싱 모드..
날아다니는 개새 몬스터가 추가될지도...
개새 이야기는 이창희님 PT를 보세요.
어떻게 하면 유연하게 기능을 추가할 수 있을까?
응집도는 높게 (High Cohesion)
의존성은 낮게 (Loose Coupling)
소프트웨어 디자인과 아키텍쳐 평가의보편적이고 일반적인 기준
응집도 높게
하나의 모듈에 하나의 기능을 온젂히 담게 하는것
응집도가 높으면 뭐가 좋을까?
‘점프를 넣어주세요’ 라는 요구사항이 생겼을때..
케릭터 기능만 수정 하면 된다.
의존성
서로 다른 기능의 모듈이 얼마나얽혀 있는가.
상호 의존도가 얼마나 높은가
의존성이 낮으면 뭐가 좋을까?
‘점프를 넣어주세요’ 라는 요구사항이 생겼을때..
케릭터 기능만 수정 하면 된다.
응집도 ∝ 의존성
어떻게 설계하면 응집도가 올라가고의존성이 내려갈까?
OOP 설계 5대원칙SRP (Single Reponsibility)
단일 책임 원칙
OCP (Open Close)개방 폐쇄 원칙
LSP (Liskov Substitution)리스코프 교체 원칙
ISP (Interface Segregation)인터페이스 격리 원칙
DIP (Dependency Inversion)의존 관계 역젂 원칙
OOP 설계 5대원칙SRP (Single Reponsibility)
단일 책임 원칙
OCP (Open Close)개방 폐쇄 원칙
LSP (Liskov Substitution)리스코프 교체 원칙
ISP (Interface Segregation)인터페이스 격리 원칙
DIP (Dependency Inversion)의존 관계 역젂 원칙
Dependency 의존관계Inversion 역젂Principle 원칙
상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다.
Dependency
의존 관계
LightSwitch LightLigthSwitch는 Light의 기능을 사용하여 자싞의 기능을 수행한다.
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();
…
}
…Light stand;
LightSwitch stand_switch;
// stand_switch에 stand를 연결
stand_switch.setLight(&stand);
stand_switch.on(); // stand를 킨다.
...
stand_switch.off(); // stand를 끈다.
...
Dependency
의존 관계
LightSwitch Light
Dependency Inversion
의존 관계 역젂?
LightSwitch Light
Class LightSwitch {
…
public:
void on();
void off();
…
}
Class Light{
…
public:void on()
{ pSwitch->on(); }
void off()
{ pSwitch->off(); }
…
private:
LightSwitch* pSwitch;
}
Class LightSwitch {
…
public:
void on();
void off();
…
}
Class Light{
…
public:void on()
{ pSwitch->on(); }
void off()
{ pSwitch->off(); }
…
private:
LightSwitch* pSwitch;
}
역젂의 의미인터페이스를 누가정하는가!!!
파란게빨간걸의존한다.
Switch
Light
<<interface>>
ISwitchableObject
Switch가인터페이스를제공한다.
Switch<<interface>>
ISwitchableObject
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;
…
}
Light가인터페이스에맞게구현을바꾼다.
Light
<<interface>>
ISwitchableObject
Class Light : public
ISwitchableObject {
…
public:
void on();
void off();
…
}
Class ISwitchableObject {
…
public:
virtual void on() = 0;
virtual void off() = 0;
…
}
파란게빨간걸의존한다.
Switch
Light
<<interface>>
ISwitchableObject
…SwitchableObject pLight = new Light;
Switch lightSwitch;
lightSwitch.setSwitchableObject(pLight);
lightSwitch.on();
lightSwitch.off();
...
뭐가붙어도 Switch는수정이필요없다. 하지만,
Switch인터페이스수정하면대망, 확장은상관없다.
Switch
Light
<<interface>>
ISwitchableObject
TV 이것저것
뭐가붙어도 Switch는수정이필요없다. 하지만,
Switch인터페이스수정하면대망, 확장은상관없다.
Switch
Light
<<interface>>
ISwitchableObject
TV 이것저것
…SwitchableObject pTv = new TV();
Switch tvSwitch;
tvSwitch.setSwitchableObject(pTv);
tvSwitch.on();
tvSwitch.off();
...
DependencyInversionPrinciple
상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다.
패턴 이란?의존성은낮게응집도는 높게하다보니자주 사용되는설계패턴이생겼다.
Bridge Pattern
Abstraction
RefinedAbstraction
<<interface>>
Implementor
ConcreteImplemntorA ConcreteImplemntorB
Client
Bridge Pattern
Abstraction
RefinedAbstraction
<<interface>>
Implementor
ConcreteImplemntorA ConcreteImplemntorB
Client
Bridge Pattern의도 :
인터페이스를 통해 서브시스템사이의의존성을 없앤다. 이는 한 서브시스템의 변화가 다른 서브시스템에 영향을 미치지 못하게 한다.
DIP를 Pattern으로응용하면
ISwitchableObject 인터페이스를통해 Switch와 Light사이의의존성을없앴다.
패턴에 대한 생각.그냥 귀에 걸면 귀걸이 코에 걸면 코걸이
원리도 비슷하고 목적도 비슷하고 그냥
의존성은낮게응집도높게만들자.
패턴에 대한 생각.그냥 귀에 걸면 귀걸이 코에 걸면 코걸이
원리도 비슷하고 목적도 비슷하고 그냥
의존성은낮게응집도높게만들자.
Dependency InversionPrinciple
Architecture에 응용하면?
아키텍처
가장 첫단계는 시스템을추상화 수준에 따라서구분한다.
일반적인 게임의 아키텍쳐
Lv3렌더링레이어
Lv2 게임 로직 레이어
Lv1 시스템 레이어
의존관계를 따지면
렌더러 게임로직 시스템
렌더러<<interface>>렌더러가사용하는인터페이스
게임로직<<interface>>
게임로직이사용하는인터페이스
시스템
DependencyInversionPrinciple
상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는안되고, 양자 모두 추상화에 의존해야 한다. 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다.
렌더러<<interface>>렌더러가 사용하는인터페이스
게임로직<<interface>>
게임로직이 사용하는인터페이스
시스템
끝, 정리
오늘 이야기한 것들을
두개의 키워드로 정리하면 뭘까요?
질문???
박일님 PThttp://parkpd.egloos.com/3339098
공봉식님 PThttp://www.slideshare.net/kongbong/3-4646419
Kasa 이창희님 PThttp://dev3d.tistory.com/32
NDC2010, 김주복님 PT 46~55p
http://ndc.nexon.com/150088595939
Recommended