[오브젝트] 5장 책임 할당하기
[오브젝트] 5장 책임 할당하기

[오브젝트] 5장 책임 할당하기

Tags
조영호
OOP
Java
Published
August 29, 2023
Author
lkdcode

책임 할당하기

책임 할당에 이용할 GRASP 패턴

책임 주도 설계

데이터보다 행동을 먼저 결정하라 협력이라는 문맥 안에서 책임을 결정하라 이 객체가 수행해야 하는 책임은 무엇인가? -> 이 책임을 수행하는데 필요한 데이터는 무엇인가? 메시지가 객체를 선택하게 하라 🤔

도메인 개념에서 출발하기

INFORMATION EXPERT 패턴 : 수행할 정보를 알고 잇는 객체에게 책임을 할당하는 것. 🤔 140p. Screening은 가격을 계산하는 데 필요한 정보를 왜 모를까? 어떻게 모른다고 알 수 있을까?

높은 응집도와 낮은 결합도

다양한 대안들이 존재한다면 응집도와 결합도의 측면에서 더 나은 대안을 선택하라 LOW COUPLING, HIGH COHESION 패턴은 설계를 진행하면서 책임과 협력의 품질을 검토하는 데 사용할 수 있는 중요한 평가 기준이다 🤔

창조자에게 객체 생성 책임을 할당하라

CREATOR 패턴
객체 A를 생성할 때, 아래 조건을 최대한 많이 만족하는 B에게 객체 생성 책임을 할당하라
  • B가 A 객체를 포함하거나 참조한다.
  • B가 A 객체를 기록한다.
  • B가 A 객체를 긴밀하게 사용한다.
  • B가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다(이 경우 B는 A에 대한 정보 전문가다) 🤔

구현을 통한 검증

메시지는 송신자의 의도를 표현하라 내부 구현에 대한 어떤 지식도 없이 전송할 메시지를 결정했다 변경의 이유에 따라 클래스를 분리해야 한다 설계를 개선하는 작업은 변경의 이유가 하나 이상인 클래스를 찾는 것으로부터 시작하는 것이 좋다 인스턴스 변수가 초기화되는 시점을 살펴보자 클래스의 속성이 서로 다른 시점에 초기화되거나 일부만 초기화된다는 것은 응집도가 낮다는 증거다 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것
클래스 응집도 판단하기
  • 클래스가 하나 이상의 이유로 변경돼야 한다면 응집도가 낮은 것
  • 클래스의 인스턴스를 초기화하는 시점에 경우에 따라 서로 다른 속성들을 초기화하고 있다면 응집도가 낮은 것
  • 메서드 그룹이 속성의 그룹을 사용하는지 여부로 나뉜다면 응집도가 낮은 것
🤔 책임이 작은 메서드는 응집도가 높은 것인가?

다형성을 통해 타입 분리하기

동일한 책임을 수행한다는 것은 동일한 역할을 수행한다는 것 역할을 사용하면 객체의 구체적인 타입을 추상화할 수 있다 협력하는 객체의 구체적인 타입을 몰라도 상관없다 PLYMORPHISM 패턴 : 객체의 타입에 따라 변하는 행동이 있다면, 타입을 분리하고 변화하는 행동을 각 타입의 책임으로 할당하라 🤔

변경으로부터 보호하기

역할이 존재를 감춘다 PROTECTED VARIATIONS 패턴 : 변경을 캡슐화하도록 책임을 할당하는 것 설계에서 변하는 것이 무엇인지 교려하고 변하는 개념을 캡슐화하라 🤔

개선하기

모든 클래스의 내부 구현은 캡슐화돼 있고 모든 클래스는 변경의 이유를 오직 하나씩만 가진다 클래스는 작고 오직 한 가지 일만 수행한다

도메인 구조가 코드의 구조를 이끈다

객체지향은 도메인의 개념과 구조를 반영한 코드를 가능하게 만들기 때문에 도메인의 구조가 코드의 구조를 이끌어 내는 것은 자연스러울뿐만 아니라 바람직한 것이다 코드의 복잡성이 높아지더라도 변경을 쉽게 수용할 수 있게 유연한 코드를 만드는 것이 더 좋은 방법이 될 수 있다 코드의 구조가 도메인의 구조에 대한 새로운 통찰력을 제공한다 도메인 모델은 구현과 밀접한 관계를 맺어야 한다 도메인 모델을 코드와 분리된 막연한 무엇으로 생각하지 마라 🤔 도메인은 결국 존재의 이유, 언어의 종류는 상관없다. 상속 대신 합성..? 합성이 정확히 무엇인지?

책임 주도 설계의 대안

최대한 빠르게 목적한 기능을 수행하는 코드를 만들고 리팩터링 해라 코드를 수정한 후에 동작이 바뀌어선 안 된다. 동작은 바꾸지 않은 채 내부 구조를 변경하는 것을 리팩터링이라 한다 뽑아내는 것이 코드를 더욱 명확하게 하면 새로 만든 메서드의 이름이 원래 코드의 길이보다 길어져도 뽑아내라 각 메서드는 단 하나의 이유에 의해서만 변경된다 작고, 명확하며, 한 가지 일에 집중하는 응집도 높은 메서드는 변경 가능한 설계를 이끌어 내는 기반이 된다 적절한 위치란 각 메서드가 사용하는 데이터를 정의하고 있는 클래스를 의미한다 🤔 테스트 코드의 중요성을 알 것 같다

객체를 자율적으로 만들자

자신이 소유하고 있는 데이터를 자기 스스로 처리하도록 만드는 것 메서드를 다른 클래스로 이동시킬 때는 인자에 정의된 클래스 중 하나로 이동하는 경우가 일반적이다 데이터를 사용하는 메서드를 데이터를 가진 클래스로 이동시키면 캡슐화, 높은 응집도, 낮은 결합도를 가지는 설계를 얻는다 🤔 결국 이래라 저래라 하지 않는 것