[객체지향의 사실과 오해] 2. 이상한 나라의 객체

이번 장에서 설명하는 내용

객체는 상태, 행동, 식별자를 가지고 있다.

행동이 상태를 결정한다.

---

 

 

 

1. 객체, 이상한 나라와 소프트웨어 나라

---

이상한 나라의 앨리스에서 앨리스는 음료를 마시면 키가 작아지고, 케이크를 먹으면 키가 커지게 된다.

여기서 앨리스의 키를 변화시키는 것은 앨리스의 행동이다.

즉, 앨리스의 상태를 결정하는 것은 행동이지만, 행동의 결과를 결정하는 것은 상태이다.

 

행동간의 순서도 중요하다. 만약 앨리스가 정원에 있는 문을 통과해야 하는데, 지금은 키가 커서 통과를 할 수 없는 상황이다.

앨리스가 문을 통과하려면 먼저 음료를 마시고 문을 통과해야한다. 반대로 문을 통과하고 음료를 마신다면 문을 통과하지 못한 상황에서 음료를 마셔 키가 작아지기만 한다.  따라서 행동의 순서가 결과에 영향을 미친다.

 

이 내용은 현실 세계뿐만 아니라 소프트웨어에서도 비슷하게 작동한다.

---

 

 

2. 상태, 행동, 식별자

---

모든 사물은 객체이고, 객체는 상태(state), 행동(behavior), 식별자(identity)를 가진 실체로 볼 수 있다.

 

[상태]

모든 일의 공통점은 어떤 행동의 결과는 과거에 어떤 행동들이 일어났었느냐에 의존하는 것이다.

키가 큰 앨리스가 정원에 있는 문을 통과를 한다는 결과를 내기 위해서는 음료를 마셔야하는 행동이 있어야 한다.

하지만 현실이든, 코딩에서든 이전에 했던 모든 행동을 기록하는 것은 힘든 일이다.

그래서 상태를 가지게 해서 과거의 모든 행동을 알지 못해도 결과적으로는 어떻게 됐는지 알 수 있는 값을 추가했다.

 

앨리스가 음료를 들고 있는 상태인지 확인하려면 음료라는 객체가 앨리스와 연결(link)되어 있는지 확인해야 한다.

모든 객체의 상태는 단순한 값과 객체의 조합으로 표현할 수 있다.

객체의 상태를 구성하는 모든 특징을 프로퍼티(property)라고 부른다. 프로퍼티는 고정되어 있기 때문에 정적이다.

하지만 프로퍼티 값(property value)는 계속 값이 바뀔 수 있기 떄문에 동적이다.

왜 정적인지, 동적인지는 아래 내용을 보면 쉽게 이해할 수 있다.

 

프로퍼티 ↔ 프로퍼티 값

=========

앨리스의 키 ↔ 앨리스 키에 대한 값

앨리스의 위치 ↔ 앨리스 위치에 대한 값

음료수 ↔ 음료수의 식별자

---

[행동]

객체의 상태는 저절로 바뀌지 않고, 객체의 자발적인 행동으로 바꿀 수 있다.

- 앨리스가 음료를 마신다 → 키가 작아진다.

- 앨리스가 케이크를 먹는다 → 키가 커진다.

 

객체의 행동은 객체의 상태를 변경하지만, 행동의 결과는 객체의 상태에 의존적이다.

- 음료를 마신 앨리스는 음료를 마시기 전의 앨리스보다 키가 작아야 한다.

- 케이크를 먹은 앨리스는 케이크를 먹기 전의 앨리스보다 키가 커야 한다.

---

[협력과 상태 캡슐화]

객체가 다른 객체와 협력하는 행동은 요청과 응답을 통해할 수 있다. (1장 참조)

그리고 모든 객체는 자신의 상태를 스스로 관리할 수 있어야 한다. 앨리스의 키와 위치를 바꾸는 것은 앨리스 자기 자신이어야 하고, 음료수의 양을 조절하는 것은 음료수 자기자신이어야 한다. (코드에서 setter를 생각하면 된다.)

 

만약 앨리스가 음료수를 마신다면 앨리스 객체와 음료수 객체는 서로 협력해야 한다. 이때 앨리스가 음료수에게 drink라는 메서드를 보내면 음료수는 자신의 양을 줄여야 한다. 이때 앨리스는 drink라는 메서드만 보낼 줄 알지, 음료수가 음료수의 양을 조절했는지 전혀 알지 못한다.

즉 다른 객체가 자신의 상태 변화에 알 수 없게 만드는 것이 캡슐화이다.

 

캡슐화를 하면 좋은 점은 다른 객체들에게 결과만 보여주고, 내부에서는 자기 맘대로 처리하면 되기 때문에 자율성이 높아진다.

이러면 객체들끼리 자율성을 높여 협력을 단순하고 유연하게 만들어진다.

---

[식별자]

객체가 식별 가능하다는 것은 객체를 서로 구별할 수 있는 특정 프로퍼티가 존재한다는 것이고, 이것을 식별자라고 부른다.

이 말은 단순 값은 식별자를 가지지 않는다는 것이고, 이것은 시스템을 설계할 때 객체와 단순 값의 차이점을 명확하게 구분하고 명시적으로 표현하는 것이 좋다.

---

 

 

3. 소프트웨어에서의 객체

---

개발자의 주요 업무는 객체의 상태를 조회하고, 객체의 상태를 변경하는 것이다. 이때 객체의 상태를 조회하는 것을 쿼리(query)라고 부르고, 객체의 상태를 변경하는 작업을 명령(command)라고 부른다. 우리가 자주 사용하는 어노테이션으로 비유를 하자면 쿼리는 getter, 명령은 setter로 이해할 수 있다.

 

초보자들이 객체지향에서 가장 쉽게 빠지는 함정은 객체에게 필요한 상태가 무엇인지 결정하고, 그 상태에 필요한 행동을 결정하는 것이다. 하지만 이런 방법은 캡슐화 저하, 협력 저하, 재사용성 저하로 설계에 나쁜 영향을 끼치게 된다.

협력에 참여하는 객체들은 상태보다 행동에 집중해야 한다. 설계를 할 때에는 필요한 행동이 무엇인지 먼저 생각하고, 이후 행동에 필요한 정보가 무엇인지 생각해보면서 상태를 결정하는 것이다.

---