오브젝트 15_ 디자인 패턴과 프레임워크

디자인 패턴과 프레임워크에 대한 내용이다

자세한 내용이 궁금하면 오브젝트를 펼쳐보는 걸 추천드립니다.📖

오브젝트

---

시작하면서

디자인 패턴은 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법이다. 디자인 패턴의 목적은 설계를 재사용하는 것이다.

프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다.

한마디로 디자인 패턴과 프레임워크는 모두 협력을 일관성 있게 만들기 위한 것이다.

 

 

디자인 패턴과 설계 재사용

소프트웨어 패턴

패턴이란 무엇인가 논의되면 반복적으로 언급되는 특징이 있다.

- 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다

- 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사소통할 수 있다.

- 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕는다

- 패턴의 요점은 패턴이 실무에서 탄생했다는 점이다

 

패턴의 가장 큰 가치는 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다는 점이다. 즉, 패턴은 경험의 산물이다.

패턴의 범위는 소프트웨어 개발과 직접적인 연관성을 가진 분석, 설계, 구현 영역만 한정되는 것은 아니다. 모든 영역이 패턴의 대상이 될 수 있다.

패턴은 홀로 존재하지 않는다. 특정 패턴 내에 포함된 컴포넌트와 컴포넌트 간의 관계는 더 작은 패턴에 의해 서술될 수 있으며, 패턴들을 포함하는 더 큰 패턴 내에 통합될 수 있다. 연관된 패턴들의 집합이 모여 하나의 패턴 언어를 구성한다.

 

패턴의 분류

패턴의 범위나 적용 단계에 따라 아키텍처 패턴(Architecture Pattern), 분석 패턴(Analysis Pattern), 디자인 패턴(Design Pattern), 이디엄(Idiom)의 4가지로 분류된다. 가장 흔하게 알려진 것은 디자인 패턴이다.

 

패턴과 책임-주도 설계

패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다. 패턴은 반복적으로 발생하는 문제를 해결하기 위해 사용할 수 있는 공통적인 역할과 책임, 협력의 훌륭한 예제를 제공한다.

- Strategy 패턴 : 다양한 알고리즘을 동적으로 교체할 수 있는 역할과 책임의 집합을 제공한다.

- Bridge 패턴 : 추상화의 조합으로 인한 클래스의 폭발적인 증가 문제를 해결하기 위해 역할과 책임을 추상화와 구현의 두 개의 커다란 집합으로 분해함으로써 설계를 확장하게 만든다.

- Observer 패턴 : 유연한 통지 메커니즘을 구축하기 위해 객체 간의 결합도를 낮출 수 있는 역할과 책임의 집합을 제공한다.

 

패턴은 출발점이다

패턴은 출발점이지 목적지가 아니다. 패턴이 설계의 목표가 되어서는 안 된다. 패턴은 단지 목표로 하는 설계를 향해는 나침반에 불과하다. 상황에 맞게 패턴을 수정해야 한다. 

 

패턴을 사용하다가 문제점이 생기는 경우가 있는데 대부분 패턴을 맹목적을 사용할 때 발생한다. 이를 '패턴 만능주의'라 부른다.

각종 상황에 패턴을 사용하려고 남발하다보면 소프트웨어의 엔트로피가 증가하는 부작용이 생긴다.

 

정당한 이유 없이 사용된 모든 패턴은 설계를 복잡하게 만드는 장애물이다.

 

 

프레임워크와 코드 재사용

가장 이상적인 형태의 재사용 방법은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는 것이다. 설계를 재사용하면서도 유사한 코드를 반복적으로 구현하는 문제를 피할 수 있는 방법이 바로 프레임워크다.

프레임워크란 '추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계' 또는 '애플리케이션 개발자가 현재의 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션의 골격'을 의미한다.

전자가 프레임워크 구조적인 측면에 초점이라면 후자는 코드와 설계의 재사용 목적에 초점을 맞춘다.

 

비록 프레임워크가 즉시 업무에 투입할 수 있는 구체적인 서브클래스를 포함하고 있기는 하지만 프레임워크는 코드의 재사용보다는 설계의 재사용을 중요시한다.

 

상위 정책과 하위 정책으로 패키지 분리하기

프레임워크의 핵심은 추상 클래스나 인터페이스 같은 추상화다. 프레임워크의 재사용성은 일관성 있는 협력과 관련있다.

협력을 일관성 있고 유연하게 만들기 위해서는 추상화를 이용해 변경을 캡슐화해야 한다. 그리고 의존성은 추상화를 향하도록 작성해야 한다.

프레임워크는 여러 애플리케이션에 걸쳐 재사용 가능해야 하기 때문에 변하는 것과 변하지 않은 것들을 서로 다른 주기로 배포할 수 있도록 별도의 '배포 단위'로 분리해야 한다. 이를 위해서 별도의 패키지로 분리한다.

상위 정책 패키지와 하위 정책 패키지가 분리되었다. 이제 상위 정책을 구현하고 있는 패키지를 다른 애플리케이션에 적용할 수 있다. 이것은 8장에서 설명한 컨텍스트 독립성의 패키지 버전이다.

 

제어 역전 원리

상위 정책을 재사용하는 것은 핵심 개념들 사이의 협력 관계를 재사용하는 걸 의미한다.

사실, 좋은 객체지향 설계의 증명이 바로 이와 같은 의존성의 역전이다. 프로그램이 어떤 언어로 작성됐는가는 상관없다. 프로그램의 의존성이 역전돼 있다면, 이것은 객체지향 설계를 갖는 것이다. 

의존성 역전 원리는 프레임워크의 가장 기본적인 설계 메커니즘이다. 의존성 역전은 제어 흐름의 주체 역시 역전시킨다.

따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다.

즉, 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다. 이를 제어 역전(Inversion of Control) 원리라고 한다.