[오브젝트] Intro + ch01 객체, 설계

기억하고 싶은 부분

• 저자가 말하는 객체지향으로 향하는 세 걸음
  1. 클래스가 아니라 객체를 바라보는 것에서부터 시작
  2. 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 존재로 바라보는 것
  3. 협력에 참여하는 객체들에게 얼마나 적절한 역할과 책임을 부여할 수 있느냐에 달려 있다.
• 책에서 제시하는 방법이 객체지향을 구현하기 위한 유일한 방법은 아니다.
• 프로그래밍 패러다임이 중요한 이유
  • 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다.
• 실무 vs 이론 (로버트 L. 글래스 <소프트웨어 크리에이티비디 2.0>)
  • 실무 방식을 선호
  • 이유는 초기 단계에서는 실무를 관찰한 결과를 바탕으로 이론을 정립하는 것이 최선
  • 컴퓨터 공학 분야는 역사가 다른 분야에 비해 상대적으로 짧다 그러므로 이론보다 실무가 더 앞선다
  • 이론보다 실무가 앞서는 분야
    • 설계, 유지보수
• 의존성은 변경에 대한 영향을 암시한다
• 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼 있다.
• 그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.
• 객체 사이의 의존성이 과한 경우 결합도(coupling)가 높다고 한다
• 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다
• 소프트웨어 모듈 세 가지 목적(from 로버트 마틴)
  1. 실행 중에 제대로 동작하는 것
  2. 변경을 위해 존재한다
  3. 코드를 읽는 사람과 의사소통하는 것
• 객체를 인터페이스와 구현으로 나누고 인터페이스만 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.
• 핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것
• 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohension)가 높다고 한다.
• 의존성의 추가는 높은 결합도를 의미하고, 높은 결합도는 변경하기 어려운 설계를 의미한다.
• 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.
• 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 설계는 트레이드오프의 산물이다.
• 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지를 결정하는 과정에서 나온다.
• 변경 가능한 코드란 이해하기 쉬운 코드다.
• 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계다
• 데이터와 프로세스를 하나의 덩어리로 모으는 것은 훌륭한 객체지향 설계로 가는 첫걸음일 뿐이다. 진정한 객체지향 설계로 나아가는 길은 협력하는 객체들 사이의 의존성을 적절하게 조절함으로써 변경에 용이한 설계를 만드는 것이다.

티켓 판매 애플리케이션 예제

초기버젼 version 00

로직

• 관람객은 가방을 가지고 있고, 가방에는 소지품(초대장, 티켓, 현금)이 있다
• 이벤트 당첨자는 초대장을 받아서 극장 입장 가능
• 관람객이 이벤트 당첨자라면 티켓으로 교환 후 입장
• 그렇지 않다면 티켓 판매 이후 입장

문제점

• 관람객 입장에서 소극장이라는 제 3자가 초대장을 확인하기 위해 가방을 마음대로 열어본다.
• 판매원 입장에서 소극장이 판매원 허락도 없이 매표소에 보관 중인 티켓과 현금에 마음대로 접근할 수 있다.
• 코드를 이해하기 위해서는 여러 가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다는 점
• 변경에 취약하다.
  • 판매원이 매표소에서만 티켓을 파는게 아니라 밖에서 판다면?
  • 관람객이 가방을 가지고 있지 않다면?
  • 관람객이 현금이 아니라 카드로 구매하고 한다면?

해결방법

• 객체 사이의 의존성이 문제이므로 필요한 최소한의 의존성만 유지하고 불필요한 의존성은 제거한다
  • Theater가 관람객의 가방에 직접 접근하는 것이 아니라 관람객과 판매원이 스스로 문제를 해결하게 한다.
  • Thread가 Audience와 TicketSeller에 관해 세세한 부분까지 알지 못하게 정보를 차단한다.(캡슐화)
• 관람객과 판매원을 자율적인 존재로 만든다.

version 01

로직

• 관람객은 자신의 가방에 초대장이 들어있는지 스스로 확인한다. 외부의 제 3자가 자신의 가방을 열어보도록 허용하지 않는다.
• 외부에서 ticketOffice에 대한 직접 접근을 막는다. 판매원만이 접근 가능하게 한다.
• Theater는 오직 TicketSeller의 인터페이스에만 의존한다.

소감

• 패러다임의 탄생 배경과 패러다임에 대해 소개하면서 자연스럽게 프로그래밍 언어의 패러다임으로 넘어가는 전개가 인상 깊었습니다. 또한 프로그래밍에서의 패러다임은 기존의 패러다임과 다르게 서로 다른 패러다임이 공존 가능하다(e.g) 절차지향 && 객체지향)는 설명도 차이점을 같이 알려주어서 좋았습니다.
• 실제 예시를 깔끔한 소스코드와 함께 보여주어서 구현한다면 이렇게 할 수 있구나 느낄 수 있었고 보기에 좋아보였던 코드의 문제점과 어떻게 수정하면 될지를 과정과 상세한 설명을 통해 알려주어서 이해가 좀 더 잘되었습니다.
• 처음에 가방 예제의 경우 가방을 안가져오는 경우도 있지 않을까 했는데 관람객이 소지하고 있는 데이터 모음에 대한 추상화라고 생각하니 납득되기도 하였고 관람객과 가방을 분리하는 편이 관람객에게만 모든 데이터를 속하게 하는 것보다 낫겠다는 생각이 들었습니다.
• 절차지향 프로그래밍의 경우 데이터 변경으로 인한 영향을 지역적으로 고립시키기 어렵다는 부분에서 다른 로직에 의도치 않은 영향을 주기 쉽겠다는 생각이 들었고 혹시 반례는 없는가와 절차지향이 더 유리할 수 있는 부분은 무엇일까와 객체지향 & 절차지향을 같이 쓰면 좋을 예시는 무엇일까라는 생각이 들었습니다.
• 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계 라는 부분에서 적절한의 기준은 어떻게 잡을 수 있는가 의문이 들었습니다.
• 지은이의 말. 들어가면 다 포함하면 약 40페이지 쯔음이지만 읽고 있던 글 옮겨적는 것이었음에도 생각보다 꽤 긴 시간이 들었네요. 그럼에도 궁금하던 부분들이 잘 설명되고 코드가 있어서 이해하기 좋아 만족스러웠습니다.

Ref

• https://github.com/eternity-oop/object

 

P.S 노마드코드 북클럽 챌린지에서 사용하는 글 서식을 가져와 후기 남겼습니다