[오브젝트 2회독] 15장 - 디자인 패턴과 프레임 워크

디자인 패턴

• s/w 설계에서 반복적으로 발생하는 문제에 대해 적용할 수 있는 해결 방법(언어에 독립적)

프레임 워크

• 설계와 코드를 함께 재사용하기 위한 것

1. 디자인 패턴과 설계 재사용

소프트웨어 패턴

실무 컨텍스트에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서 유용할 것이라고 예상되는 아이디어

• 패턴은 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달함(커뮤니케이션 비용 감소)

패턴과 책임-주도 설계

• 객체 지향 설계는 올바른 책임을 올바른 객체에게 할당하고 유연한 협력 관계를 구축하는 일
• 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿
• 중요한 것은 패턴의 세부 내용이 아닌 특정한 상황에서 패턴을 따르면 설계를 쉽고 빠르게 떠올릴 수 있다는 사실

캡슐화와 디자인 패턴

• 알고리즘 변경을 캡슐화할 때 사용하는 두가지 패턴
  • 객체 합성을 사용하는 것은 Strategy 패턴
  • 객체 상속을 사용하는 것은 Template method 패턴
• STRATEGY 패턴은 런타임에 객체의 알고리즘 변경이 가능하며, Template method pattern은 결합도가 높아 런타임에 변경 불가능
• 하지만 알고리즘 교체의 니즈가 없다면 복잡도를 낮출수 있는 STRATEGY 패턴이 효과적

패턴은 출발점이다

• 패턴은 설계의 목적이 되어선 안되며, 현재 요구사항에 맞게 패턴이 맞지 않다면 수정해야 함
• 패턴이 제시하는 구조를 맹목적으로 따르게 될 경우 불필요하게 복잡하고 유지보수 하기 어려운 시스템을 낳음
• 어떤 컨텍스트에서 어떤 패턴이 적용되어야 하고, 적용 되어선 안되는지 익혀야 함

2. 프레임워크와 코드 재사용

코드 재사용 vs 설계 재사용

• 프레임워크란
  • 추상 클래스나 인터페이스를 정의하고 인스턴스 사이에 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계(ex. iOS UIKit)
  • 애플리케이션 개발자가 현재 요구사항에 맞게 커스터마이징 할 수 있는 애플리케이션 골격
  • 핵심은 결국 설계와 코드 재사용이라는 사용 목적

프레임워크가 코드 재사용이 가능하지만, 결국 중요한 건 설계 자체의 재사용이 중요

상위 정책으로 패키지 분리

• 협력을 일관성 있고 유연하게 만들기 위해 추상화를 위해 변경을 캡슐화
• 세부 사항은 자주 변경되기 때문에 이를 캡슐화 하고 상위 정책에서 의존해선 안됨
• 시스템을 프레임워크로 배포한다면, 변하는 것과 변하지 않는 것을 분리하여 서로 다른 주기로 배포

제어 역전 원리

• 의존성 역전 원칙은 의존성 방향뿐 아니라 제어 흐름의 주체 역시 역전
  • 객체 지향에선 프레임워크가 애플리케이션에 속한 서브 클래스 메서드를 호출
  • 절차적 프로그래밍에서는 상위 모듈 → 하위 모듈을 구체적으로 호출
  • 더이상 라이브러리의 구체적 호출에 의존하지 않고, 프레임워크가 메서드를 호출하는 것에 의존하게 됨.

결론

• 디자인 패턴은 설계 재사용이 목적, 프레임워크는 코드 및 설계 재사용이 목적
• 패턴의 정의는 현재와 다른 실무 컨텍스트에서 유용하게 사용될 수 있는 아이디어
• 패턴은 목적지가 되어선 안되며, 해결하고자 하는 상황에 맞게 변경해서 사용할 수 있어야 함
• 패턴의 맹목적 지향은 더욱 유지보수가 어렵고 이해하기 힘든 코드를 양산
• 프레임워크의 핵심은 설계를 재사용하는 것
• 의존성 역전 원칙에 따라 전통적 제어흐름이 역전된 형태를 보임(프레임워크가 서브 클래스를 호출)