달력

12

« 2018/12 »

  •  
  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
  •  
  •  

'디자인 패턴'에 해당되는 글 7

  1. 2017.04.12 Factory Mathod Pattern
  2. 2016.05.04 Iterator Pattern
  3. 2016.05.02 UML의 기본 구성-시퀀스 다이어그램 (4)
  4. 2016.05.02 UML의 기본 구성-클래스 다이어그램
  5. 2010.04.04 데코레이터(Decorator) 패턴 (1)
  6. 2010.04.03 스트레티지(strategy) 패턴
  7. 2010.03.24 static
2017.04.12 14:22

Factory Mathod Pattern 프로그래밍/디자인패턴2017.04.12 14:22




Factory Method Pattern 에 대해서 알아보도록 하겠습니다.


개인적으로 이 패턴에 대해서 이해를 하는 과정이 있어서, 가장 좋은 방법은

사용, 결과를 확인 하였을 때 가장 이해가 빠르지 않나 싶습니다.


결과를 보면 텍스트 뿐이지만, 실제로 생성되는 클래스는 각각 다른 클래스 입니다.


다음은 UnitFactory Class 를 확인해 봅시다.


Factory 라는 가상 클래스에서 상속받아, 생성 타입에 따라 Fly, Walk 등을 만들어 낸다고 보시면됩니다.

사실 상황에 따라 다르게 쓰일 수 있는데, 

이번 예제 같은 경우엔 UnitFactory 하나를 만들어 2가지 유닛을 생성하는 용도로 사용하였지만,

- FlayUnitFactory

- WlakUnitFactory 

이렇게 2개로 나누어 작성할 수도 있을 것 같습니다.


그럼 마지막으로 Factory Class를 살펴 보겠습니다.


쉽게 말해, 무언가를 찍어내고 싶을때 많이 사용하는 패턴입니다. 만들고 관리하는 과정에 있어서 편리함을 주기 위함이라고 보시면 될 것 같습니다. 


어떤것을 만들던지 쉽게 만들 수 있고( 정해진 패턴내에서 )

이미 만든것들을 관리하기 편하게 한다던가,

원한다면 제거 하는 과정에서도 쉽게 컨트롤 할 수 있습니다. 


테스트를 위한 전체 코드를 첨부하고 마치도록하겠습니다.



'프로그래밍 > 디자인패턴' 카테고리의 다른 글

Factory Mathod Pattern  (0) 2017.04.12
Template Method Pattern  (0) 2016.06.30
Adapter Pattern  (2) 2016.06.07
Iterator Pattern  (0) 2016.05.04
UML의 기본 구성-시퀀스 다이어그램  (4) 2016.05.02
UML의 기본 구성-클래스 다이어그램  (0) 2016.05.02
Posted by 안식의후크
2016.05.04 16:55

Iterator Pattern 프로그래밍/디자인패턴2016.05.04 16:55





이번에는 Iterator 패턴에 대해 알아보고, 

해당 부분을 적용한 Unity 예제와, 조금의 응용을 같이 진행에 보도록 하겠습니다. 


흔히 Iterator라 함은, 구지 디자인 패턴의 종류라기보단 컨테니어들을 따라갈때 많이 쓰던 키워드 중 하나? 정도로 많이 파악이 되어 있습니다. 실제로 그것과 크게 다르지도 않습니다.


중요한 것은, 특정 List나 Arr등 그룹지어져 있는 Object들을 순차적( 구현에 따라선 특정 구간이 될 수도... )으로 순회하면서 찾는다는 것이 중요합니다. 단지 이것을 디자인 패턴으로 표현 하였을 때 어떤식의 장점이 있는지, 그리고 어떤식으로 구현해야 하는지 확인해 본다고 보시면 될 것 같습니다.


먼저 최종 사용 코드부터 보도록 하겠습니다. 


사용 코드 예제



(*사용 구현에 대해서는 주관적인 부분입니다.)


코드를 보면 BookShelf에 Book이라는 Class를 넣어 주고, BookShelfIterator를 사용하여 순회 합니다.

그럼 다음으로 실제로 저장 될( 서가에 들어갈 ) Book Class를 보도록 하겠습니다.


아직 Iterator Pattern에서 어떤 처리를 하는지는 설명하지 않았으나,

원하는 결과는 다음과 같을 것입니다.


GameObecjt를 2개 추가하여, 각각 Script를 지정합니다.


Iterator Pattern 을 넣고


국어책도 한권 넣어서 실행하면,

국어책을 책장에 넣고, 책장을 순회하여 어떤 책이 있는지 확인해 볼 수 있습니다.


책의 갯수를 조금 더 늘려 보도록 하겠습니다. 




3권을 더 추가하였습니다.


각각의 책을 서가에 넣고,


서가을 순회하면서 모든 책들을 찾아 보았습니다.


그럼 이제 실제 패턴에 구현 부분을 확인해 보도록 하겠습니다. 



코드를 보면 BookShelf(서가)클래스 안에 Book(책)을 담을 수 있어야 하고.

서가에 iterator를 통해 서가을 검색, 순차적으로 접근 할 수 있어야 합니다.

그런 실제 iterator를 구현한 클래스가 BookShelfIiterator class 입니다.


여기 까지가 iterator pattern의 기본 예제였습니다.



여기서 조금 응용을 해보겠습니다.


* 만약 기존의 책이 아닌 사진을 저장해 놓은 앨범이라는 새로운 서적이 추가되었다. 그렇다면 여기서 어떻게 진행해야 할까?


첫번째로 앨범 전용 서가를 하나 추가할 수도 있을 것이고,

Book Class 처럼 Album이라는 class를 새로 만들 수도 있을 것입니다. 

Iterator도 Album 전용 Iterator가 생성 될 수도 있고, 기존의 Iterator를 활용하여 진행 할 수도 있을 것입니다. 


저는 해당 문제를 기존의 Iterator Pattern을 그대로 두면서 Book Class를 활용하는 방법으로 진행하도록 하겠습니다. 


다른 부분은 다 그대로 두고 Album 이라는 class를 추가 해 보도록 하겠습니다. 


Book Class를 상속받아서 편하게 추가해 보았습니다. 

하지만 꼭 이 방법만이 있는것은 아니겠죠.

 


이런식으로 접근해서 해결 하였지만,



이런 방법도 있을 수 있을 것 같습니다.

(하지만 이렇게 하면 BookShelf 에서 더 코드변경이 일어날지도 모르겠네요)



조금 복잡 할 수도 있으나 Iterator Pattern을 쓰는 이유는 아마 이런 이유가 아닐까 싶습니다.


새로운 무언가( Obecjt, Class ... ) 가 추가 되었을 때 기존의 검색 체계에서 벗어나지 않게 쉽게 추가 할 수 있기 위해서라고 생각합니다. 


즉, 구현에 상관 없이 Iterator를 사용할 수 있기 때문.


Alnum을 추가 하고 실행하면 다음과 같이 표현됩니다.




이상으로 Iterator Pattern에 대한 설명을 마칩니다. 많이 부족하지만, 점점 나아질 것이라 생각합니다.

'프로그래밍 > 디자인패턴' 카테고리의 다른 글

Template Method Pattern  (0) 2016.06.30
Adapter Pattern  (2) 2016.06.07
Iterator Pattern  (0) 2016.05.04
UML의 기본 구성-시퀀스 다이어그램  (4) 2016.05.02
UML의 기본 구성-클래스 다이어그램  (0) 2016.05.02
다시 시작하는 디자인패턴  (0) 2016.04.29
Posted by 안식의후크



클래스 다이어그램에 비하면 조금 더 가독성이 높은 편,


실제 내부적으로 어떻게 구성 되어 있는지 표현하는게 클래스 다이어그램이라면


시퀀스 다이어그램은, 구성된 내용들이 어떻게 동작하는지 보여 준다고 보면됩니다.



표현을 빌리면,


시간에 의해 변하지 않는 것(정적인 관계) = 클래스 다이어그램

시간에 따라 변하는 것(동적인 관계) = 시퀀스 다이어그램


이라고 보시면됩니다.


실제 예제를 보면 다음과 같습니다.





1 ~ 2. 손님이 입장 후 서빙 직원에게 요리를 주문합니다.


3 ~ 4. 직원은 해당 내용을 종이에 작성 한 후 그 리스트를 요리사에게 전달 합니다.


5 ~ 6. 요리사는 해당 요리를 제작 완료된 요리를 직원에게 다시 전달합니다.


7. 직원은 해당 요리를 손님에게 전달합니다.


8. 식사 진행


9 ~ 10. 직원에게 계산 후 퇴장


2 ~ 9 까지는 손님 수만큼 계속 반복됩니다.



시퀀스의 경우 기본적인 설명은 여기까지만 하고, 그 이후에 사용되는 표현에 대해서는 그때 그때 명시하도록 하겠습니다.


다음은 Iterator 패턴에 대해 알아 보도록 하겠습니다.

'프로그래밍 > 디자인패턴' 카테고리의 다른 글

Adapter Pattern  (2) 2016.06.07
Iterator Pattern  (0) 2016.05.04
UML의 기본 구성-시퀀스 다이어그램  (4) 2016.05.02
UML의 기본 구성-클래스 다이어그램  (0) 2016.05.02
다시 시작하는 디자인패턴  (0) 2016.04.29
데코레이터(Decorator) 패턴  (1) 2010.04.04
Posted by 안식의후크



디자인 패턴에 들어 가기에 앞서 UML을 알아둬야 할 필요성이 있습니다.


Unified Modeling Language의 약자로 설계문서를 시각화 한다고 정의 되어 있습니다.

지금 설명하는 것들은 모두 클래스 다이어그램입니다.


가장 기본적인 상속 구조를 알아 보도록 하겠습니다.



해당 그림은 다음과 같습니다.

- 부모 클래스가 가상 클래스(이탤릭)로써, 자식 클래스가 상속을 받은 형태

- 부모클래스에는 변수, 스태틱 변수( 밑줄 )가 존재

- 부모 클래스는 가상함수(이텔릭)와 함수가 존재

- 자식 클래스는 변수X, 부모로써 상속받은 가상함수와 스태틱함수(밑줄) 존재

- 각 변수나 함수 앞에 기호는 public은 +, protected는 #, private는 -로 표기



다음은 인터페이스 설명입니다.


- 가상 클래스와 비슷하지만 직선 대신 점선 사용.

- 변수, 함수 그대로 사용.

- << interface >> 와 같이 인터페이스 표기


집약(포함) 표기



- 인스턴스의 갯수와 상관없이 표기

- 0..*은 최소 0개부터 무제한

- 바구니에는 x개의 과일이 존재하고 과일은 모두 색상을 가지고 있다.

- 집약 관계에는 깊은, 얕은 관계가 존재 깊은 관계에는 마름모안에 공간을 채운다.

- 집약의 대상이 사라졌을( 삭제 되었을 때 ) 남아 있을 수 있다면, 얕은 집약관계, 함께 사라진다면( 삭제 된다면 ) 깊은 집약 관계라고 볼 수 있다.


클래스의 관계 표기



책에서 보는것과, StarUML을 사용해서 표기 하는것과는 조금 다른 부분이 존재 하는데 일단 중요한거 같지 않으니 무시하고 넘어 가겠습니다.


다음 장에서는, 시퀀스 다이어그램을 간단하게 살펴보도록 하겠습니다.

Posted by 안식의후크





특정 객체의 기능을 동적으로 추가하거나, 삭제 할 때 편리하게 사용 할 수 있는 패턴이다.

유용한 상황 :
 다른 객체에 영향을 주지 않으면서 새로운 기능을 추가 하고자 할 때, 특시 Client 측에서는 이렇게 새로운 기능이 추가된 객체와 그렇지 않은 객체를 따로 구분하고 싶지 않을 때
 
 특정 객체에 동적으로 추가된 기능을 삭제하고 싶을 때. 단, 이 경우 추가된 기능에 해당하는 객체가 아닌 원래 객체가 가진 기능은 삭제할 수 없다.
 
 클래스 상속을 통한 기능 확장이 불가능하거나 어려울 때, 예를 들어 서로 독립된 상속 관계가 많아 이들을 조합하면, 너무 많은 하위 클래스가 만들어질 우려가 있는 경우 또는 클래스 정의가 숨겨져 있어 상속이 불가능할 때.

예제는 기본 베이스 커피에 토핑을 추가 한다고 하였을 때 사용하는 데코레이터 패턴의 예제 이다.

소스에 대한 설명은 생략 하겠다.

실행 결과
Posted by 안식의후크





기본적인 구조는 최상위 클래스를 상속받아 그 클래스들에 기능을 추가한다. 라고 보는게 맞을듯.

어떤 상황에 좋은가?

 서로 행위만 다를 뿐 밀접한 연관 관계를 가지는 여러 클래스들에 대해 필요한 시점에 어느 한 행위를 수행하는 클래스를 골라 사용하고자 할 때 유용하다.

 저장 공간 사용 효율이나 실행 시간 효율 등의 측면에서 다양한 형태의 알고리즘(기능)이 존재해서 상황에 따라 최적의 알고리즘(기능)을 선택해서 사용하도록 할 때 유용하다.

 어떤 알고리즘(기능)이 Client가 알아서는 안될 데이터를 사용하거나 알고리즘(기능)에 종속된 복잡한 자료구조(속성)를  사용할 때 유용하다. 이 경우 Strategy 패턴은 Client에게 알고리즘(기능)이 사용하는 데이터나 자료구조(속성)를 숨겨주는 역활을 한다.

 어떤 클래스가 많은 행위를 가지고 있고 이것이 여러 개의 조건문 형태로 쭉 나열되는 형태일 때 많은 조건문 대신 Strategy 패턴을 사용하면 유용하다. 이때 각 조건에 따라 수행할 때용들은 Strategey의 하위 클래스로 정의 될 것이다.

예제의 기능은, 최상위 오리 클래스를 상속 받아,
다양한 오리들을 생성하고, 사용한다.



Duck.h
Duck.Cpp
FlyBehavior.h
FlyBehavior.cpp

QuackBehavior.h
QuackBehavior.h

main.cpp
Posted by 안식의후크
2010.03.24 15:14

static 프로그래밍/C++2010.03.24 15:14







static, 지역변수로 선언되어 있는 변수를 전역 변수처럼 사용한다.

C++, 클래스에서 사용하는 static은 크게 2가지 특징을 가지고 있는데

첫번째로 public안에 선언된 멤버 변수에 static을 붙히면 전역 변수처럼 사용이 가능하다.
(main 함수가 호출 되기 이전에 메모리 공간에서 초기화가 되기 때문이다.)




두번째로 static 멤버 변수는 멤버에 존재 하는 것이 아니다.
단지 여러 클래스에서 접근 할 수 있는 권한만이 부여된 것이다.


그렇다고 만약 BBB라는 클래스가 있다고 하였을때,
AAA의 static a를 접근하여 수정할 수 있는것은 아니다.
static a 는 엄연히 AAA클래스의 private 선언 이기 때문이다.
보통 이는 나중에 디자인 패턴에서 나오는 싱글턴 패턴에서 많이 쓰이게 되는데.
개념은 간단하다.

결과 화면

단 1개의 객체만으로 값을 접근 하는 것을 확인 할 수 있다.

최종 정리

'프로그래밍 > C++' 카테고리의 다른 글

public: private: 그리고 protected:  (0) 2010.03.24
explicit, mutable  (0) 2010.03.24
static  (0) 2010.03.24
멤버 이니셜 라이저(member initializer)  (0) 2010.03.23
복사 생성자, 디폴트 생성자 그리고 디폴트 복사 생성자.  (0) 2010.03.21
friend  (0) 2010.03.21
Posted by 안식의후크