잘 설계된 객체지향 애플리케이션은 작고 응집도 높은 객체들로 구성된다.
초점이 명확하고, 한 가지의 일만 하는 객체
과도한 협력은 설계를 곤경에 빠뜨릴 수 있음
협력은 다른 객체가 존재한다는 것을 알고 있어야 함. 메시지도 알고 있어야 함.
변경과 의존성
의존성
실행 시점 : 의존하는 객체가 정상적으로 동작하기 위해서 실행시에 의존 대상 객체가 반드시 존재해야 한다.
구현 시점 : 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경된다
의존성은 방향성을 가지며, 단방향이다는 특징이 있다.
A가 B에 메시지를 보낸다 => A가 B에 의존한다. A->B라는 화살표
점선 화살표
UML과는 의존관계가 다르다
UML은 두 요소 사이에 존재할 수 있는 다양한 관계의 하나로 의존 관계를 정의한다.
의존성 전이
A->B->C 를 A->C처럼 생각할 수 있다는 뜻.
모든 경우 전이되지는 않지만, 가능성이 있다는 것
직접 의존성, 간접 의존성
직접 의존성은 명시적으로 코드에 의존성이 드러나는 것
간접 의존성은 코드상에 바로 드러나지 않는 것
런타임 의존성
실행 시간의 의존성. 우리가 작성한 코드의 구조
컴파일 의존성
실제로 코드가 컴파일 될 때인지, 코드를 작성하는 시점인지 생각할 필요는 있음
A->B(interface) <-C 인경우, 컴파일 타임은 A->B, C->B이지만, 런타임에서는 A->C에 의존한다.
동일한 소스코드 구조로 다양한 소스코드를 만들어 낼 수 있어야 함
컨텍스트 독립성
구체적인 문맥은 컴파일타임 의존성을 런타임 의존성으로 대체하느냐에 따라 달라질 것
특정 문맥에 강하게 결합될 때 다른 문맥에서 사용하기 어려워 진다.
자신이 실행될 컨텍스트에 대한 최소한의 가정만으로 이루어져 있다면 다른 문맥에서 재사용하기 더 수월해지는데, 이를 컨텍스트 독립성이라고 부른다.
각 객체가, 해당 객체를 실행하는 시스템에 관해 아무것도 알 수 없을 경우에 시스템을 변경하기가 정말 쉽다.
의존성 해결하기
컴파일타임의 의존성이 구체적인 런타임 의존성ㅇ로 변경되어야 한다.
이를 위해 교체하는 것을 의존성 해결이라고 한다
객체를 생성한 시점에 생성자를 위해 해결
객체를 생성 후 setter를 통해 해결
객체가 불완전 상태가 있을 수 있음.
메서드 실행 시 인자를 이용해 의존성 해결
보통 선호되는 방법은 생성자를 통해 안정적인 상태, setter로 추후에 해결
메서드 인자는 지속적으로 의존 관계를 맺을 필요가 없이 메서드가 실행되는 동안에만 일시적으로 의존관계가 있는 경우가 필요할 수 있음
유연한 설계
의존성과 결합도
의존성을 바람직하게 만들어야 한다.
바람직한 의존성이란 재사용성을 의미한다
특정 컨텍스트에 강하게 결합하지 않은 의존성을 의미한다.
이를 결합도로 표현한다.
바람직한 경우 느슨한 결합도, 약한 결합도. 아닌 경우 단단한 결합도, 강한 결합도라고 한다.
바람직한 의존성은 설계 재사용이 쉽게 만드는 의존성이다.
지식이 결합도를 낳는다. 서로에 대해서 거의 모른다면 결합도가 낮다. 이를 추상화로 표현한다.
추상화에 의존해라 => 결합도를 낮춘다 => 바람직한 의존성 => 변경하고 확장하고 추가하기 쉬워진다.
구체 클래스 의존성 -> 추상 클래스 의존성 -> 인터페이스 의존성
인터페이스에 의존하면 상속 계층을 모르더라도 협력 가능함.
컨텍스트 확장하는 것을 가능하게 함.
명시적인 의존성을 생성자, setter, 메서드 인자로 해결하는 방법이 좋다
생성자, setter, 인자는 퍼블릭 인터페이스에 노출됨. 이를 명시적인 의존성
안쪽에 감춰진 경우는 숨겨진 의존성이라고 한다.
명시적이지 않으면 내부 구현을 다 뜯어봐야 한다. 명시적으로 설명해야 한다.
new 는 해롭다.
구체 클래스에 의존해야 한다는 점이 문제가 된다.
new 뒤에는 추상 클래스를 넣을 수 없다.
따라서 결합도를 높이게 된다.
가끔은 생성해도 괜찮다.
협력하는 기본 객체를 설정하고 싶은 경우
보통 default 인 경우를 다루는 경우가 가장 많음
클래스의 사용성이 많이 좋아진다면 구체 클래스에 의존하는 경우가 좋을 수도 있다.
표준 클래스에 대한 의존은 해롭지 않다.
대표적으로 JDK의 표준 클래스.
이런 것들은 직접 생성해도 괜찮음 이때도 ArrayList 대신 List로 보는 쪽이 더 좋다
컨텍스트 확장하기
이때 if로 분기하는 것보다는 할인의 예시에서도 0원 할인이라는 방법을 사용하는 것이 좋음
중복 할인같은 것도, 일반적인 할인처럼 상속 받고, 그 결과를 동일하게 반환하는 것으로 내부 구현을 만든다면 정말 깔끔한 코드가 된다.
조합 가능한 행동
how 대신 what 으로 선택해야 된다는 것
