15일차 - 퍼블릭 인터페이스 만들기

2023.08.18 FRI

183p ~ 198p

 

14일차 내용 ⬇️

2023.08.15 - [개발 서적 기록/오브젝트_조영호] - 14일차 - 협력, 메시지, 퍼블릭 인터페이스, 오퍼레이션

14일차 - 협력, 메시지, 퍼블릭 인터페이스, 오퍼레이션

---

퍼블릭 인터페이스 만들기 : 협력 경로를 제한하자, 직접 상태를 판단해서 결정하지 말자.

객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라. 
( 이것이 디미터 법칙이다. Law of Demeter :Don't Talk to Strangers )

 

A라는 객체가 B라는 객체에 의존하고 있는데, 내부적으로 "B.C"와 같은 코드를 통해서 A객체가 C객체에도 의존하게 되는 경우다.

sale.getPayment().getAmount() 와 같은 경우도 해당한다.

 

따라서, 인접한 이웃하고만 소통하라는 법칙이다. 

 

협력 경로를 제한한다는 것은 필요한 대상에게만 메시지를 전송하라는 것도 동일하다.

어떠한 클래스 C와 그 클래스에 구현된 메서드 M은 두가지의 대상에만 메시지를 전송해야한다.

• M의 파라미터로 전달된 클래스 ( 자신인 클래스 C도 포함 )
• C의 인스턴스 변수의 클래스

위와 같은 대상은 아래와 같은 인스턴스가 포함된다.

• this 객체 / The this object (or self)
• 메서드의 매개변수 / A parameter of the method
• this의 속성 필드 / An attribute of this
• this의 속성 필드 중 컬렉션 타입인 속성의 요소 / An element of a collection which is an attribute of this
• 메서드 내에서 생성된 지역 객체 / An object created within the method

이 말은 sale.getPayment().getAmount() 와 같은 코드라고 한다면, sale.getPayAmount()로 변경하고, sale 객체는 getPayAmount() 메서드를 호출하면 getPayment()와 getAmount()를 내부적으로 수행하도록 만들어 디미터의 법칙을 지킬 수 있다.

이렇게 객체의 상태에 관해 묻지 말고, 원하는 것을 시키는 방식의 메시지를 작성해야한다.

( 이것이 묻지 말고 시켜라 라는 법칙이다. Tell, Don't Ask )

 

이렇게 협력 경로를 제한하면, 곧 캡슐화를 수행한 것과 같다.메시지 수신자의 내부 구조가 전송자에게 노출되지 않고, 메시지 전송자는 수신자의 내부 구현에 결합되지 않는다.

 

그리고, 상태를 묻는 오퍼레이션을 행동을 요청하는 오퍼레이션으로 제한하면, 역시나 캡슐화를 수행한 것이다.메시지 전송자는 메시지 수진자의 상태를 기반으로 결정을 내리지 않고, 그러한 상태에 대한 행위를 객체에게 위임한다.

 

결국 낮은 결합도를 유지하고, 높은 응집도를 가질 수 있다.

퍼블릭 인터페이스 만들기 : 의도를 드러내는 인터페이스

객체의 행위를 나타내는 메서드를 외부에 나타낼 때, 즉 이름을 지을 때에는, 어떻게 로직을 수행하는지가 드러나서는 안된다.

메서드의 이름은 무엇을 하는지 나타내야한다.

어떻게 하는지, 어떤 방법을 쓰는지를 나타내면, 내부 구현을 외부로 노출하기 때문에 캡슐화를 위반하고 변경에 취약하다.

 

무엇을 나타내는지 나타내도록 메서드의 이름을 짓는 패턴을 의도를 드러내는 선택자 패턴이라고 부른다.

이렇게 의도를 드러내는 방법으로는 인터페이스를 사용할 수 있다.

인터페이스 단위에서 의도를 드러내는 인터페이스와 그 메서드를 작성함으로써, 구현과 관련된 모든 정보가 캡슐화되고, 협력과 관련된 의도만 노출할 수 있다.