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

 

 

5장은 GRASP 책임할당패턴에 대해서 설명하고,

책임을 중심으로 설계를 하는 것이 캡슐화, 응집도, 결합도 관점에서 설계를 개선할 수 있다는 것을 보여준다.

 

 

객체 디자인에서 가장 기본이 되는 것 중의 하나는 책임을 어디에 둘 지를 결정하는 것이다. 나는 십년 이상 객체를 가지고 일했지만 처음 시작할 때는 여전히 적당한 위치를 찾지 못한다. 늘 이런 점이 나를 괴롭혔지만, 이제는 이런 경우에 리팩터링을 사용하면 된다는 것을 알게 되었다 [Fowler 1999a](p.166).

 

 

GRASP

"General Responsibility Assignment Software Pattern

(일반적인 책임 할당을 위한 소프트웨어 패턴)"

 

 

INFORMATION EXPERT(정보 전문가) 패턴

- 책임을 수행할 정보를 알고 있는 객체에게 책임 할당

- 주의할 점은 정보는 데이터와 다르다. 즉, 정보 전문가는 정보를 알고 있다고 해서 그 정보를 저장하고 있을 필요는 없다. 

 

CREATOR(창조자) 패턴

- 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침 제공

- 예를 들어, 영화 예매 협력의 최종 결과물은 Reservation 인스턴스를 생성하는 것인데 Reservation을 잘 알고 있거나, 긴밀하게 사용하거나, 초기화에 필요한 데이터를 가지고 있는 객체는 무엇인가? 와 같은 질문을 통해 해당 객체를 생성할 책임을 할당한다. 

 

POLYMORPHISM(다형성) 패턴

- 객체의 타입에 따라 변하는 로직이 있을 때 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임 할당

- 클래스 분해 -> 책임 분산

 

PROTECTED VARIATIONS(변경 보호) 패턴

- 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임 할당 

- 인터페이스를 활용하여 변경을 캡슐화

 

 

 

설계를 개선하는 방법

낮은 응집도를 해결하기 위해 변경의 이유에 따라 클래스를 분리해야 한다. 

왜냐하면 클래스가 하나 이상의 이유로 변경되어야 한다면 응집도가 낮기 때문이다. 

 

그럼 변경의 이유는 어떻게 파악할 수 있을까?

 

첫번째로는, 인스턴스 변수가 초기화되는 시점을 살펴보는 것이다. 

응집도가 높은 클래스는 인스턴스를 생성할 때 모든 속성을 함께 초기화한다.

-> 함께 초기화되는 속성을 기준으로 코드 분리

 

두 번째로는, 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것이다. 

모든 메서드가 객체의 모든 속성을 사용한다면 클래스의 응집도는 높다고 볼 수 있다 

->  속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드 분리

 

 

 

 

4장까지 스터디를 하면서 많이 이해했다고 생각했는데 매번 새롭다. 

책임을 중심으로 설계하고 낮은 결합도와 높은 응집도를 고려하고,

변화하는 것은 캡슐화하여 변경에 대처할 수 있는 유연한 코드를 작성하는 것.

객체지향 언어를 사용하여 프로그래밍을 하는 내가 계속 고민해 보고 추구해야 하는 방향이다.

개념은 계속 반복적으로 공부하니까 이제 잘 이해가 되는데 

이상적으로 코드를 구현하는 것은 어렵다. 하지만, 우리에겐 리팩토링이 있다. 

 

 

먼저 실행되는 코드부터 작성한 다음에 책임을 이동시키면서 내부 구조를 변경해 보는 거다. 

데이터 중심으로 구현한 다음에 리팩터링해도 괜찮다. 

 

 

---

 

 

 

자바 문법(자바의 정석 챕터 14 참고)

 

람다와 Stream

Stream은

• 데이터 소스를 추상화하고, 데이터를 다루는데 자주 사용되는 메서드들을 정의해 놓음
• 데이터 소스를 변경하지 않음
• 일회용임
• 작업을 내부 반복으로 처리(반복문을 메서드 내부에 숨김)
• 스트림 연산
  • 중간연산/최종연산으로 분류

private boolean checkSequenceConditions(Screening screening) {
	return sequenceConditions.stream()
    			.anyMatch(condition -> condition.isSatisfiedBy(Screening));
}

sequenceConditions는 List <>인데 이 값을 받아서 stream의 최종연산 중 하나인 boolean anyMatch (Predicate <T> p)를 활용해 isSatisfiedBy 조건을 하나라도 만족하는지 확인함.

 

 

---

// TODO 

람다/스트림 다시 공부. 

Predicate <T>는 뭘까..?

 

람다와 스트림 정리한 내용

 

 

 

 

 

참고자료

https://docs.oracle.com/javase/tutorial/extra/generics/morefun.html

https://stackoverflow.com/questions/2827585/what-is-super-t-syntax

https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html