[독서 기록] 오브젝트 6장 메시지와 인터페이스

 

오브젝트

객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재로 바라보는 것이다. 세번째 걸음을 내디딜 수 있는지 여부는 협력에 참여하는 객체 들에게 얼마나 적절한 역할과 책임을 부여할 수 있느냐에 달려 있다. 객체지향의 마지막 걸음은 앞에서 설명한 개념들을 여러분이 사용하는 프로그래밍 언어라는 틀에 흐트러짐 없이 담아낼 수 있는 기술을 익히는 것이다. 《객체지향의 사실과 오해》가 첫번째 걸음과 두번째 걸음인 객체와 협력에 초점을 맞췄다면 《오브젝트: 코드로 이해하는 객체지향 설계》는 세번째와 네번째 걸음인 책임의 할당과 그 구현에 초점을 맞춘다. 이 책을 읽고 나면 객체에 적절한 역할과 책임을 부여하는 방법과 유연하면서도 요구사항에 적절한 협력을 설계하는 방법을 익히게 될 것이다. 나아가 프로그래밍 언어라는 도구를 이용해 객체지향의 개념과 원칙들을 오롯이 표현할 수 있는 방법 역시 익힐 수 있을 것이다. ★ 이 책에서 다루는 내용 ★ ◎ 역할, 책임, 협력에 기반해 객체지향 프로그램을 설계하고 구현하는 방법 ◎ 응집도와 결합도를 이용해 설계를 트레이드오프하는 방법 ◎ 설계를 유연하게 만드는 다양한 의존성 관리 기법 ◎ 타입 계층을 위한 상속과 코드 재사용을 위한 합성의 개념 ◎ 다양한 설계 원칙과 디자인 패턴

저자

조영호

출판

위키북스

출판일

2019.06.17

 

 

 

디미터 법칙

묻지 말고 시켜라 

의도를 드러내는 인터페이스

명령-쿼리 분리 

 

다음은 디미터 법칙을 위반하는 코드의 전형적인 모습을 표현한 것이다. 

screening.getMovie().getDiscountConditions();

185p 

 

 

절차적인 코드는 정보를 얻은 후에 결정한다. 객체지향 코드는 객체에게 그것을 하도록 시킨다[Sharp00]. 

- 186p 

 

 

 

의도를 드러내는 선택자 

-190

 

 

오퍼레이션의 이름은 협력이라는 문맥을 반영해야 한다. 오퍼레이션은 클라이언트가 객체에게 무엇을 원하는지를 표현해야 한다. 다시 말해 객체 자신이 아닌 클라이언트의 의도를 표현하는 이름을 가져야 한다. sellTo, buy, hold라는 이름은 클라이언트가 객체에게 무엇을 원하는지를 명확하게 표현한다. setTicket은 그렇지 않다. 

- 197p 

 

 

IntStream.of(1, 15, 20, 3, 9).filter(x->x>10).distinct().count();

위 코드에서 of, filter, distinct 메서드는 모두 IntStream이라는 동일한 클래스의 인스턴스를 반환한다. 

-> 따라서 이 코드는 디미터 법칙을 위반하지 않는다. 디미터 법칙은 결합도와 관련된 것이며, 이 결합도가 문제가 되는 것은 객체의 내부 구조가 외부로 노출되는 경우로 한정된다. 

- 198p 

 

 

물으려는 객체가 정말로 데이터인 경우도 있다. 로버트 마틴은 <클린 코드>에서 디미터 법칙의 위반 여부는 묻는 대상이 객체인지, 자료 구조인지에 달려 있다고 설명한다. 객체는 내부 구조를 숨겨야 하므로 디미터 법칙을 따르는 것이 좋지만 자료 구조라면 당연히 내부를 노출해야 하므로 디미터 법칙을 적용할 필요가 없다.

- 202p 

 

 

public boolean isSatisfied(RecurringSchedule schedule) {
	if (from.getDayOfWeek() != schedule.getDayOfWeek() || !from.toLocalTime().equals(schedule.getFrom()) || !duration.equals(schedule.getDuration())) { 
    reschedule(schdule); 
    return false; 
    }
    
    return true;
    }
    }

 

isSatisfied 메서드는 Event가 RecurringSchedule의 조건에 부합하는지를 판단한 후 부합할 경우 true를, 부합하지 않을 경우 false를 반환한다. 따라서 isSatisfied 메서드는 개념적으로 쿼리다. 

 

isSatisfied 메서드는 Event가 RecurringSchedule의 조건에 부합하지 않을 경우 Event의 상태를 조건에 부합하도록 변경한다. 따라서 isSatisfied는 실제로는 부수효과를 가지는 명령이다. 

 

-> 명령과 쿼리를 명확하게 구분 ! 

 

 

public boolean isSatisfied(RecurringSchedule schedule) { 
	if (from.getDayOfWeek() != schedule.getDayOfWeek() || !from.toLocalTime().equals(schedule.getFrom()) || !duration.equals(schedule.getDuration())) {
    	return false; 
    }
    
    return true;
   }

수정후의 isSatisfied 메서드는 부수효과를 가지지 않기 때문에 순수한 쿼리가 됐다. 

 

public class Event {
	public booelan isSatisfied(...)
   }

 

if (!event.isSatisfied(schedule)) { 
	event.reschedule(schedule);
}

- 210p 

 

 

참조 투명성이란 "어떤 표현식 e가 있을 때 모든 e를 e의 값으로 바꾸더라도 결과가 달라지지 않는 특성"이라는 점을 기억하라.

- 212p 

 

 

부수효과를 기반으로하는 방식 -> 명령형 프로그래밍  : 상태를 변경시키는 연산들을 적절한 순서대로 나열 

대부분의 객체지향 프로그래밍 언어들은 메시지에 의한 객체의 상태 변경에 집중 -> 명령형 프로그래밍 언어로 분류 

 

최근 들어 주목받고 있는 함수형 프로그래밍은 부수효과가 존재하지 않는 수학적인 함수에 기반한다. 따라서 함수형 프로그래밍에서는 참조 투명성의 장점을 극대화할 수 있으며 명령형 프로그래밍에 비해 프로그램의 실행 결과를 이해하고 예측하기가 더 쉽다. 또한 하드웨어의 발달로 병렬 처리가 중요해진 최근에는 함수형 프로그래밍의 인기가 상승하고 있으며 다양한 객체지향 언어들이 함수형 프로그래밍 패러다임을 접목시키고 있는 추세다.

- 214p