일관성 있는 협력

• 객체는 협력을 위해서 존재한다.
• 협력은 객체가 존재하는 이유와 문맥을 제공한다.
• 객체 지향 설계의 목표는 적절한 책임을 수행하는 객체들의 협력을 기반으로 결합도가 낮고 재사용 가능한 코드 구조를 만드는 것이다.
• 재사용을 위해서는 객체들의 협력 방식을 일관성 있게 만들어야 한다.
• 가능하면 유사 기능을 위해서 유사 협력 패턴을 사용하면 좋다.
• 객체들의 협력이 전체적으로 일관성 있는 유사한 패턴을 따른다면 시스템을 이해하고 확장하기 위해 요구되는 시간을 줄일 수 있다.
• 이는 유사한 기능에 대해서 유사한 협력 패턴을 구사함으로써 개념적 무결성(Conceptual Integrity)을 지킬 수 있는 효과적인 방법이다.

1. 설계에 일관성 부여

• 어떤 변경이 중요한지, 그리고 그 변경을 어떻게 다뤄야 하는지에 대한 통찰력을 가져야 한다.
• 경험을 바탕으로 어디에서 일관성을 보장해야 하고 일관성을 제공하기 위해서 어떤 방법을 쓸지를 고민해야 한다.
• 좋은 방법으로 디자인 패턴이 있다. 물론 항상 정답은 아니다.

• 변하는 개념을 변하지 않는 개념으로부터 분리하자
• 변하는 개념을 캡슐화하자

• 그러기 위해서는 커다란 클래스를 작은 클래스로 분리하고 클래스는 단 하나의 이유에 의해서만 변경될 수 있게 해야 한다.
• 간단하게 말하면 단일 책임 원칙을 따르도록 클래스를 분리해야 한다는 것이다.
• 작은 클래스로 분리하면 인스턴스들 사이의 협력 패턴에 일관성을 부여하기가 쉬워진다.
• 더 좋은 방법은 추상화를 찾아 추상화에 의존하도록 하는 것이다.
• 추가로 일전에 언급한 캡슐화는 단순히 데이터 은닉으로 끝나는 개념이 아니다.
• 캡슐화는 항상 변경이라는 주제가 녹아 있다. 캡슐화의 가장 대표적인 예시는 객체의 퍼블릭 인터페이스와 구현을 분리하는 것이다.
• 즉, 캡슐화는 SW 안에서 변할수 있는 어떤 개념이라도 감추는 것이다.

• 데이터 캡슐화 : 외부에서 직접 접근할 수 없게 하며, 클래스 내부에 데이터에 접근할 수 있는 방법을 정해두는 것이다. 이는 내부에서 관리하는 데이터를 캡슐화한다.
• 메소드 캡슐화 : 클래스 외부에서 특정 메소드에 접근할 수 없게 하고 클래스 내부, 서브 클래스만 접근할 수 있게 해두는 것이다. 이는 내부 행동을 캡슐화 하는 것이다.
• 객체 캡슐화 : 객체와 객체 사이의 관계를 캡슐화 한다. 이는 합성을 의미하기도 한다.
• 서브타입 : 컴파일 타임에는 모르지만 런타임에는 클래스와 협력할 수 있다. 즉, 서브 타입의 존재를 감추고 런타임에 보인다는 것이다. 다시 말해 서브 타입 종류를 캡슐화 하는 것이다. 결과적으로 다형성 기반으로 캡슐화 하는 것이다.

• 이를 머리에 답고 협력 방식을 생각해보면 변하는 부분과 변하지 않는 부분을 분리하고, 변하는 부분을 추상화하고 나면 변하는 부분을 생략한 채 변하지 않은 부분만 이용해서 객체 사이의 협력을 논할 수 있다.
• 더 나아가면 변하지 않는 요소와 추상적인 요소만으로 전체적인 협력 구조를 설계할 수도 있다.
• 변하는 것과 변하지 않는 것을 분리하고 변하는 것을 캡슐화한 코드는 오로지 변하지 않는 것과 추상화에 대한 의존성만으로 전체적인 협력을 구현할 수 있다.

2. 협력 패턴 맞추기

• 비록 설계를 비틀어서 이상한 구조가 되더라도 전체적으로 일관성을 유지하는게 현명하다.
• 만약 이 비틀어짐을 더 이상 견딜 수 없다면 협력 패턴을 과감하게 리팩토링하는 것도 방법이다.
• 협력 패턴에서 언급할 만한 개념은 1.패턴, 2.프레임워크다.