15 디자인 패턴과 프레임워크

15장은 오브젝트 책의 마지막 챕터로 지금까지 배운 객체지향의 개념을 바탕으로 디자인 패턴과 프레임워크에 대해 이야기하고 있습니다. 특히 이번장에서 저는 프레임 워크에 정의에 대해 새로 배웠으며 디자인 패턴의 종류가 아닌 정의에 대해 공부한 적은 처음이기에 어려웠지만 흥미롭게 읽었습니다.

---

이처럼 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법을 디자인 패턴이라고 부른다.
...
디자인 패턴이 설계를 재사용하기 위한 것이라면 프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다.

세부적인 내용에 들어가기전 디자인 패턴은 무엇인지 프레임워크가 무엇인지 짚어주는 부분입니다. 저는 이 부분을 읽기 이전까지 프레임워크는 제어의 역전이 적용된 코드라고 이해를 하고 있었지만 디자인 패턴, 설계의 측면에서 프레임워크를 다시 바라볼 수 있었습니다.

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

소프트웨어 패턴

패턴이란 무엇인가를 논의할 때면 반복적으로 언급되는 몇 가지 핵심적인 특징이 있다.
1. 패턴은 반복적으로 발생하는 문제와 해법의 쌍으로 정의된다.
2. 패턴을 사용함으로써 이미 알려진 문제와 이에 대한 해법을 문서로 정리할 수 있으며, 이 지식을 다른 사람과 의사소통할 수 있다.
3. 패턴은 추상적인 원칙과 실제 코드 작성 사이의 간극을 메워주며 실질적인 코드 작성을 돕는다.
4. 패턴의 요점은 패턴이 실무에서 탄생했다는 점이다.
...
내가 사용하는 패턴 정의는 하나의 실무 컨텍스트에서 유용하게 사용해왔고 다른 실무 컨텍스트에서도 유용할 것이라고 예상되는 아이디어다.
...
패턴이 지닌 가장 큰 가치는 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달할 수 있다는 점이다. 패턴은 경험의 산물이다.
...
패턴의 이름은 높은 수준의 대화를 가능하게 하는 원천이다.
...
모든 영역이 패턴의 대상이 될 수 있다.

소프트웨어 패턴이란 무엇인가에 대해 자세하게 이야기하고 있습니다. 먼저 패턴은 누군가 발명한 것이 아닌 실무에서 공통적으로 사용되어지는 일종의 설계에 대한 템플릿이며 클래스나 객체에 대한 이야기가 아닌 협력과 책임에 대한 이야기라는 것입니다. 또한 패턴에 대해 이야기를 하며 책에서는 경험과 실무를 강조하고 있습니다. 해당 부분에서 저는 패턴은 일종의 약속된 문맥을 가리키는 용어와도 같다는 생각을 하였습니다.

 

패턴분류

디자인 패턴은 특정 정황 내에서 일반적인 설계 문제를 해결하며, 협력하는 컴포넌트들 사이에서 반복적으로 발생하는 구조를 서술한다.

디자인 패턴을 왜 사용하는지에 대해 이야기를 하고 있다는 느낌을 받았습니다. 그리고 제가 느낀 바로는 실무에서 자주 발생하는 설계 관련 문제를 해결하는 것에 방점을 둔다 였습니다.

 

패턴과 책임-주도 설계

중요한 것은 패턴을 따르면 특정한 상황에 적용할 수 있는 설계를 쉽고 빠르게 떠올릴 수 있다는 사실입니다.
...
디자인 패턴의 구성요소가 클래스와 메서드가 아니라 역할과 책임이라는 사실을 이해하는 것이 중요하다.

패턴을 따르면 특정한 상황에서 책임 주도 설계에 대한 고민 없이 빠르게 구현이 가능하다는 장점이 있습니다. 또한 디자인 패턴은 책임과 협력에 대한 것이지 구체적인 구현방법에 대해 언급하지 않는 것 역시 중요한 포인트중 하나이라 생각합니다.

 

캡슐화와 디자인 패턴

디자인 패턴에서 중요한 것은 디자인 패턴의 구현방법이나 구조가 아니다. 어떤 디자인 패턴이 어떤 변경을 캡슐화 하는지를 이해하는 것이 중요하다.

디자인 패턴은 추상적으로 이야기하면 템플릿을 제공하는것이며 조금 더 이야기하면 변경과 캡슐화를 수행하는 방법이 중요한 포인트라 생각합니다.

 

패턴은 출발점이다.

패턴은 설계의 목표가 돼서는 안 된다. 패턴은 단지 목표로 하는 설계에 이를 수 있는 방향을 제시하는 나침반에 불과하다.
...
정당한 이유 없이 사용된 모든 패턴은 설꼐를 복잡하게 만드는 장애물이다. 패턴은 복잡성의 가치가 단순성을 넘어설 때만 정당화돼야 한다.

개발에 있어 항상 정답은 없다 생각합니다. 그리고 이것은 디자인 패턴에 있어서도 비슷하게 적용됩니다. 책에서 이야기하는 것을 하나의 문장으로 줄여 말하면 '패턴이 만능은 아니다.'가 될 것 같습니다.

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

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

여기서는 프레임워크에 대해 이야기하고 있습니다. 그리고 프레임워크에 대한 정의를 먼저 말하고 있으며 객체지향에 대해 공부를 하기 이전에는 제어의 역전이 적용된 무언가로 알고 있었습니다. 그러나 객체지향을 공부한 지금이라면 제어의 역저은 프레임워크가 가지고 있는 속성중 하나이며 핵심은 '재사용 가능한 설계를 미리 구현해놓은 코드'라 생각합니다.

 

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

협력을 일관선 있고 유연하게 만들기 위해서는 추상화를 이용해 변경을 캡슐화해야 한다.
...
요점은 상위 정책이 세부 사항보다 더 다양한 상황에서 재사용될 수 있어야 한다는 것이다.
...
이 문제를 해결할 수 있는 가장 좋은 방법은 의존성 역전 원칙에 맞게 상위 정책과 세부 사항 모두 추상화에 의존하게 만드는 것이다.
...
프레임워크는 여러 애플리케이션에 걸쳐 일관성 있는 협력을 구현할 수 있게 해준다. 그리고 일관성 있는 협력이 제공하는 다양한 정점들은 프레임워크에 대해서도 여전히 적용된다.

이전 포스팅에서는 상위/하위 정책으로 나누는 방법에 대해 깊숙하게 이야기를 하였다면 이번 장에서는 전체적인 설계의 측면에서 이야기를 하고 있다는 인상을 받았습니다. 그리고 이는 여느 프로그램에서 그렇듯 상위수준(추상화가 더 되어 있는 코드)에서는 하위수준(추상화가 덜 되어있는 코드)에 영향을 받으면 안된다는 것을 이야기 하고 있습니다.

 

제어 역전 원리

로버트 마틴은 훌륭한 객체지향 설계는 의존성이 역전되는 설계라는 점을 강조한다.

마지막으로 객체지향의 기본이 되는 제어 역전 원리에 대해 이야기를 하고 있습니다. 이는 이미 여러번 이야기하였는 내용이며 제어의 역전을 기반으로 객체지향 프로그래밍을 하기에 마지막 장의 마지막 챕터에 이야기를 하였다 생각합니다.