�ݺ�ߣ

Design Patterns
1.Strategy Pattern

Strategy Pattern?
 스트래티지 패턴(Strategy Pattern)에서는 알고리즘군을 정의하고
각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지을 활용
하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할
수 있다.

예제1
오리 연못 시뮬레이션 게임을 만드는 사람이 처음으로 표준적인 객체지향
기법을 사용하여 Duck이라는 수퍼 클래스를 만든 다음.
그 클래스를 확장하여 다른 모든 종류의 오리를 만들었다.
Duck
quack()
swim()
display()
Duck2
display() {
// 모양
}
Duck1
display() {
// 모양
}
모든 오리들이 꽥꽥 소리르 낼 수 있고
헤엄을 칠 수 있기 때문에 수퍼클래스에서
간단한 코드를 구현.
모든 오리들의 모양ㅇ이 다르기
때문에 display() 메소드는
추상 메소드.
각 형식별로 자기 모양을 화면에
보여주기 위한 display()메소드를
별도로 구현.
이 외에도 다른 수많은
유형의 오리들도
Duck 클래스로부터
상속을 받음

예제1
그런데 이제 오리들이 날아다닐 수 있도록 해야하는 일이생김.
Duck
quack()
swim()
display()
fly(){난다}
Duck2
display() {
// 모양
}
Duck1
display() {
// 모양
}
모든 서브클래스에서
fly()를 상속 받음.
fly()를 추가
기타 Duck서브 클래스

예제1
그런데 이렇게 추가하고나니 모든 오리들이 날아다니기 시작했음. 장난감 오리도 날아다님
Duck
quack()
swim()
display()
fly(){난다}
Duck2
display() {
// 모양
}
수퍼클래스에 fly()메소드를
집어넣었더니 날아다니면
안 될 오리들을 포함한 모든
오리들이 날아다니는 기능이
추가됬음
Duck1
display() {
// 모양
}
Duck3
quack() {
//난 사람소리
}
display() {
//모양
}
미친 오리라서 사람소리를
내도록 quack()를 오버라이드 함

예제1
Duck3
quack() {
//난 사람소리
}
display() {
//모양
}
fly() {
// 아무것도 안함
}
Quack()메소드처럼
fly도 개별구현 하면 됬었음.
Duck4
quack() {
//벙어리
}
display() {
//모양
}
fly() {
// 못남
}
Duck4처럼 벙어리에 날지도 못하는
오리면 이런식으로 구현해줘야함.
여기서 문제 Duck의 행동을 제공하는 데 있어서 상속을 사용할 때 단점이 될수 있는것은?
A. 서브클래스에서 코드가 중복된다.
E. 오리가 날면서 동시에 꽥꽥거릴 수 없다.
B. 싱행시에 특징을 바꾸기 힘들다.
F. 코드를 변경했을 때 다른 오리들한테
C. 오리가 춤추게 만들수 없다.
원치 않은 영향을 끼칠수 있다.
D. 모든 오리의 행동을 알기 힘들다.

상속이 아닌 인터페이스로
정
답
:
A
B
D
E
제품을 갱신을 하기로 결정을 하면 매번 Duck의 서브 클래스의 fly()와 quack()
메소드를 일일이 살펴봐야하고 상황에 따라 오버라이드 해야 할수도 있음.
결국엔 일부 형식의 오리만 날거나 꽥꽥거릴 수 있도록 하는 더 깔끔한 방법을 찾아야 함.
Duck
quack()
swim()
display()
Duck1
display()
fly()
quack()
Duck2
display()
fly()
quack()
Duck3
display()
quack()
Duck4
display()
Flyable
fly()
Quackable
quack()
이런식으로 한다면?

문제점!
모든 서브클래스에 날거나 꽥꽥거리는 기능이 있어야 하는 것은 아니므로
상속을 사용하는 것이 올바른 해결책이 아니라는 것은 알 수 있었음.
서브클래스에서 Flyable, Quackable을 구현 하도록 함으로써 일부 문제점은 해결할 수
있지만, 그렇게 하면 그러한 행동에 대한 코드 재사용을 전혀 기대할 수 없게 됨.

문제를 명확하게 파악하기
상속을 사용하는건 좋지 못하다는건 파악했음.
인터페이스를 사용하는 방법은 괜찮아 보이지만 자바 인터페이스에는
구현된 코드가 들어가지 않기에 코드 재사용을 할수 없다는 문제
즉 한 행동을 바꿀 때마다 그 행동이 정의 되어 있는 서로 다른 서브클래스
들을 전부 찾아서 코드를 바꿔줘야함.
이 상황에서 어울릴 만한 디자인 원칙은
(자바8에서는
인터페이스에도
구현이 가능함.)
디자인 원칙
애플리케이션에서 달라지는
부분을 찾아내고, 달라지지 않는
부분으로부터 분리 시킨다.
“캡슐화”
“바뀌는 부분은 따로 뽑아서 캡슐화시킨다. 그렇게 하면 나중에 바뀌지 않는 부분에는
영향을 미치지 않는 채로 그 부분만 고치거나 확장할 수 있다.”

바뀌는 부분과 그렇지 않은 부분 분리하기
현재는 fly()와 quack()의 문제를 제외하면 Duck클래스는 잘 작동하고 있음.
“변화하는 부분과 그대로 있는 부분”을 분리하려면 두 개의 클래스 집합을 만들어야함.
하나는 나는 것과 관련된 집합. 또하나는 소리내는 것과 관련된 부분.
각 클래스 집합에는 각각의 행동을 구현한 것을 전부 집어넣는다.
Duck Class
쩔뚝
빠름
느림 꽥꽥
안녕
삑삑
나는 행동 소리내는 행동
오리의 행동
바뀌는 부분 뽑기

오리의 행동 디자인
1. 최대한 유영하게 만듬.
2. Duck의 인스턴스에 행동을 할당할수 있어야함.
3. 행동을 동적으로 바꿀수 있으면 좋음 (setter)
두 번째 디자인 원칙
디자인 원칙
구현이 아닌 인터페이스에
맞춰서 프로그래밍한다.
여기에서 인터페이스는 중의적으로쓰임.(자바 or 개념만)
핵심은 실제 싱행시에 쓰이는 객체가 코드에 의해서 고정되자 않도록, 상위 형식
에 맞춰서 프로그래밍함으로써 다향성을 활용해야 한다는 것.

예를 들면
Animal
makeSound()
Cat
makeSound() {
meow()
}
meow() {야옹}
Dog
makeSound() {
back();
}
back(){멍멍}
구현에 맞춘 코드
변수 “d”를 Dog형식으로 선언하면
어떤 구체적인구현에 맞춰서 코딩을 해야함
인터페이스/상위 형식에 맞춘 코드
Dog라는 걸 알고 있긴 하지만 다형성을
활용하여 Animal에 대한 레퍼런스를 사용해도됨
구체적으로 구현된 객체를 실행시에 대입하는 코드
Animal의 하위 형식 가운데 어떤 형식인지 모름.
단지 makeSound()에 대해 올바른 반응을 할 수만 있으면됨

Duck의 행동을 구현하는 방법
<<인터페이스>>
FlyBehavior
fly()
<<인터페이스>>
QuackBehavior
quack()
FlyNoWay
fly() {
// 못남
}
FlyWithWings
fly() {
// 남
}
Squack
quack() {
//삑삑
}
Quack
quack() {
// 꽥꽥
}
이런 식으로 디자인하면 다른 형식의 객체에서도 나는 행동과 소리내는 행동을 재사용할수 있음.
기존 행동 클래스를 수정하거나 건드리지 않고도 새로운 행동을 추가할 수 있음.

Duck 행동 통합하기
가장 중요한 점은 이제 Duck에서 나는 행동과 소리 내는 행동을 Duck 클래스
(또는 서브클래스)에서 정의한 메소드를 써서 구현하지 않고 다른 클래스에 위임한다는것.
1. 두 개의 인터페이스 형식의 인스턴스 변수를 추가.
각 서브클래스에서는 실행시에 이변수에 틍정 행동양식
에 대한 레퍼런스를 다형적으로 설정.
Duck
quack()
swim()
display()
fly()
Duck
FlyBehavior flyBehavior
QuackBehavior quackBehavior
preformQuack()
swim()
display()
preformFly()
변경

Duck 행동 통합하기2
2 performQuack() 구현
소리내는 행동을 직접 처리하는 대신,
quackBehavior로 참조되는 객체에 그 행동을 위임.
3.인스턴스 변수 설정방법
소리를 처리할때
Quack클래스를 사용하기에
performQuack()이 호출되면
행동은 Quack 객체에게 위임됨.

캡슐화된 행동을 큰 그림으로 보기
Duck
FlyBehavior flyBehavior
QuackBehavior quackBehavior
preformQuack()
swim()
display()
preformFly()
Duck1
display()
Duck2
display()
Duck3
display()
<<인터페이스>>
FlyBehavior
fly()
FlyNoWay
fly() {
// 못남
}
FlyWithWings
fly() {
// 남
}
<<인터페이스>>
QuackBehavior
quack()
Squack
quack() {
//삑삑
}
Quack
quack() {
// 꽥꽥
}
각 행동의 집합을
알고리즘군으로
생각함.

클래스 사이의 관계
“A는 B이다“ 보다 “A에는 B가 있다”가 나을수 있다.
FlyBehavior와 QuackBehavior가 있음 각각 행동과 소리내는행동을 위임받음
두 클래스를 이런 식으로 합치는 것을 구성(composition)을 이용하는 것이라고함.
Duck클래스에서는 행동을 상속받는 대신, 올바른 행동 객체로 구성됨으로써 행동을 부여받음.
이는 곧 세 번째 디자인 원칙임.
디자인 원칙
상속보다는 구성을 활용한다.
구성을 이용하여 시스템을 만들면 유연성을 크게 향상시킬 수 있다.
단순히 알고리즘군을 별도의 클래스의 집합으로 캡슐화할 수 있도록
만드는 것 뿐 아니라 구성요소로 사용하는 객체에서 올바른 행동
인터페이스를 구현하기만 하면 실행시에 행동을 바꿀 수도 있게 해줌.

�ݺ�ߣ

Design patterns

More Related Content

Design patterns