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