GoF 구조적인 패턴 소개

 

나는 완벽한 것보단 완료를 더 추구한다.  그래서 무언가 내가 역할이 주어졌을 때 빠르게 프로토타입을 완성한다.

 

이 과정에서는 단위 테스트, 더 좋은 코드 구조 등.. 여러 가지 상황을 고려하지 않고 현재 가장 적합한 선택만으로 개발을 진행한다. 

 

하지만 소프트웨어란 결국 사용자의 요구기능이 지속적으로 추가되어야 하는 것이고 그렇지 않다면 죽은 소프트웨어라 볼 수 있다. 

 

그래서 우선 꼼꼼히 각종 테스트케이스를 만들려고 했다. 

 

이 과정에서 막히는 부분이 존재했다. 무거운 작업을 하는 코드가 구현체로 존재해 실제 테스트마다 무거운 작업을 해야 하는 것이었다.

 

결국 테스트를 위해 코드의 구조를 조금 손봐야 했다.

하지만 디자인 패턴은 아직은 아니라고 공부를 미뤄왔던 내게 별다른 선택지가 없는 것을 깨닫고 GoF의 디자인 패턴을 빠르게 볼 건데 여기선 디자인 패턴의 개념과 해당 디자인 패턴의 목적을 알아볼 것이다. 

 

그럼 내가 코드를 바라볼 때 더욱 적절한 디자인 패턴을 찾아 적용할 수 있을 것이라고 믿는다. 

 

 

어댑터 패턴

 

기존 코드를 클라이언트가 사용하는 인터페이스의 구현체로 바꿔주는 패턴으로 클라이언트가 사용하는 인터페이스를 따르지 않는 기존 코드를 재사용할 수 있게 해 준다.

 

클라이언트는 Target 인터페이스를 사용하도록 코드가 작성되어 있다.

우리는 Adaptee라는 코드를 Client가 사용하게 하고 싶지만 타입이 달라 사용할 수 없다. 

이때 두 가지 상황이 존재한다. 

 

Adaptee가 서드파티 라이브러리이고, Target interface를 건드릴 수 없을 때 이 경우

우리는 Adapter를 만들어야 한다. Target Interface를 implement 하여 서드파티 라이브러리를  해당 규약에 맞게 고쳐준 이후 사용할 수 있다.

 

내가 Adaptee에 접근이 가능한 경우. 이 경우는 별도의 Adapter를 생성하지 않고 Target 인터페이스에 맞춰서 수정해주면 된다.

 

정리하면 클라이언트는 Target 인터페이스를 의존하고 있는데, 기존 코드를 주입하고 싶다.

하지만 타입이 다르기 때문에 Target 규약에 맞춰주어야 한다.

이 과정에서 내가 코드를 수정할 수 없는 상황이라면 target을 구현한 Adapter 클래스를 만들고

재사용할 코드를 Target에 맞춰서 구현한 이후 클라이언트가 사용할 수 있게 한다. 

코드를 수정할 수 있다면 새로운 Adapter를 만드는 대신 기존 코드를 Target에 맞춰 간단히 처리할 수 있다. 

 

내가 바라본 어댑터 패턴은 기존 코드 구조를 변경하지 않고 어댑터를 활용해 상이한 인터페이스를 연결하여 확장을 유연하게 할 수 있는 것.

 

브리지 패턴

 - 추상적인 것과 구체적인 것을 분리하여 연결하는 패턴

  

추상적인 코드를 구체적인 코드 변경 없이도 독립적으로 확장할 수 있다.

추상적인 코드와 구체적인 코드를 분리할 수 있다.

 

 

음..  

 

추상적인 타입에 구체적인 타입이 있을 때  즉 둘 사이에 어떤 식으로도 결합이 되어 있을 때?

이 경우 abstraction과 implementation의 각각의 계층으로 분리하여 확장해야 할 때 사용되는 패턴으로 보인다. 

 

추상적인 것과 구체적인 것이 결합되어 사용되고 있다. (AB)

만약 새로운 B를 포함한 AB가 필요하다면  A+ new B를 합쳐서 만들어야 할 것이다.

 

그래서 A, B에 대해 코드 변경 없이 독립적인 계층을 갖게 하고 싶을 때 즉 분리하고 싶을 때 사용할 수 있는 패턴이 아닐까 싶다.

 

해당 방법은 B를 추상화시켜 A에 포함시키기만 하면 된다.  

 

이 단순한 방법으로 A는 B에 의존 없이 확장할 수 있고, 새로운 B가 추가되어 AB를 만들어 줄 때도 A의 코드 변경은 없다. 

 

 

컴포짓 패턴

 

그룹 전체와 개별 객체를 동일하게 처리할 수 있는 패턴

 

클라이언트는 그룹, 개별을 모두 동일한 컴포넌트로 인식할 수 있는 계층 구조

 

Component 인터페이스에서 사용될 오퍼레이션을 정의하는 것이 중요하다.

 

클라이언트가 사용하게 될 오퍼레이션을 Component에 정의를 하고 그룹화, 개별에서 Component를 구현을 해주어야 한다.

 

근데 Component들이 공통된 메서드를 전부 구현이 가능한가에 대해서 의문이 든다. 필요 없는 경우도 있을 텐데 이 경우에도 강제로 오퍼레이션을 작성해야하는 것아닌가?

 

JFrame을 좀 참조해서 이해해보자.

 

 

 

데코레이터 패턴

--

 

 

퍼사드 패턴

--

 

플라이웨이트 패턴

--

 

프록시 패턴

--