1장 객체, 설계

들어가며

글래스는 스포트웨어 크리에이티비티2.0 에서 이론보다 실무가 먼저라고 한다. 다른 분야에 비해 역사가 짧기 때문이다.
특히 소프트웨어 설계와 소프트웨어 유지보수가 실무가 앞서있다.

소프트웨어 생명 주기 동안 유지보수가 차지하는 비중을 감안할 때 이론은 매우 실망스럽다. 결국 실무에 초점을 맞추는게 중요하다.

추상적인 개념과 이론은 훌륭한 코드를 작성하는데 필요한 도구이다.

01 티켓 판매 애플리케이션 구현하기

1장의 첫 구현의 로직은 간단하고 예상대로 동작한다. 하지만 몇가지 문제점이 있다.

02 무엇이 문제인가

로버트 마틴은 클린 소프트웨어에서 소프트웨어 모듈이 가져야하는 3가지 기능을 설명한다

1. 제대로 동작해야한다
2. 변경을 위해 존재해야한다 어렵다면 개선해야한다
3. 코드를 읽는 사람과 의사소통 하는것이다. 특별한 훈련이 없어도 쉽게 읽고 이해할 수있어야한다

예상을 빗나가는 코드

• 기존 코드는 관람객과 판매원이 소극장의 통제를 받는 수동적 존재이다.

• 소극장이 관람객의 가방을 열어보고 티켓과 현금을 마음대로 접근한다.

• 이해 가능한 코드란 그 동작이 우리의 에상에서 벗어나지 않는 코드이다.

  • 하지만 현재의 코드는 우리의 상식과 다르므로 코드를 읽는 사람과 의사소통 하지 못한다

• 또한 코드이해를 위해 세부적인 내용을 한꺼번에 기억해야한다.

• 보다 심각한 문제는?

변경에 취약한 코드

• 지나치게 세부적인 사실에 의존해서 동작한다.
• 이것은 의존성(dependency)관련 문제이다.
  • 의존성이라는 말에는 어떤 객체가 변경될 때, 그 객체가 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어있다.
  • OOP 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.
  • 이경우 최소한의 의존성 유지하고, 불필요한 의존성 제거이다
  • 과한 경우 결합도가 높다고 한다.

03 설계 개선하기

• Theater 가 Audience 와 TicketSeller 에 관해 세부적인 부분을 알지 못하게 차단한다
  • 스스로 다루게 하는 '자율적인 존재'로 만든다

자율성을 높이자

• 이렇게 개념이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 '캡슐화' 라고 부른다
  • 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것
• 이렇게 되면 Theater 는 오직 TicketSeller 의 인터페이스에만 의존한다.
  • 인터페이스만 공개하는것은 객체 사이 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위한 가장 기본적인 설계이다

무엇이 개선됐는가

• 기존에는 상세한 내부 구현까지 알고있어야했다. 그 결과 사소한 변경에도 직접 영향을 받았다.
• 수정 후에는 내부에 직접 접근하지 않고, 직접 판매하게 했다.
  • 객체의 자율성을 높이는 방향으로 설계를 개선했다

캡슐화와 응집도

• 핵심은 객체를 캡슐화 하고 객체간 상호작용 하도록 만드는 것이다
• 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야한다 (* 정보전문가)

절차지향과 객체지향

절차적 프로그래밍

• 기존 코드는 Theater 의 enter 메서드 안에서 구현했다
  • enter 메서드는 Process 이고, 그 외 객체는 Data이다
  • 이 방식을 절차적 프로그래밍이라 한다
• 하지만 이 방식은 우리의 직관에서 위배된다
  • 수동적인 존재에 불과함
• 또한 데이터 변경으로 인한 영향을 지역적으로 고립시키기 어렵다
  • 그 결과 변경은 버그를 부르고, 버그에 대한 두려움은 코드를 변경하기 어렵게 만든다.
• 즉 변경하기 쉬운 설계는 한번에 하나의 클래스만 변경할 수있는 설계이다.
  • 그러나 절차적 프로그래밍은 모든 데이터에 의존해야한다

객체지향 프로그래밍

• 해결방법은 자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 각 객체로 이동하는 것이다

• 결국 OOP의 핵심은 캡슐화를 통해 의존성을 관리하여 결합도를 낮춘다. 즉 객체는 자신의 문제는 스스로 처리하면은 우리의 예상을 만족시켜 이해하기 쉽다. 그 결과 객체 내부의 변경이 외부에 파급되지 않도록 제어할수 있기 때문에 변경하기 수월하다

책임의 이동

• 두 방식의 근본적 차이는 책임의 이동이다

• 절차지향 프로그래밍은 모든 책임이 Theater에 집중되어있다. (독재자)

• 객체지향 프로그래밍은 모든 책임이 독재자가 없고 각 객체에 책임이 적절히 분배된다. (자율적 / 민주적?)

• 즉 데이터와 데이터를 사용하는 프로세스가 별도의 객체 -> 절차적 프로그래밍

• 데이터와 데이터를 사용하는 프로세스가 동일 객체 -> 객체지향 프로그래밍

• 결국에는 객체가 어떤 데이터를 가지느냐 보다, 어떤 책임을 할당하게 할것이냐에 초점이 필요하다

• 하지만 설계를 어렵게 하는것은 의존성이다. 해결방법은 결합도를 낮추는것이다. 이를 위해 캡슐화를 하고 자율성을 높여 응집도를 높인다.

그래 거짓말이다!

• 그런데 Theater 등은 생물처럼 다룬다.
• 현실세계에서는 수동적인 존재라도, 객체지향 세계에 오면 능동적이고 자율적인 존재이다
• 이른바 의인화(anthropomorphism)이다

04 객체지향 설계

설계가 왜 필요한가?

• 설계는 코드작성의 일부이며 코드를 작성하지 않고서는 작성할 수 없다.
• 언제든지 변경되는 요구사항에 쉽게 변경하고, 버그로서 코드 수정의지를 꺾는것을 막을 수있다.

객체지향 설계

• 우리가 진정으로 원하는것은 변경에 유연하게 대응할 수있는 코드이다.

  • 이것은 과거 다른 방법보다 안정감을 준다
  • 그 방법은 이해하기 쉬운 코드이다.

• 결국... 세상에 엮인것이 많은 사람일수록 변하기 어려운 것 처럼, 객체가 생성되는 주변 환경에 강하게 결합될수록 변경하기 어려워진다.