[TIL] 2021.01.27 인터페이스, 오리 타입

Facts

 

Feelings

 

Findings

4.2 인터페이스 정의하기

퍼블릭 인터페이스: 메뉴판, 바깥을 향한 클래스의 얼굴, 쉽게 변경x

프라이빗 인터페이스: 부엌 안의 메시지, 세부 구현, 언제든 변경 가능

책임, 의존성, 그리고 인터페이스: 퍼블릭은 안정적인 부분, 프라이빗은 불안정한 부분이라는 뜻을 내포.

퍼블릭 인터페이스와 프라이빗 인터페이스를 구분하는 이유 - 내부를 마음대로 변경하기 위해서

 

4.3 퍼블릭 인터페이스 찾아내기 - 예술적 작업, 정해진 법칙이 없다.

요구사항: 유스케이스

의도를 구성하기 - 도메인 객체가 아니라 그들의 메시지에 집중

시퀀스 다이어그램 사용하기 - 과도한 의존성을 조심해라, 각자에게 최소의 책임만

No How, But What -----v

주어진 맥락에서 독립적일 수 있게 하기 - 다른 객체에 대해 전혀 모를 수록 유연하게 재사용될 수 있다.

다른 객체를 믿기 - 믿고 분리시켜라

새로운 객체를 찾아내기 위해 메시지를 사용하기 - 메시지에 맞는 객체가 없다면 새로 만들어라.

메시지 기반 애플리케이션 만들기 - 시퀀스 다이어그램은 메시지를 잘 표현하기 때문에 이에 적합하다.

 

4.4 자신의 인터페이스를 드러내는 코드 작성하기 - 우리 앱의 특징을 드러내고 그 미래를 결정하는 것은 바로 인터페이스다.

명시적인 인터페이스 만들기 - public, protect, private 키워드는 다른 프로그래머에게 어떤 메소드에 의존해도 괜찮은지 알려주는 것이다.

다른 이의 퍼블릭 인터페이스를 존중하자 - 그러니 프라이빗 말고 퍼블릭에 의존하자.

프라이빗 인터페이스에 의존할 때는 특별히 주의를 - 의존성을 고립시키자(3장)

 

4.5 데메테르의 원칙

정의 - 메시지를 전달받은 객체가 바로 다른 타입의 객체에게 메시지를 전달하지 않는 것(마치 기차처럼)

위반의 결과 - 중간의 객체를 사용하기 힘들어진다. 하나를 수정하면 전체가 오작동할 수 있다(불투명성).  

위반하지 않기 - 메시지 위임 사용하기(delegration)

데메테르의 원칙에 귀 기울이기 - 메시지 기반의 관점 취하기. 메시지가 곧 퍼블릭 인터페이스가 된다.

 

5장. 오리타입으로 비용 줄이기

5.1 오리 타입 이해하기 - 구체적인 클래스에 의존하는 것이 아닌, 더 추상화된 클래스에 의존하는 것. 

 

5.3 오리 타입을 무서워하지 않고 사용하기

동적 타입 받아들이기

동적타입은 수술용 메스같은 것이라, 잘 사용하면 좋고, 잘못 사용하면 독이다.

정적 타입 추종자들이 생각하듯 컴파일러가 런타임에러를 막아주는 것은 아니다.

Future Action Plans

 

Feedback