Strategy Pattern: 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 한다. 이 패턴을 사용하면, 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.
정의를 보면 이해하기가 어렵다..
1. 초기 모습
가. 오리 클래스가 존재하고, 공통 행동으로 보여주기, 수영하기, 울기 등이 메소드로 구현되어 있다.
나. 특정 오리 클래스를 만들어서 상속 받은 뒤 필요한 부분을 오버라이딩한다.
2. 문제: 오리들이 날 수 있게 되어서 날기 라는 메소드를 추가하고 싶다.
가. 해결1: 오리 클래스에 날기 라는 메소드를 추가한다, 즉 모든 오리 클래스가 날 수 있게 된다.
-> 어떤 오리는 날지 않을 수 있고 나는 모습은 변할 수 있다. 이럴 경우, 일일이 자식 클래스를 확인해서 체크해줘야 한다.
-> 울기 라는 메소드도 날기 라는 메소드와 마찬가지로 오리마다 구현이 다르고 자주 변할 수 있다.
나. 해결2: 날기와 울기에 대한 인터페이스를 만들어서 자식 오리들이 필요한 경우 상속받게 한다.
-> 이 경우, 어쨋든 자식마다 구현을 해줘야하는 불편함이 있다.
(JAVA를 잘 모르지만, 다중 상속이 되지 않아 인터페이스의 경우에는 상속받는 자식들을 따로 구현해줘야해서 그런 것 같다.
그렇다면 C++ 은 다중 상속이 가능하니, 괜찮은건가?)
-> 또한, 새로운 오리를 만들 때마다, 상속을 다시 해줘야하는 불편함도 있다.
다. 해결3: 날기와 울기에 대한 인터페이스에 자식으로 세세한 구현을 하도록 한 뒤, 이 인터페이스를 오리 클래스의 멤버로 만든다.
-> 이렇게 하면 날기라는 인터페이스를 상속받은 클래스들은 높이 날기, 낮게 날기, 날지 못 함 식으로 자식들을 구현한 뒤,
오리 클래스를 만들 때, 특징에 대해 초기화를 하는 방식으로 유연하게 대처가 가능하다.
그림으로 보면 위와 같다.
이렇게 하면 오리들의 클래스를 생성할 때, 어떤 나는 형식을 쓸 것인지 초기화해줌으로써, 더 유연하게 할 수 있고, 재사용성도 높아진다.
간단히 하면 "자주 변하는 것들은 상속으로 하지 말고, 따로 인터페이스(클래스)로 만들어서 멤버 변수로 추가하라는 것이다."
사실 정확히 이해한 것인지 잘 모르겠다..