Java 디자인 패턴 정리

객체지향 디자인을 위해서는 재사용성, 확장성. 관리 용이성 등을 갖춰야 한다고 얘기를 하고 있다. 이런 것들을 갖추기 위해서 Java에서는 유명한 여러가지 디자인 패턴이 있는데 이를 한번 정리해본다.

 

1. Iterator 패턴

       - 반복작업에 대한 캡슐화 : Iterator를 사용하면 클라이언트에서는 처리할 컬렉션 객체가 List인지 Array인지 신경쓰지 않아도됨.

       - Enumeration과의 차이점은 Iterator은 remove() 를 지원.

 

2. Adapter 패턴

      - 캐스팅 등이 불가능한 경우 클래스의 인터페이스를 클라이언트가 원하는 인터페이스로 변환하는 역할(Adapter)

      - 인터페이스 간의 호환성 문제를 해결할 수 있음.

 

   

3. Factory Method 패턴

      - 객체 생성을 다른 클래스(주로, 상위클래스)가 해줌.

      - Abstract Class, 인터페이스에 대해서 다양한 하위구현체들이 존재할때 사용하면 객체 생성을 간편화, 효율적으로 관리 가능.

      - 주로 어떤 값에 따라서 생성되는 하위객체가 다를 경우 사용.

 

 

4. Template Method 패턴

      - 전체적인 로직에는 큰 차이가 없이 일부분만 바뀌는 몇가지 클래스가 있을 경우 전체를 새로 작성할 필요가 없음

      - 전반적인 구현은 상위클래스에서 담당하고, 부분적으로 차이나는 부분은 하위클래스가 담당.

      - 상위클래스의 변화가 하위클래스들 전체에 영향을 미칠수 있음. 

 

 

5. Singleton 패턴

      - 객체를 하나만 만들어서 사용 : 불필요한 객체 생성을 막음

      - 변경이 필요한 부분은 멤버변수가 아니라 메소드의 파라메타 등으로 처리

 

6. Strategy 패턴

      - 변경되는 부분을 인터페이스로 처리하여 클라이언트에 독립적으로 구현체를 변경할 수 있도록 함.

 

 

7. Composite 패턴

      - 파일 데이터와 같은 일반적인 트리 구조의 데이터 타입을 만드는 것

      - 클라이언트에서 개별객체와 복합객체(다른객체들로 구성된)를 똑같은 방법으로 다룰 수 있음

 

 

8. Decorator 패턴

      - 기존에 구현된 기능(타켓)에 부가기능을 추가하기 위한 패턴

 

 

9. Proxy 패턴

      - 기존 구현된 기능(타켓)에 부가기능을 추가 및 삭제 하지 않음. 

      - 클라이언트가 타겟에 접근하는 방식을 변경 함 

      - 원격객체, 생성하기 힘든객체, 아직 생성이 안된 객체, 보안이 중요한 객체에 대한 접근을 제어하는 대변자 객체를 만들수 있음.

      ==> 기능자체에는 관여하지 않고 접근방법을 제어 함

 

 

10. Chain of Responsibility 패턴

      - 문제 해결사들이 한줄로 서있다가 문제가 들어오면, 자기가 해결할수 있으면 해결, 안되면 다음 해결사에게 전달

 

 

 

11. Facade 패턴

      - 복잡한 서브 시스템에 통일된 인터페이스를 제공 -> 복잡한 API 단순화 시켜줌

      - Ex>여러개의 작은 단위의 인터페이스들을 고차원의 하나의 인터페이스로 제공

              

 

12. Observer 패턴

      - 어떤 클래스(Observable 상속)에 변화가 생겼을 때 다른 클래스(Observer 구현)에 통보해주는 패턴

      - 어떤 클래스.addObserver(다른클래스); 로 Observer 등록.

      - 어떤 클래스 setChange(); // 변화가 일어났음을 알림, notifyObservers(Object); // 어떤변화가 일어났는지에 대한 상세정보 전달

      - 변화를 감지하면 Observer 클래스의 update(Observalbe, Object) 메소드가 호출 됨

  

 

13. Prototype 패턴

      - 일반적인 원형을 만들어서 그것을 복사한 후(Clone) 필요한 값만 다시 설정해주는 패턴.

      - 객체 생성이 복잡한 경우 new로 매번 같은 복잡한 과정을 거칠 필요가 없음

      - 일반적으로 Factory Method 패턴과 같이 사용(원형 생성에 관한 내용을 밖으로 노출하지 않음)

 

 

14. Flyweight 패턴

      - 동일한 객체를 공유해서 객체 생성을 줄여줌

      - 일반적으로 Flyweight는 Map으로 관리(Map에 있으면 객체 공유, 없으면 새로 생성 후 Map에 넣고 관리)

 

 

15. Builder 패턴

      - 객체 생성에 있어서 복잡한 과장을 분리 해내는 패턴.

      - 객체 생성할 때 많은 값들을 셋팅 해줘야 할때 이를 포괄하는 한두개의 메소드 호출로 객체생성 복잡도를 줄임

 

 

16. Mediator 패턴

      - 관제탑과 같이 통신을 집중 시킴으로써 통신의 경로를 줄이고 단순화 하는 패턴.

      - 각 객체 간의 통신이 아니라 ControlTower같은 중계 객체를 두고, 각 객체들은 ControlTower 랑만 통신함.

      - 통신하는 객체 수가 많을 수록 중계 객체를 두는것이 유리함.

 

 

17. Visitor 패턴

       - 어떤 구조체(자료구조)에 대해 그 안을 돌아다니면 어떤 일을 처리하는 패턴

       - 하나의 구조체에 대해 다양한 일을 할수 있는데 일(기능)이 추가된다고 해서 구조체가 변경되는 것은 무리 -> Visitor 패턴 사용

       - 어떤 디렉토리 구조를 탐색해서 어떤일을 한다고 할 경우 재귀를 사용하지 않고 Visitor로 처리 가능

       - 각각 Visitor, Acceptor 인터페이스 구현