[스터디: 객체지향의 사실과 오해] 자율적인 객체

5. 책임과 메시지

자율적인 객체

자율적이라는 말은 자기 스스로의 원칙에 따라 일을 하거나 절제하는 성질이나 특성을 뜻한다.

 

이를 객체에 대입해보면 자신의 행동을 스스로 결정할 수 있는 객체를 자율적인 객체라고 할 수 있을 것이다.

 

그렇다면 어떻게 객체를 자율적으로 만들 수 있을까?

1장에서부터 나온 커피 주문 이야기를 예로 들어서 정리하였다.

 

캐시어는 커피를 제조하라는 문장을 아래와 같이 바리스타에게 전달할 수 있다.

1. "커피를 만들어라"
2. "루왁 원두와 커피머신을 사용해서 커피를 만들어라"

두 메시지 모두 커피를 만드는 바리스타의 책임을 수행하도록 하는 메시지이다.

 

1번의 메시지를 받은 바리스타는 어떠한 원두를 사용할지 선택할 수 있고, 커피머신의 사용 여부도 선택할 수 있다.

하지만 2번의 메시지를 전달받은 바리스타는 반드시 루왁 원두와 커피머신 기계를 사용해야 한다.

 

즉, 객체 스스로 책임 수행의 방식을 선택할 수 없고, 외부에서 정해주었기 때문에 객체의 자율성이 떨어진다.

 

프로그래밍의 세계에 대입해 본다면, 객체는 메서드를 통해서 메시지를 주고받을 것이다.

2번과 같은 메시지를 전달하기 위해서는 아래와 같이 메서드 인자를 추가해줘야 한다.

barista.makeCoffee("루왁", "커피머신");

클린코드 책에는 메서드의 인자는 2개까지만 허용하고 3개 이상부터는 가급적 쓰지 않는것이 좋다라고 강조한다.

클린코드 책에서는 이 말을 통해서 메서드를 분리해야한다 라는 점을 강조하고 있지만, 이 책에서는 객체의 자율성 보장을 위해서도 메서드의 인자를 줄여야 한다라는 것을 말하는 것으로 느껴졌다.

 

 

 

그러면 무조건 자율적인것이 좋은 것일까?

3. "만들어라"

만약 위와 같이 메시지를 전달하였다면, 바리스타는 커피를 만들어라는 건지, 쉐이크를 만들어라는 건지 알 수 없다.

이렇게 추상적으로 메시지를 전달하면 객체는 자유로워지지만, 메시지 송신자가 원하는 결과와 다른 결과를 받을 수 있다.

 

따라서, 적당히 추상적이면서, 적당히 구체적인 메시지를 선택해야한다.

💡 메시지를 선택할 때는 "어떻게" 가 아닌 "무엇을"에 집중하여 메시지를 만든다.

2번 메시지는 커피를 제조하는 방법까지 외부에서 정해주었기 때문에 바리스타 객체의 자율성이 침해된다.

3번 메시지는 무엇을에 해당하는 목적어가 빠져있어 구체적인 책임을 알기 어렵다.

 

"어떻게"가 아닌 "무엇을"에 초점을 맞추어 1번 메시지를 전달한다면, 객체의 자율성을 보장함과 동시에 적절한 책임을 할당할 수 있다.

 

또한 이러한 방식은 명확한 메서드명을 짓는 것에도 도움을 준다고 느꼈다.

외부에서 객체 스스로 정해야 하는 어떻게 부분까지 정해준다면, 메서드의 이름이 길어질 수 밖에 없다.

2번 메시지를 전달하기 위해서는 아래와 같은 메서드를 지어야 할 것이다.

barisata.makeCoffeeUsingAndWith("루왁", "커피머신");

하지만 1번 메시지와 같이 어떻게에 해당하는 부분은 객체의 결정에 맡긴다면, 아래와 같은 명확한 메서드명을 지을 수 있을 것이다.

barista.makeCoffee();

 

이렇게 메시지를 보내면 객체 내부에서 어떻게 수행할지를 스스로 결정할 수 있다.

 

즉, 동일한 메시지를 수신받더라도 그 수행 방식을 다르게 할 수 있다는 것이다.

 

결국, 이를 통해 객체지향의 장점인 대체 가능성과 재사용성을 높이는데 기여한다.

 

---

인터페이스

이전까지는 책에서 인터페이스라는 말을 사용하지 않았지만, 이번 장에서 드디어 인터페이스를 소개하며 그동안 혼자 정리했던 생각들과 비교할 수 있었다.

 

인터페이스는 외부에 공개되는 창이라고 생각하면 이해하기 편하다.

인터페이스를 외부에 공개함으로써, 외부에서는 인터페이스를 통해 객체와 협력하고, 객체는 인터페이스 뒤에 숨어서 자율성을 보장받을 수 있다.

 

인터페이스는 아래와 같은 특징을 지닌다.

• 인터페이스의 사용법만 알면 내부 구조나 동작 방식을 몰라도 쉽게 사용할 수 있다.
• 내부 구조나 동작 방식을 변경하더라도, 외부 사용자는 인터페이스만 변경하지 않으면 상관없다.

1장에서부터 소개한 변경에 대처하기 위한 예방책으로 인터페이스가 사용될 수 있다.

커피 주문 사례에 적용시킨 내용은 1장에서 정리하여서 이를 참고하면 더 쉽게 이해할 수 있을 것 같다.

https://gyuwon-tech.tistory.com/23

[스터디: 객체지향의 사실과 오해] 역할 중심 설계와 캡슐화

 

책에서는 맷 와이스펠드가 제안한 객체지향적 사고 방식의 세가지 원칙을 소개한다.

1. 추상화된 인터페이스
2. 최소 인터페이스
3. 인터페이스와 구현의 차이가 있다를 인식

 

1. 앞서 설명한 내용으로, 추상화된 인터페이스를 설계함으로써 객체의 자율성을 보장할 수 있다.
2. 최소 인터페이스를 사용하여 최소한의 정보만 외부로 노출시킴으로써, 외부 로직을 수정하는 경우를 줄일 수 있다.
3. 객체의 외부와 내부를 정확히 구분해야한다.

+) 객체의 내부와 외부는 무엇일까?

객체의 내부에는 객체가 스스로 결정하는 것으로 상태와 메서드의 구현내용이 이에 속한다.
객체의 외부는 외부에 공개되는 객체의 정보로, 공용인터페이스를 뜻한다.

 

객체의 외부와 내부를 구별하여, 객체의 내부를 변경하더라도 객체의 외부는 변경되지 않도록 설계하는 것이 중요하다.

 

이 내용은 객체의 캡슐화에 관련된 내용이다.

 

처음 자바를 배울때는 캡슐화란 단순히 필드를 private으로 선언하여 외부에서 접근할 수 없도록 하는것이라고 배웠다.

틀린 설명은 아니지만, 단순히 필드만을 숨긴다는 설명은 캡슐화의 일부만 설명한 것이라고 생각한다.

 

필드와 같은 상태 뿐만 객체의 구현 자체를 외부에 숨기고, 객체의 인터페이스만 노출하여 객체의 자율성을 보장하도록 해주는 것이 캡슐화의 정확한 정의라는 것을 책을 통해 다시 배울 수 있었다.

캡슐화란 객체의 유연함을 위하여
객체의 구현을 숨기고 최소한의 정보만을 노출하는 것이다.

 

 

---

느낀점

책을 읽으며 클래스와 캡슐화와 같은 이미 알고 있던 개념들을 새로 정의하는 경험을 하고 있다.

클래스: 
이전: 객체를 찍어내는 틀
현재: 추상화를 구현하는 도구

캡슐화:
이전: 객체의 필드를 외부에서 접근하지 못하도록 접근제어자를 설정하는 것
현재: 객체의 유연함과 대체가능성을 높이기 위해 최소한의 객체 정보만 외부로 노출하는 것

 

이전처럼 단순히 정의만 외우는 것보다, 역할과 함께 정의하는 것이 개념에 대해 더 깊게 고민하고, 이해할 수 있는 것 같다.

앞으로 새로운 내용을 학습할 때도, 이 방식을 적용하여 내용을 더 깊게 공부할 것이다.

 

---

아쉬운점

책에서는 협력, 역할, 책임 중심의 설계를 했을 때의 장점을 지나치게 강조한다.

중요한 내용이긴 하지만, 너무 많이 중복되기 때문에 읽으면서 지루함이 느껴지기도 하였다.

 

협력, 역할, 책임 중심의 장점을 지나치게 강조하기 보다는, 실제 프로그램에서 이 개념을 어떻게 활용해서 설계할 수 있는지를 알려주었으면 독자가 배운 개념이 어떻게 적용될 수 있는지 대략적으로 배울 수 있어서 더 좋았을 것 같다는 아쉬움이 남는다.