이전 포스팅에서 구현한 프로그램의 문제점에 대해서 생각해 보자
간단한 예를 들어서 문제를 집어보겠다.
오리 시뮬레이션에서 오리가 하늘을 날 수 있도록 하고 싶을때 어떻게 구현해야 할까??
첫번째로 생각해 볼 수 있는것은 super class인 Duck 클래스에 fly()를 추가해주는 것이다.
누구나 가장 먼저 이 생각을 하지 않을까 싶다.
하지만 이렇게 할 경우, 하늘을 날지 않는 나무 오리라든가 고무 오리마저 하늘을 나는 경우가 발생한다.
나무 오리나 고무 오리가 하늘을 날지 못하게 하려면 별 수 없이 overriding(재정의)를 해야 한다.
거기에다가 나무 오리의 경우는 꽥꽥거리지 못하게 quack()도 overriding해줘야 한다.
이렇게 super class에 의존도가 높아지는 코딩을 한다면 다음과 같은 단점이 생긴다.
1. 서브 클래스에서 코드가 중복된다.
2. 실행시에 특징을 바꾸기 힘들다.
3. 모든 오리들의 행동을 알기 힘들다.
4. 코드를 변경했을 때 다른 오리들한테 원치 않은 영향을 끼칠수 있다.
만약 프로그램을 자주 갱신해야 한다면, 정말이지 위와 같은 방법으로 코딩하는 것은 개발자를 잡는 일일 것이다.
그렇다면 다음으로 생각할 수 있는 것은 무엇일까??
상속을 통해서 되지 않는다면, 다음으로 생각할 수 있는 것은 인터페이스가 아닐까 싶다.
인터페이스를 이용한 클래스 다이어 그램을 보자.
새로운 행동을 추가할때 인터페이스를 따른다면 새로운 클래스를 추가할 때마다 fly()와 quack()메소드를 일일이 살펴보고 상황에 따라 override할 필요는 없을 거 같다.
하지만 이렇게 구현할 경우 코드가 중복될 수밖에 없다. 또한 수정해야 하는 경우 중복되는 모든 코드들을 수정해야 한다.(ex fly()를 수정해야 할 경우) 즉, 코드 재사용은 생각할 수가 없다는 것이다. 게다가 코드 관리를 하기도 정말이지 힘들 것이다.(오리마다 나는 방식이 모두 다르다면, 모든 오리 클래스에 fly()가 다 다를테니 당연히 관리가 힘들다.)
정말이지 문제점이 많은 것 같다.
그래서 필요한 것이 디자인패턴이 아닌가 싶다.
다음 포스팅에서 이런 문제들을 해결할 Strategy Pattern 에 대해 포스팅 해보겠다.
소스들
invalid-file
