본문 바로가기
스터디/오브젝트

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

by 디토20 2024. 4. 16.
반응형

 

 

 

 

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

 

 

  • 디자인 패턴 : 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법
    • 디자인 패턴의 목적은 설계를 재사용하는 것
  • 프레임워크 : 설계와 코드를 함께 재사용하기 위한 것
    • 프레임워크는 애플리케이션의 아키텍처를 구현 코드의 형태로 제공한다.
  • 디자인 패턴과 프레임워크 모두 협력을 일관성 있게 만들기 위한 방법이다.

 

15.1 디자인 패턴과 설계 재사용

  • 패턴이란 무엇인가?
    • 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다.
    • 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사소통할 수 있다.
    • 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕는다.
    • 패턴의 요점은 패턴이 실무에서 탄생했다는 점이다.
  • 패턴은 한 컨텍스트에서 유용한 동시에 다른 컨텍스트에서도 유용한 아이디어다.
  • 패턴으로 인정하기 위한 조건으로 '3의 규칙'이 언급된다.
    • 최소 세가지의 서로 다른 시스템에 특별한 문제 없이 적용할 수 있고 유용한 경우에만 패턴으로 간주할 수 있다.
  • 패턴은 실무에서 검증된 자산이므로 실무 경험이 적은 초보도 패턴을 익히고 적용함으로써 유연하고 품질 높은 소프트웨어를 개발할 수 있다.

 

15.1.1 패턴 분류

  • 패턴은 일반적응로 패턴의 범위나 적용단계에 따라 아키텍처 패턴, 분석 패턴, 디자인 패턴, 이디엄의 4가지로 분류된다.
  • 디자인 패턴은 가장 널리 알려진 패턴으로, 특정 정황 내에서 일반적인 설계 문제를 해결하며 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술한다.
  • 디자인 패턴중간 규모의 패턴으로 특정한 설계 문제를 해결하는 것을 목적으로 하며 프로그래밍 언어나 패러다임에 독립적이다.
  • 아키텍처 패턴은 디자인 패턴의 상위 패턴으로 소프트웨어의 전체적인 구조를 결정할 때 사용된다.
  • 아키텍처 패턴은 구체적인 소프트웨어 아키텍처를 위한 템플릿을 제공하며 디자인 패턴과 마찬가지로 프로그래밍 언어나 패러다임에 독립적이다.
  • 이디엄은 디자인 패턴의 하위로, 특정 프로그래밍 언어에만 국한되는 하위 레벨 패턴이다.
  • 위 세 패턴이 주로 기술적인 문제를 해결하는데 초점을 맞춘다면, 분석 패턴은 도메인 내의 개념적인 문제를 해결하는데 초점을 맞춘다.
  • 분석 패턴은 업무 모델링 시에 발견되는 공통적인 구조를 표현하는 개념들의 집합이다.

 

15.1.2 패턴과 책임-주도 설계

  • 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다.
  • 특정 상황에 적용 가능한 패턴을 잘 알고 있다면 책임 주도 설계 절차를 하나하나 따르지 않고도 시스템에 구현할 객체들의 역할과 책임, 협력 관계를 빠르고 손쉽게 구성할 수 있다.
  • 패턴의 구성 요소는 클래스가 아니라 '역할'이므로 구현은 여러가지 방법으로 될 수 있다.

 

15.1.3 캡슐화와 디자인 패턴

  • 대부분의 디자인 패턴 목적은 특정한 변경을 캡슐화함으로써 유연하고 일관성 있는 협력을 설계할 수 있는 경험을 공유하는 것이다.
  • 디자인 패턴에서 중요한 것은 구현 방법이나 구조가 아닌, 어떤 디자인 패턴어떤 변경을 캡슐화하는지를 이해하는 것이다.

 

15.1.4 패턴은 출발점이다

  • 패턴은 출발점이지 목적지가 아니다.
  • 패턴이 설계의 목표가 되어서는 안된다.
  • 패턴이 현재의 요구사항이나 적용 기술, 프레임워크에 적합하지 않다면 패턴을 그대로 따르지 말고 목적에 맞게 패턴을 수정하라.
  • 해결하려는 문제가 아니라 패턴이 제시하는 구조를 맹목적으로 따르는 것은 불필요하게 복잡하고 유지보수하기 어려운 시스템을 낳는다.
  • 패턴을 가장 효과적으로 적용하는 방법은 패턴을 지향하거나 패턴을 목표로 리팩터링 하는 것이다.

 

15.2 프레임워크와 코드 재사용

15.2.1 코드 재사용 대 설계 재사용

  • 재사용 관점에서 설계 재사용보다 더 좋은 방법은 코드 재사용이다.
  • 가장 이상적인 형태의 재사용은 설계 재사용과 코드 재사용을 적절한 수준으로 조합하는 것이다.
  • 프레임워크란 추상 클래스나 인터페이스를 정의하고 인스턴스 사이의 상호작용을 통해 시스템 전체 혹은 일부를 구현해 놓은 재사용 가능한 설계를 말한다.
  • 프레임워크는 코드를 재사용함으로써 설계 아이디어를 재사용한다.

 

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

  • 프레임워크의 핵심은 추상 클래스나 인터페이스와 같은 추상화라고 할 수 있다.
  • 그림에서 알수 있는 것처럼 구체 클래스들은 추상클래스에 의존하지만, 추상 클래스는 구체 클래스에 의존하지 않는다.

 

 

 

  • 변하지 않는 것은 상위 정책이고, 변하는 것은 구체적인 세부 사항이다.
  • 변하는 부분과 변하지 않는 부분을 별도의 패키지로 분리해 서로 다른 주기로 배포할 수 있도록 해야한다.
  • 세부 사항을 구현한 패키지는 항상 상위 정책을 구현한 패키지에 의존해야 한다.
  • 상위 패키지는 여러 애플리케이션에서 재사용할 수 있는 요금 계산 프레임워크로 사용할 수 있다.

 

 

15.2.3 제어 역전 원리

  • 상위 정책을 재사용한다는 것은 결국 도메인에 존재하는 핵심 개념들 사이의 협력 관계를 재사용한다는 것을 의미한다.
  • 요구사항이 빠르게 진화하는 코드에서 의존성 역전 원리가 적절하게 지켜지지 않는다면 그곳에는 변경을 적절하게 수용할 수 없는 하향식의 절차적인 코드가 존재할 수 밖에 없다.
  • 훌륭한 객체지향 설계는 의존성이 역전된 설계라는 점을 강조한다.
  • 의존성을 역전시킨 객체지향 구조에서는 반대로 프레임워크가 애플리케이션에 속하는 서브클래스의 메서드를 호출한다.
  • 따라서 프레임워크를 사용할 경우 개별 애플리케이션에서 프레임워크로 제어 흐름의 주체가 이동한다.
  • 프레임워크에서는 일반적인 해결책만 제공하고 애플리케이션에 따라 달라질 수 있는 특정한 동작은 비워둔다.
  • 이렇게 완성되지 않은 채로 남겨진 동작을 훅(hook)이라고 부른다.

 

 

 

 

 

 

 

728x90
반응형

댓글