학습목표

  • 커맨드 패턴을 통해 얻을 수 있는 이점에 대하여 생각해보자

커맨드 패턴 = 요청을 객체의 형태로 캡슐화하여 사용한다 정도랄까?


예를 들어 게시판을 만들 때 요청을 생각해보자. 요청은 여러 개로 나뉠 수 있다. 삭제 요청, 삽입 요청, 수정 요청 등 등 ..


이를 아래와 같이 각 요청에 따라 다르게 수행할 수 있는 객체로 만들 수 있다. 




다양한 요청들을 처리할 때는 요청을 받은 쪽은 Command의 어떠한 내부 흐름이 있는지 몰라도 되고, execute()만 실행해주면 된다.




이를 큐에 응용한다면 큐는 어떤 요청이 오더라도 execute()만 호출하면 될 것이다


[소스 : https://github.com/kimjongmo/DesignPattern/tree/master/021CommandPattern]

학습목표

  • 프록시를 왜 사용하는지 이해해본다.

proxy pattern = "대신 처리 해준다"


스프링의 AOP 개념을 듣다 보면 프록시라는 개념이 나옵니다. 핵심 기능과 공통 기능을 나누고 공통 기능과 다른 기능들을 설정해두고 프록시가 처리하도록 하는 패턴인 것 같습니다.


동영상에 "대리"라는 단어로 비유 하듯이 간단한 업무는 프록시(대리)에게 맡기는 것을 의미합니다.



구조도는 다음과 같습니다


[출처 : https://www.youtube.com/watch?v=Nc-3QUJicvo]

[소스 : https://github.com/kimjongmo/DesignPattern/tree/master/020ProxyPattern]



학습목표

  • 프로토 타입 패턴을 통해서 복잡한 인스턴스를 복사 할 수 있다. 
  • 다수의 객체 생성시에 발생되는 객체의 생성 비용을 효과적으로 줄인다


프로토타입 패턴의 장점

1. 객체를 생성해 주기 위한 별도의 객체 생성 클래스가 불필요하다

2. 객체의 각 부분을 조합해서 생성되는 형태에도 적용 가능하다. 


프로토타입 패턴의 단점

1. 생성될 객체들의 자료형인 클래스들이 clone()메서드를 구현해야 한다.









[소스 : https://github.com/kimjongmo/DesignPattern/tree/master/006ProtoType]

[참고 : http://leetaehoon.tistory.com/55  https://www.youtube.com/watch?v=oWsS67joKJA&t=401s]

학습목표

  • 하나의 인스턴스만 생성하고 이용할 수 있도록 하는 것

구조도는 다음과 같습니다.



대표적인 싱글톤 예제는 DBCP가 있습니다. 



객체 생성을 줄임으로서 Heap 영역의 메모리가 줄었고, 하나의 인스턴스만 공유할 수 있게 되었다. 




개인적으로 조금 주의를 가해야 한다는 생각은 자원을 공유한다는 것이기 때문에 멀티 스레드 같은 환경에서는 동기화를 시켜서 사용해야 할 것 같습니다. (그냥 Synchronized보다는 좀 더 효율적으로 만들순 없을까나... 훔...)


또 싱글톤의 경우 종료시까지 Heap 영역에 남는다는 점도 있습니다(가비지 컬렉터가 지우지 못한다) 



[소스 : https://github.com/kimjongmo/DesignPattern/tree/master/05Singleton]

[참조 : https://www.youtube.com/watch?v=5jgpu9-ywtY&t=136s]



학습목표
  • 팩토리 메소드 패턴에서 템플릿 메소드 패턴의 사용됨을 안다.
  • 팩토리 메소드 패턴에서의 구조와 구현의 분리를 이해하고 구조와 구현의 분리의 장점을 안다.


빨간 구역은 framework 패키지

파란 구역은 concrete 패키지입니다.


설명에서도 템플릿 메소드가 나오듯이 두 가지 패턴이 굉장히 헷갈리는 패턴입니다. 


강의 외에 두 가지가 차이가 잘 이해가 가지 않아서 좀 더 찾아본 결과 제 결론은 이렇습니다


템플릿 메소드 : 슈퍼클래스에서 로직의 흐름을 정하고, 서브클래스는 상속받은 로직의 흐름을 유지하고 , 기능을 구체화 시킵니다.

    Ex)

    로직의 흐름 : (A에서 B로 갈꺼다)

    기능 정의    : C와 D를 거쳐 A에서 B로 간다,  C와 E를 거쳐 A에서 B로 간다.


팩토리 메소드 : 서브클래스에서 오브젝트 생성 방법을 결정하는 것. 템플릿 메소드는 흐름이지만 팩토리 메소드는 오브젝트를 생성하는 것

                     Ex)
                     아이템을 만드는 과정 : (  a-b-c  ) ->  Item만듬         * 이 과정에서 (a-b-c)로직은 템플릿   item을 만든 다는 것은 펙토리

                      서브클래스 : (a - b - c) ->Item1을 만듬,  (d - e - f) -> item2


[소스 : https://github.com/kimjongmo/DesignPattern/tree/master/04FactoryMethod]

[출처:https://www.youtube.com/watch?v=-gyoG-7MHLI&list=PLsoscMhnRc7pPsRHmgN4M8tqUdWZzkpxY&index=4]




학습 목표

  • 일정한 프로세스를 가진 요구사항을 템플릿 메소드 패턴을 이용하여 구현

탬플릿 메소드 패턴 : 알고리즘의 구조를 메소드에 정의하고 하위 클래스에서 알고리즘 구조의 변경없이 알고리즘을 재정의 하는 패턴.
                            -> 변하지 않는 기능은 슈퍼클래스에서 만들어주고 자주 변경되어 확장할 기능은 서브클래스에서 만든다.

 


언제 쓰일까?

 - 구현하려는 알고리즘이 일정한 프로세스가 있다.

 - 구현하려는 알고리즘이 변경 가능성이 있다. 


어떤 단계로 써야 할까?

 - 알고리즘을 여러 단계로 나눈다.

  ex) 게임에 접속 시 아이디 비밀번호 로그인 과정, 해당 회원의 등급(회원, 관리자) 확인 과정, 연결 과정


 - 나눠진 알고리즘의 단계를 메소드로 선언한다.

  ex) 위의 로그인 과정, 등급 확인 과정, 연결 과정 들을 각 각 메소드로 정의.


 - 알고리즘을 수행할 템플릿 메소드를 만든다.

  ex) 하나의 메소드 안에 이 과정들을 담는다.


 - 하위 클래스에서 나눠진 메소드들을 구현한다.

  ex) 나눠진 알고리즘의 단계를 하위 클래스들이 구현한다.




AbstGameConnectHelper클래스의 requestConnection 메소드는 abstract로 선언한 메소드들을 담고 있는 템플릿 메소드입니다.

DefaultGameConnectHelper클래스는 위의 클래스를 상속받은 클래스로 각 각의 나눠진 메소드들을 정의하는 클래스입니다. 


이렇게 구현이 되었다고 생각했을 때 , 보안 과정에 추가적인 문제를 선언해야 한다면 프로세스(requestConnection)를 변경할 필요없이 DefaultGameConnectHelper클래스의 doSecurity메소드만 재정의하면 된다는 것이다. 


템플릿 메소드의 정의를 다시 한번 보도록 하자


"알고리즘의 구조를 메소드에 정의하고 하위 클래스에서 알고리즘 구조의 변경없이 알고리즘을 재정의 하는 패턴"



[출처 : https://www.youtube.com/watch?v=qr7I18Lhsl8]

학습 목표

  • 알고리즘을 요구사항에 맞게 사용할 수 있다.

상황을 예시로 들자면  "A라는 알고리즘을 돌리게 되면 효율이 매우 떨어진다는 것을 알게 되었고, B라는 알고리즘으로 대체를 하는 상황"이 가장 적절하다고 생각한다.


클래스의 구성은 다음과 같이 되어있다. AdapterImpl.class에서는 sort()라는 메소드안에 Sort.class의 알고리즘을 장착하고, Main.class에서는 이 AdapterImpl.class의 sort 메소드를 사용한다.


1. 버블 소트를 사용하고 있을 때


2. 버블 --> 퀵



 다음 사진에서 볼 수 있듯이 Main.class에는 어떠한 변경도 일어나지 않았지만 전혀 다른 알고리즘으로 바꿀 수 있게 되었다.



[출처 : https://www.youtube.com/watch?v=gJDZ7pcvlAU]

학습 목표

  • 인터페이스 개념
  • 델리게이트 개념
  • 전략 패턴 이해


인터페이스 : 기능의 선언과 구현으로 분리시킨다.



델리게이트 : 특정 객체의 기능을 사용하기 위해 다른 객체를 호출하는 것.


전략 패턴 : 여러 알고리즘을 하나의 추상적인 접근점을 만들어 접근 점에서 서로 교환 가능하도록 하는 패턴.

(바뀌는 부분을 인터페이스로 분리하여 처리)


다음 클래스 다이어그램에 맞게 구현해보면서 이해해보자!!


[소스 : https://github.com/kimjongmo/DesignPattern/tree/master/00Strategy]

[출처 : https://www.youtube.com/watch?v=UEjsbd3IZvA]

+ Recent posts