GOF의 디자인 패턴을 분석하기 전에, GOF의 디자인 패턴에서 사용하는 클래스 다이어그램도를 보려면 UML을 알아야 한다! 클래스 구조와 클래스간에 관계에 대해서만 알아도 GOF의 디자인 패턴을 이해하는데에는 무리가 없다.
1. Class (클래스 정의)
- 클래스에 대한 데이터(멤버변수)와 행동양식(멤버 메서드)를 정의한다.
- 3부분으로 나눠어지며 각각 클래스명, 데이터, 행동양식을 정의한다.
🧐 상 단 : 클래스명
🧐 중 단 : 데이터(멤버변수)
- 데이터 타입
-(private) : 외부에 노출이 되지 않는 한정자
+(public) : 외부에 노출이 되는 한정자
#(protected) : 클래스나 상속된 클래스에서 접근가능한 한정자
🧐 하 단 : 행동양식(메서드)
2. Class Relationship (클래스간 관계)
- 클래스간의 관계는 총 4가지로 분류할 수 있다!
🤓 Generalization(일반화 관계) : 일반적인 것(동물)에서 특화된 것(강아지, 고양이)과의 관계를 나타낸다. 보통 상속을 표현!
🤓 Realization(실체화 관계) : 인터페이스와 그것을 구현한 것과의 관계를 나타낸다.
🤓 Association(연관 관계) : 한 객체가 다른객체를 소유하거나 파라미터로 객체를 받아서 처리하는 관계!
🤓 Dependency(의존 관계) : 한 객체가 다른객체를 소유하지는 않지만, 다른객체의 변경에 따라서 같이 변경을 해주어야 한다.
🍎 Generalization (일반화 관계)
- 상속을 표현한다. (A는 B다)
- 특수한 것에서 일반화를 표현한다. (특수화된 것에서 일반적인 내용들을 이끌어 내서 상위 클래스<일반화>가 된다.)
위 사진을 보면, Marine, Medic클래스는 Unit이라는 상위 클래스로부터 'Name, Health'멤버변수와 'Move(), UnderAttack(ref Character)' 메소드를 상속받아서 사용할 수 있다. 특히 메소드 부분은 캐릭터 특성에 따라서 추상 메서드를 그대로 쓰거나 오버라이드해서 사용 가능하다!
🍊 Realization (실체화 관계)
- 인터페이스를 구현하는 관계를 표현한다! (A는 B처럼 행동한다)
- 상속의 개념과 비슷하지만 상속과 다른점은,
- 상속 : 직접 상위 클래스를 상속받아서 Unit.cs 기능을 포함한다. (멤버변수, 메서드)
- 인터페이스 : 서로 다른 클래스라도 인터페이스만 준수하면(모두 구현하면) 동일한 기능들이 구현될 수가 있다. 즉, 완전히 다른 클래스에 공통적인 기능(메서드)를 부여해주는 것!
위 사진을 보면, Barracks.cs, Factory.cs, Bunker.cs는 Building.cs를 상속받는다. 테란 건물들은 보통 띄우고 착지하는 기능이 있는데 Bunker는 불가능하다. 때문에 상속을 받는 클래스에서 위 기능이 구현되어 있다면 Bunker에서는 사용하지 못하는데 매우 비효율적이다. 하지만 인터페이스를 구현해서 이동이 가능한 건물에만 상속받게 한다면 위 문제는 해결된다! 인터페이스를 구현하는 곳에서는 Move,Land,Fly 메서드를 반드시 구현해야 합니다.
🍋 Association (연관 관계)
- 한 객체가 다른객체를 소유(사용)하거나, 참조하여 사용할 때
- 단방향과 양방향이 존재한다!
- 단방향 : 클래스간의 관계가 "->" 이렇게 구현이 되며, 화살표의 대상은 자신을 가리키는 클래스의 존재여부를 알지 못한다.
- 양방향 : 클래스간의 관계가 "-"로 구현되며 서로 연관이 되어있다.
- 연관관계는 대상이 되는 객체의 Life Cycle에 따라서 두 가지로 분류된다!
- Aggregation (집합) :
- 메인 클래스가 삭제될시 대상 클래스는 같이 삭제가 안됨. (라이프 사이클이 다름)
- 분리가 되도 독립적으로 동작됨
- 약한 결합
- Cmposition(합성) :
- 메인 클래스가 삭제될시 대상 클래스도 같이 삭제가 됨. ( 라이프 사이클이 동일)
- 분리가 되면 의미가 없어짐.
- 강한결합
- ex) Association
마린은 총이라는 클래스를 멤버 변수로 가지고 있다. 5.56mm Gun.cs는 marine.cs가 있다는 사실도 모른다.
- ex) Aggregation (집합)
팩토리는 애드온이라는 것을 건설해서, 기존의 팩토리에서는 생산하지 못하는 시즈탱크를 생산할 수가 있다. 애드온은 팩토리가 위치를 이동하여도 파괴되지 않고, 다른 팩토리가 연결이 되면 또 동작을 정상적으로 하게 된다.
다른예로, 컴퓨터에는 모니터와 마우스와 키보드가 있는데 이것들도 같은 의미로 해석이 됩니다.
- ex) Composition (합성)
실제 스타크래프트에서는 캐리어가 생성이 되고난 이후 인터셉터라는 유닛을 다시 생성하지만, 여기서는 전제조건을 캐리어가 생성이 되는 동시에 인터셉터가 생성이 된다고 생각하겠다! 캐리어가 죽으면 안에 있던 인터셉터도 같이 죽게되니 라이프 사이클을 공유하게 된다. 이것이 바로 콤포지션 모델이다.
🍉 Dependency (의존관계)
의존관계는 한 객체가 다른객체를 소유하지는 않지만, 다른객체의 변경에 따라서 같이 변경을 해주어야 할때 사용합니다.
일반적으로 아래의 상황일때 사용하게 됩니다.
- 다른 객체를 파라미터로 받아서 그 메서드를 사용한다.
- 객체의 메서드 안에서 다른 객체를 생성해서 리턴한다.
배럭스에서는 마린이나 메딕등을 생산을 할 수가 있다. 배럭스는 마린이나 메딕을 사용하지 않고 단순히 MakeMarine이라는 메서드를 통해서 마린을 new로 생성해서 리턴할 뿐이다. 위에서 마린의 클래스에서 생성자에 변경이 생기면 배럭스에서도 생성하는 구문을 수정이 되어야 합니다.