디자인 패턴
- 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법
- 설계를 재사용하는 것이 목적
프레임워크
- 설계와 코드를 함께 재사용하는 것이 목적
- 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공
📖 15.1 디자인 패텅과 설계 재사용
🔖 15.1.1 소프트웨어 패턴
패턴이란❓
- 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의
- 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사소통할 수 있다.
- 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕는다.
- 패턴의 요점은 패턴이 실무에서 탄생했다는 점이다.
하나의 실무 컨텍스트에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어다. - 마틴 파울러
🛠️ 3의 규칙
- 최소 세 가지의 서로 다른 시스템에 특별한 문제 없이 적용할 수 있고 유용한 경우에만 패턴으로 간주할 수 있다.
패턴의 이름은 높은 수준의 대화를 가능하게하는 원천이다.
패턴은 홀로 존재하지 않는다.
- 연관된 패턴들의 집합들이 모여 하나의 패턴 언어(패턴 시스템)를 구성한다.
🔖 15.1.2 패턴 분류
- 디자인 패턴
- 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술
- 아키텍처 패턴
- 소프트웨어의 전체적인 구조를 결정하기 위해 사용할 수 있다.
- 미리 정의된 서브시스템들을 제공하고, 각 서브시스템들의 책임을 정의하며, 서브시스템들 사이의 관계를 조직화하는 규칙과 가이드라인을 포함
- 구체적인 소프트웨어 아키텍처를 위한 템플릿을 제공
- 이디엄(Idiom)
- 특정 프로그래밍 언어에만 국한된 하위 레벨 패턴
- 주어진 언어의 기능을 사용해 컴포넌트, 컴포넌트 간의 특정 측면을 구현하는 방법을 서술
- 언어에 종속적
- 분석 패턴
- 도메인 내의 개념적인 문제를 해결하는 데 초점을 맞춤.
- 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합
🔖 15.1.3 패턴과 책임-주도 설계
객체지향 설계에서 가장 중요한 일은 올바른 책임을 올바른 객체에게 할당하고 객체 간의 유연한 협력관계를 구축하는 일이다.
- 패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴 수 있다.
- 패턴의 구성 요소는 클래스와 메서드가 아니라 '역할과 책임'이다.
- 어떤 구현 코드가 어떤 디자인 패턴을 따른다고 이야기할 때는 역할, 책임, 협력의 관점에서 유사성을 공유한다는 것이지 특정한 구현 방식을 강제하는 것은 아니다.
🔖 15.1.4 캡슐화와 디자인 패턴
대부분의 디자인 패턴의 목적은 특정한 변경을 캡슐화함으로써 유연하고 일관성 있는 협력을 설계할 수 있는 경험을 공유하는 것
- 디자인 패턴에서 중요한 것은 디자인 패턴의 구현 방법이나 구조가 아니다.
- 어떤 디자인 패턴이 어떤 변경을 캡슐화하는지를 이해하는 것이 중요하다.
- 디자인 패턴이 변경을 캡슐화하기 위해 어떤 방법을 사용하는지를 이해하는 것이 더 중요하다.
🔖 15.1.5 패턴은 출발점이다
패턴은 출발점이지 목적지가 아니다. 디자인 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않다면 패턴을 그대로 따르지 말고 목적에 맞게 패턴을 수정하라.
- 해결하려는 문제가 아니라 패턴이 제시하는 구조를 맹목적으로 따르는 것은 불필요하게 복잡하고, 난해하며, 유지보수하기 어려운 시스템을 낳는다.
📖 15.2 프레임워크와 코드 재사용
🔖 15.2.1 코드 재사용 대 설계 재사용
재사용 관점에서 설계 재사용보다 더 좋은 방법은 코드 재사용이다.
프레임워크란❓
- 추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계
- 애플리케이션 개발자가 현재의 요구사항에 맞게 머스터마이징할 수 있는 애플리케이션의 골격(skeleton)
- 코드를 재사용함으로써 설계 아이디어를 재사용
🔖 15.2.2 상위 정책과 하위 정책으로 패키지 분리하기
상위 정책은 상대적으로 변경에 안정적이지만 세부 사항은 자주 변경된다. 그리고 상위 정책이 세부 사항에 비해 재사용될 가능성이 높다.
- 상위 정책이 세부 사항보다 더 다양한 상황에서 재사용될 수 있어야 한다.
- 상위 정책이 세부 사항에 의존하게 되면 상위 정책이 필요한 모든 경우에 세부 사항도 항상 함께 존재해야 하기 때문에 상위 정책의 재사용성이 낮아진다.
- 의존성 역전 원칙에 맞게 상위 정책과 세부 사항 모두 추상화에 의존하게 만든다.
- 변하는 것(구체적인 세부 사항)과 변하지 않는 것(상위 정책에 속하는 역할들의 협력구조)을 서로 다른 주기로 배포할 수 있도록 별도의 '배포 단위'로 분리해야 한다.
- 상위 정책을 구현하고 있는 패키지를 다른 애플리케이션에 재사용할 수 있다.
🔖 15.2.3 제어 역전 원리
프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다.
- 의존성을 역전시키면 제어 흐름의 주체 역시 역전된다.
- IoC 원리, Hollywood 원리
프레임워크에서는 일반적인 해결책만 제공하고 애플리케이션에 따라 달라질 수 있는 특정한 동작은 비워둔다.
- 완성되지 않은 채로 남겨진 동작을 훅(hook)이라고 부른다.
- 재정의된 훅은 제어 역전 원리에 따라 프레임워크가 원하는 시점에 호출
- 우리는 프레임워크가 적절한 시점에 실행할 것으로 예상되는 코드를 작성할 뿐이다.
제어의 역전이 프레임워크의 핵심 개념인 동시에 코드의 재사용을 가능하게 하는 힘이라는 사실을 이해해야 한다.
