본격적인 GOF의 디자인 패턴을 분석하기 전에, GOF의 디자인 패턴에서 사용하는 클래스 다이어그램도를 보려면UML을 알아야 합니다. 클래스 구조와 클래스간에 관계에 대해서만 알아도 GOF의 디자인 패턴을 이해하는데에는 무리가 없다고 봅니다.
1.Class(클래스 정의)
클래스에 대한 데이터(멤버변수)와 행동양식(멤버 메서드)을 정의한다.
3부분으로 나뉘어지며 각각 클래스명,데이터,행동양식을 정의한다.
- 상단: 클래스명
- 중단:데이터(멤버변수)
[ 데이터 타입]
-(Private): 외부에 노출이 되지 않는 한정자
+(Public): 외부에 노출이 되는 한정자
#(Protected): 클래스나 상속된 클래스에서 접근가능한 한정자
- 하단:행동양식(메서드)
2.Class Relationship(클래스간 관계)
클래스간의 관계는 총 4가지로 분류할 수가 있다.
①Generalization(일반화 관계) : 일반적인 것(동물)에서 특화된 것(사자)과의 관계를 나타낸다. 보통 상속을 표현한다.
②Realization(실체화 관계) : 인터페이스와 그것을 구현한 것과의 관계를 나타낸다.
③Association(연관 관계) : 한 객체가 다른객체를 소유하거나 파라미터로 객체를 받아서 처리하는 관계를 나타낸다.
④Dependency(의존관계) : 한 객체가 다른객체를 소유하지는 않지만, 다른객체의 변경에 따라서 같이 변경을 해주어야 한다.
①Generalization(일반화 관계)
상속을 표현한다. ( A는 B다. is a)
특수한 것에서 일반화를 표현한다. ( 특수화된 것에서 일반적인 내용들을 이끌어 내서 상위 클래스<일반화>가 된다. )
Unit이라는 상위 클래스에서 공통적으로 마린이나 메딕에서 사용하는 Name이나 Health 멤버변수를 추상적으로 선언하고 Move라는 메소드를 선언을 합니다. Unit클래스를 상속받는 마린이나 메딕에서는 각자의 특수한 스킬이나 액션에 따라서 다른 멤버변수나 메서드를 추가하여 구현을 하거나, 상속받은 추상 메서드를 오버라이드해서
구현하면 됩니다.
②Realization(실체화 관계)
인터페이스를 구현하는 관계를 표현한다. ( A는 B처럼 행동한다. behaves like )
상속의 개념과 비슷하지만 상속과 다른점은,
- 상속 : 직접 상위 클래스를 상속받아서 Unit 클래스의 기능을 포함한다.(멤버변수 및 메소드 모두 상속됨)
- 인터페이스 : 서로 다른 클래스라도 인터페이스만 준수하면(인터페이스의 함수들을 모두 구현하면) 동일한 기능들이 구현 될 수가 있다.(메소드 같은 기능들만 구현이 됨) 즉, 완전히 다른 클래스에 공통적인 기능(메서드..)을 부여하는 것이다.
Building이라는 것에서 Barraks,Factory,Bunker가 상속되어서 멤버 변수인 Health와 Ammor의 데이터와 Contruct(건물짓기), UnderAttack(공격받기) 기능이 부여가 됩니다. 여기에서 테란건물의 특수기능인 건물을 상공으로 띄워서
이동하고 다시 땅으로 착지하는 기능을추가하려고 했을때, Building의 상위 클래스에 메서드를 추가하게 되면 Bunker라는 건물은 이동이 원래 불가능한데 그 기능을 갖게 되서 문제가 발생합니다. ( 단순히 Overide해서 아무 기능이 없게 해도 되지만 상속받는 모든것에 그렇게 처리를 하는것도 효율적이지 못한거 같습니다. ) 이때 인터페이스를 구현해서 이동이 가능한 건물 에만 인터페이스를 구현하게 되면 됩니다. 인터페이스를 구현하는 곳에서는 Move,Land,Fly 메서드를 반드시 구현해야 합니다.
③Association(연관 관계)
한 객체가 다른객체를 소유(사용)하거나, 참조하여 사용할때
단방향과 양방향이 존재한다.
- 단방향: 클래스간의 관계가 "->" 이렇게 구현이 되며, 화살표의 대상은 자신을 가리키는 클래스의 존재여부를 알지 못한다.
- 양방향: 클래스간의 관계가 "-" 로 구현되며 서로 연관이 되어있다.
연관관계는 대상이 되는 객체의 Life Cycle에 다라서 두가지로 분류가 된다.
Aggregation (집합) :
메인 클래스가 삭제될시 대상 클래스는 같이 삭제가 안됨 (라이프 사이클이 다름)
분리가 되도 독립적으로 동작됨
약한 결합Composition(합성) :
메인 클래스가 삭제될시 대상 클래스도 같이 삭제가 됨( 라이프 사이클이 동일)
분리가 되면 의미가 없어짐
강한결합
[예-Association]
마린은 총이라는 클래스를 멤버 변수로 가지고 있습니다. 5.56mm Gun이라는 클래스는 marine이 있다는 사실도 모릅니다.
[예-Aggregation]
팩토리는 애드온이라는 것을 건설해서, 기존의 팩토리에서는 생산하지 못하는 시즈탱크를 생산할 수가 있습니다. 애드온은 팩토리가 위치를 이동하여도 파괴되지 않고, 다른 팩토리가 연결이 되면 또 동작을 정상적으로 하게 됩니다. 다른예로, 컴퓨터에는 모니터와 마우스와 키보드가 있는데 이것들도 같은 의미로 해석이 됩니다.
[예-Composition]
콤포지션은 스타크래프트에서 적용되는 유닛이 없어서 난감햇는데요(--;) 가장 유사한게 캐리어 입니다. 실제 스타크래프트에서는 캐리어가 생성이 되어서 인터셉터라는 유닛을 다시 생성하지만, 여기서는 전제조건을 캐리어가 생성이 되는 동시에 인터셉터가 생성이 된다고 생각하겠습니다. 캐리어가 죽으면 안에 있던 인터셉터도 같이 죽게되니 라이프 사이클을 공유하게 되죠. 이것이 바로 콤포지션 모델입니다.
④Dependency(의존관계)
의존관계는 한 객체가 다른객체를 소유하지는 않지만, 다른객체의 변경에 따라서 같이 변경을 해주어야 할때 사용합니다. 일반적으로 아래의 상황일때 사용하게 됩니다.
1.다른 객체를 파라미터로 받아서 그 메서드를 사용한다.
2.객체의 메서드 안에서 다른 객체를 생성해서 리턴한다.
배럭스에서는 마린이나 메딕등을 생산을 할 수가 있습니다. 배럭스는 마린이나 메딕을 사용하지 않고 단순히MakeMarine이라는 메서드를 통해서 마린을 new로 생성해서 리턴할 뿐입니다. 위에서 마린의 클래스에서 생성자에 변경이 생기면 배럭스에서도 생성하는 구문을 수정이 되어야 합니다.
이번 시간은 여기 까지 입니다.
공부하면서 여기저기 찾아서 하다보니 시간이 엄청나게 걸리네요.(ㅠ.ㅠ)
그래도 머릿속에 완벽히 기억이 되네요 ㅋㅋ 여러분도 파이팅!