ziglog
객체지향의 사실과 오해 - 1장
January 29, 2022 • ☕️ 4 min read
협력하는 객체들의 공동체
객체지향의 목표는 실세계를 모방하는 것이 아니라 새로운 세계를 창조하는 것이다. 단순히 실세계를 소프트웨어 안으로 옮겨 담는 것이 아니라 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것이다
협력하는 사람들
- 커피 공화국의 아침
- 카페테리어에서 커피를 주문하고 받는 과정에는 손님, 캐시어, 바리스타 사이의 암묵적인 협력 관계가 존재한다
- 커피 주문이라는 협력에 참여하는 모든 사람들은 각자 맡은 바 역할과 책임을 다하고 있다
- 요청과 응답으로 구성된 협력
- 사람들은 문제 해결에 필요한 지식을 알고 있거나 서비스를 제공해줄 수 있는 사람에게 도움을 요청한다
- 요청은 연쇄적으로 발생한다
- 요청을 받은 사람은 주어진 책임을 다하면서 필요한 지식이나 서비스를 제공, 즉 요청에 응답한다
- 우리는 요청과 응답을 통해 다른 사람과 협력하여 문제를 해결한다
- 역할과 책임
- 역할은 협력 안에서 차지하는 책임이나 임무를 의미한다
- 특정한 역할은 특정한 책임을 암시한다
- 사람들은 협력을 위해 특정한 역할을 맡고 역할에 적합한 책임을 수행한다
- 여러 사람이 동일한 역할을 수행할 수 있다
- 역할은 대체 가능성을 의미한다
- 책임을 수행하는 방법은 자율적으로 선택할 수 있다 (다형성)
- 한 사람이 동시에 여러 역할을 수행할 수 있다
역할, 책임, 협력
- 기능을 구현하기 위해 협력하는 객체들
- 사람 - 객체
- 에이전트의 요청 - 메시지
- 에이전트가 요청을 처리하는 방법 - 메서드
- 역할과 책임을 수행하며 협력하는 객체들
- 협력에 참여하는 각 개인은 책임을 수행하기 위해 다른 사람에게 도움을 요청하기도 하며, 이를 통해 연쇄적인 요청과 응답으로 구성되는 협력 관계가 완성된다
- 애플리케이션의 기능은 더 작은 책임으로 분할되고 책임은 적절한 역할을 수행할 수 있는 객체에 의해 수행된다
- 적절한 객체에게 적절한 책임을 할당해야 한다
- 역할은 관련성 높은 책임의 집합이다
협력 속에 사는 객체
-
협력 공동체의 일원으로서 객체는 다음 두 가지 덕목을 갖춰야 한다
- 객체는 충분히 ‘협력적’이어야 한다
- 객체는 다른 객체의 명령에 복종하는 것이 아니라 요청에 응답할 뿐이며, 어떤 방식으로 응답할지는 객체 스스로 판단하고 결정한다
- 객체는 충분히 ‘자율적’이어야 한다
- 객체들은 공동의 목표를 달성하기 위해 협력에 참여하지만 자신의 행동을 스스로 결정하고 책임진다
-
상태와 행동을 함께 지닌 자율적인 객체
- 객체는 협력에 참여하기 위해 어떤 행동을 해야 하고, 그 행동을 하는 데 필요한 상태도 함께 지니고 있다.
- 객체는 객체의 내부와 외부를 명확하게 구분하여 자율성을 갖춘다.
- 객체지향 개발에서는 데이터와 프로세스를 객체라는 하나의 틀 안에 함께 묶어 놓음으로써 객체의 자율성을 보장한다
-
협력과 메시지
- 객체지향의 세계에서는 오직 한 가지 의사소통 수단인 **‘메시지’**를 이용한다
- 객체는 협력을 위해 다른 객체에게 메시지를 전송하고 다른 객체로부터 메시지를 수시한다
-
메서드와 자율성
-
메서드
- 객체가 수신된 메시지를 처리하는 방법
- 어떤 객체에게 메시지를 전송하면 결과적으로 메시지에 대응되는 특정 메서드가 실행된다
- 메시지와 메서드의 분리는 객체들 간의 자율성을 증진시킨다 (객체는 메시지에 응답하기 위해 자신만의 자율적인 방법을 택할 수 있다)
- cf) 캡슐화
-
객체지향의 본질
-
객체를 지향하라
- 클래스는 객체지향의 핵심을 이루는 중심 개념은 아니다
- 지나치게 클래스를 강조하는 관점은 객체의 캡슐화를 저해하고 클래스를 서로 강하게 결합시키는 문제가 있다
- 객체지향 설계를 위해서는 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환해야 한다
→ 객체의 역할, 책임, 협력에 집중하라!
🤓 DISCUSSION
- 리액트에서는?
- 컴포넌트도 객체라고 할 수 있다.
- 인터페이스
- 특정한 객체를 다른 컴포넌트에 전달하는,
props같은 경우도 객체지향에서의 ‘메시지’ - 메시지를 주고 받는 방식이 인터페이스로 정의되어 있다.
- 객체지향에서 인터페이스는 클래스가 구현해야 할 내용을 추상 메서드로 미리 정의해놓은 것과 유사하다.
- 인터페이스로 메서드 이름을 지정해놓고, 그 인터페이스를 확장해서 인터페이스에 지정된 메서드를 오버라이드 해서 쓰는 방식도 사용할 수 있다.
- 특정한 객체를 다른 컴포넌트에 전달하는,
- 컴포넌트, element도 결국 하나의 객체다
🤔 생각해보기
책에서 지적하고 있는대로, ‘객체지향’이라는 것을 단순히 클래스가 찍어내는 인스턴스들의 느낌으로만 이해하고 있었던 것 같다. 유명한 ‘붕어빵 틀’에 사로잡힌 코린이중 하나…
아직 메시지와 메서드가 어떤 차이가 있는 것인지, ‘인터페이스’가 어떻게 메시지와 메서드를 정의하는 것인지 확실하게 와닿지는 않는다. 인터페이스를 단지 컴포넌트에 넘겨주는 props를 사용자에게 알려주기 위해, ‘타입’의 관점에서 사용했던 느낌이 큰 것 같다.
‘객체지향’이라는 관점을 떠나서 ‘객체’를 생각해보았을 때, ‘메서드’와 ‘프로퍼티’로 이루어진 것이 ‘객체’라고 배우기는 쉽다. 그러나 아래 문장은 조금 낯설었다.
객체지향 개발에서는 데이터와 프로세스를 객체라는 하나의 틀 안에 함께 묶어 놓음으로써 객체의 자율성을 보장한다
일반적으로 사용했던 객체의 ‘프로퍼티’가 바로 데이터, ‘메서드’는 프로세스에 해당할 것이다. 데이터와 프로세스가 단순히 하나의 객체로 묶이는 것이 아니라, 그렇게 함으로써 객체의 내부와 외부를 명확하게 구분하여 객체의 자율성을 보장한다는 것은 새롭게 생각해보게 된 내용이었다.
객체의 역할, 책임, 협력에 집중하여 객체 각각이 아니라 전체의 큰 그림에서 객체들 간에 어떻게 메시지를 주고받는지에 집중하여 객체지향 프로그래밍을 익혀나가야겠다.
Relative Posts:
지그의 개발 블로그
