TL;DR

  • 티켓 판매 시스템이라는 간단한 도메인을 예로 들어 채그이 전체적인 주제를 함축해서 전달합니다.

intro

  • 소프트웨어 개발에서 실무가 이론보다 앞서 있는 대표적인 분야로 ‘소프트웨어 설계’와 ‘소프트웨어 유지보수’를 들 수 있습니다.
    • 대부분 사람들은 이론이 먼저 정립된 후에 실무가 그 뒤를 따라 발전한다고 생각합니다. 로버트 L. 글래스는 그 반대라고 주장합니다. 글래스에 따르면 어떤 분야를 막론하고 이론을 정립할 수 없는 초기에는 실무가 먼저 급속한 발전을 이룬다고 합니다. 실무가 어느 정도 발전하고 난 다음에야 비로소 실무의 실용성을 입증할 수 있는 이론이 서서히 그 모습을 갖춰가기 시작하고, 해당 분야가 충분히 성숙해지는 시점에 이르러서야 실무를 추월하게 된다는 것입니다. 글래스의 결론을 한마디로 요약하면 이론보다 실무가 먼저라는 것입니다. 따라서 어떤 분야든 초기 단계에서는 아무것도 없는 상태에서 이론을 정립하기보다는 실무를 관찰한 결과를 바탕으로 이론을 정립하는 것이 최선입니다.
  • 소프트웨어 설계와 유지보수에 중점을 두려면 이론이 아닌 실무에 초점을 맞추는 것이 효과적입니다.
    • 실무는 훌륭한 소프트웨어를 설계하기 위해 필요한 다양한 기법과 도구를 초기부터 성공적으로 적용하고 발전시켜 왔습니다. 반면에 훌륭한 설계에 관한 최초의 이론은 1970년대가 돼서야 비로소 세상에 모습을 드러냈습니다. 대부분의 설계 원칙과 개념 역시 이론에서 출발해서 실무에 스며들었다기보다는 실무에서 반복적으로 적용되던 기법들을 이론화 된 것들이 대부분입니다. 소프트웨어의 규모가 커지면 커질수록 소프트웨어 설계 분야에서 이론이 실무를 추월할 가능성은 희박해 보입니다.
    • 소프트웨어 유지보수의 경우에는 그 격차가 더 심합니다. 실무에서는 다양한 규모의 소프트웨어를 성공적으로 유지보수하고 있지만 소프트웨어 유지보수와 관련된 효과적인 이론이 발표된 적은 거의 없습니다. 심지어 이론은 소프트웨어 유지보수에 전혀 관심이 없는 것처럼 보이기까지 합니다. 소프트웨어 생명주기 동안 유지보수가 차지하는 비중을 감안해 볼 때 현재 상황은 매우 실망스러운 수준이라고 할 수 있습니다.
  • 설계에 관해 설명할 때 가장 유용한 도구는 이론으로 덕지덕지 치장된 개념과 용어가 아니라 코드 그 자체입니다.
  • 프로그래밍을 통해 개념과 이론을 배우는 것이 개념과 이론을 통해 프로그래밍을 배우는 것보다 더 훌륭한 학습 방법이라고 생각합니다. 개념은 지루하고 이론은 따분합니다. 개발자는 구체적인 코드를 만지면 더럽힐 때 가장 많은 것을 얻어가는 존재입니다.

01. 티켓 판매 애플리케이션 구현하기(step1)

02. 무엇이 문제인가

  • 모든 소프트웨어 모듈에는 세 가지 목적이 있습니다.
    • 첫 번째 목적은 실행 중에 제대로 동작하는 것입니다. 이것은 모듈의 존재 이유라고 할 수 있습니다.
    • 두 번째 목적은 변경을 위해 존재하는 것입니다. 대부분 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경할 수 있어야 합니다. 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 합니다.
    • 모듈의 세 번째 목적은 코드를 읽는 사람과 의사소통하는 것입니다. 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 합니다. 읽는 사람과 의사소통할 수 없는 모듈은 개선해야 합니다.
  • 마틴에 따르면 모든 모듈은 제대로 실행돼야 하고, 변경이 쉬워야 하며, 이해하기 쉬워야 합니다.

예상을 빗나가는 코드

  • 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이 문제입니다. 이해 가능한 코드란 그 동작이 우리의 예상에서 크게 벗어나지 않는 코드입니다. 또한 코드를 이해하기 위해서는 여러 가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다는 점입니다.
  • 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루기 때문에 코드를 작성하는 사람뿐만 아니라 코드를 읽고 이해하는 사람 모두에게 부담을 줍니다.
  • 하지만 가장 심각한 문제는 하나의 클래스를 바꿀 때 다른 클래스도 함께 바꿔야 합니다.

변경에 취약한 코드

  • 더 큰 문제는 변경에 취약하는 것입니다.
  • 세부적인 사실 중 한 가지라도 바뀌면 해당 클래스뿐만 아니라 이 클래스에 존재하는 모든 클래스도 함께 변경해야 합니다. 이 처럼 다른 클래스가 내부에 대해 더 많이 알면 알수록 클래스의 변경이 어려워집니다.
  • 객체 사이의 의존성(dependency)과 관련된 문제입니다. 문제는 의존성이 변경과 관련돼 있다는 점입니다. 의존성은 변경에 대한 영향을 암시합니다. 의존성이라는 말 속에는 어떤 객체가 변경될 대 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼 있습니다.
  • 그렇다고 해서 객체 사이의 의존성을 없애는 것이 정답은 아닙니다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것입니다. 따라서 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것입니다.
  • 객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)가 높다고 말합니다. 반대로 객체들이 합리적인 수준으로 의존할 때는 결합도가 낮다고 말합니다.
  • 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있습니다. 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워집니다. 따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 쉬운 설계를 만드는 것이어야 합니다.

03. 설계 개선하기

  • 01의 코드는 기능은 제대로 수행하지만 이해하기 어렵고 변경하기가 쉽지 않습니다. 변경과 의사소통이라는 문제는 서로 엮여 있습니다. 의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워진 것입니다.
  • 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 됩니다.
  • 각 클래스를 자율적인 존재로 만들면 됩니다.

자율성을 높이자(step2)

  • 클래스가 자율적인 존재이도록 만듭니다.
  • 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화(encapsulation)라고 부릅니다.
  • 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것입니다.
  • 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 됩니다. 오직 인터페이스(interface)에만 의존합니다. 내부에 인스턴스를 포함하고 있다는 사실은 구현(implementation의 영역에 속합니다.
  • 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙입니다.

무엇이 개선됐는가(step3)

  • 우리의 예상과 정확하게 일치하게 되었습니다. 따라서 코드를 읽는 사람과의 의사소통이라는 관점에서 확실히 개선될 수 있습니다.
  • 더 중요한 점은 특정 클래스를 변경하더라도 다른 클래스를 함께 변경할 필요가 없어졌습니다. 따라서 변경 용이성의 측면에서도 확실히 개선될 수 있습니다.

어떻게 한 것인가

  • 자기 자신의 문제를 스스로 해결하도록 코드를 변경한 것입니다.
  • 우리는 우리의 직관을 따랐고 그 결과로 코드는 변경이 쉽고 이해할 수 있도록 수정할 수 있습니다.
  • 객체의 자율성을 높이는 방향으로 설계를 개선해야 합니다. 그 결과, 이해하기 쉽고 유연한 설계를 얻을 수 있습니다.

캡슐화와 응집도

  • 핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것입니다.
  • 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohesion)가 높다고 말합니다. 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더러 응집도를 높일 수 있습니다.
  • 객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 합니다. 자신이 소유하고 있지 않은 데이터를 이용해 작업을 처리하는 객체에게 어떻게 연관성 높은 작업들을 할당하려면 객체는 자신의 데이터를 스스로 처리하는 자율적인 존재여야 합니다. 그것이 응집도를 높이는 첫걸음입니다.
  • 외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길입니다.

절차지향과 객체지향

절차지향

  • step1처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural programming)이라고 부릅니다. 모든 처리가 하나의 클래스 안에 위치하고 나머지 클래스는 단지 데이터의 역할만 수행합니다. 일반적으로 절차적 프로그래밍은 우리의 직관에 위배 됩니다. 절차적 프로그래밍의 세상은 예상을 너무나도 쉽게 벗어나기 때문에 코드를 읽는 사람과 원활하게 의사소통하지 못합니다. 더 큰 문제는 절차적 프로그래밍의 세상에서는 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵 습니다. 절차적 프로그래밍의 세상은 변경하기 어려운 코드를 양산하는 경향이 있습니다.
  • 변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계입니다. 절차적 프로그래밍은 프로세스가 필요하 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약할 수밖에 없습니다.

객체지향

  • 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 이동시켜야 합니다.
    • 프로세스가 동일한 모듈 내부의 위치 하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented Programming이라고 부릅니다.
    • 또 다른 의존성이 추가되지만 적절한 트레이드오프의 결과로 볼 수 있습니다.
  • 의존성은 적절히 통제되고 있으며 하나의 변경으로 인한 여파가 여러 클래스로 전파되는 것을 효율적으로 억제합니다.
  • 훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것입니다. 일반적으로 절차지향보다 변경이 좀 더 유연하다고 말하는 이유가 바로 이것입니다.
  • 객체지향 코드는 자신의 문제를 스스로 처리해야 한다는 우리의 예상을 만족하게 해주기 때문에 이해하기 쉽고, 객체 내부의 변경이 객체 외부의 파급되지 않도록 제어 할 수 있으므로 변경하기가 수월합니다.

책임의 이동

  • 두 방식의 차이점을 가장 쉽게 이해할 수 있는 방법은 기능을 처리하는 방법을 살펴보는 것입니다. 두 방식 사이에 근본적인 차이를 만드는 것은 책임의 이동(shift of responsibility)입니다.
    • 절차적 프로그래밍 방식은 책임이 하나에 집중되어 있습니다.
    • 객체지향 설계에서는 하나의 기능을 완성은 데 필요한 책임이 여러 객체에 걸쳐 분산돼 있습니다. 하나에 몰려 있던 책임이 개별 객체로 이동하는 것을 책임의 이동이라고 합니다.
  • 객체지향 설계에서는 독재자가 존재하지 않고 각 객체에 책임이 적절하게 분배됩니다. 따라서 각 객체는 자신을 스스로 책임집니다. 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로써 완성됩니다.
  • 객체지향 프로그래밍을 흔히 데이터와 프로세스를 하나의 단위로 통합해 놓는 방식으로 표현하기도 합니다. 비록 이 관점이 객체지향을 구현 관점에서만 바라본 지극히 편협한 시각인 것은 맞지만, 객체지향에 갓 입문한 사람들에게 어느 정도 도움이 되는 실용적인 조언인 것 또한 사실입니다.
    • 데이터와 데이터를 사용하는 프로세스가 별도의 객체에 위치하고 있다면 절차적 프로그래밍 방식을 따르고 있을 확률이 높습니다.
    • 데이터와 데이터를 사용하는 프로세스가 동일한 객체 안에 위치한다면 객체지향 프로그래밍 방식을 따르고 있을 확률이 높습니다.
  • 사실 객체지향 설계의 핵심은 적절한 객채에게 적절한 책임을 할당하는 것입니다. 객체는 다른 객체와의 협력이라는 문맥 안에서 특정한 역할을 수행하는 데 필요한 적절한 책임을 수행해야 합니다. 따라서 객체가 어떤 데이터를 가지느냐보다는 객체에 어떤 책임을 할당할 것이냐에 초점을 맞춰야 합니다.
  • 적절히 책임을 분해하면 변경에 탄력적으로 대응할 수 있는 견고한 설계를 얻을 수 있습니다. 적절한 객체에 적절한 책임을 할당하면 이해하기 쉬운 구조와 읽기 쉬운 코드를 얻게 됩니다.
  • 설계를 어렵게 만드는 것은 의존성이라는 것을 기억해야 합니다. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것입니다. 결합도를 낮추기 위해 선택할 수 있는 방법으로 세부사항을 내부로 감춰 캡슐화하는 방법이 있습니다. 불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 합니다. 불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 훌륭한 객체지향 설계입니다.

더 개선할 수 있다(step4, step5).

  • 더 개선할 수 있지만, 이 과정에서 존재하지 않았던 새로운 의존성이 추가될 수 있습니다. 의존성 추가는 높은 결합도를 의미하고, 높은 결합도는 변경하기 어려운 설계를 의미합니다.
  • 결합도와 자율성을 모두 만족하게 할 방법이 잘 떠오르지 않는 트레이드오프 시점일 올 수 있습니다. 이 경우 자율성과 결합도 중의 하나를 선택해야 합니다.
  • 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있습니다. 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물입니다. 어떤 경우에도 모든 사람들을 만족하게 할 수 있는 설계를 만들 수는 없습니다.
  • 설계는 균형의 예술입니다. 훌륭한 설계는 적절한 트레이드오프의 결과물이라는 사실을 명심해야 합니다.

그래, 거짓말이다!

  • 비록 현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 묻는 것이 능동적이고 자율적인 존재로 바뀝니다. 이처럼 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화(anthropomorphism)라고 부릅니다.
  • 훌륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계를 가리킵니다. 그 대상이 비록 실세계에서는 생명이 없는 수동적인 존재라고 하더라도 객체지향의 세계로 넘어오는 순간 그들은 생명과 지능을 가진 싱싱한 존재로 다시 태어납니다.
  • 이해하기 쉽고 변경하기 쉬운 코드를 작성하고 싶다면 한 편의 애니메이션을 만든다고 생각합니다. 다른 사람의 코드를 읽고 이해하는 동안에는 애니메이션을 보고 있다고 여러분의 뇌를 속입니다. 그렇게 하면 코드 안에서 웃고, 떠들고, 화내는 가방 객체를 만나더라도 당황하지 않을 것입니다.

04. 객체지향 설계

설계가 왜 필요한가

설계란 코드를 배치하는 것입니다.

  • 설계는 코드 작성의 일부이며 코드를 작성하지 않고서는 검증할 수 없습니다.
  • 우리는 오늘 완성해야 하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야 합니다. 좋은 설계란 오늘 요구하는 기능을 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계입니다.
  • 변경을 수용할 수 있는 설계가 중요한 이유는 요구사항이 항상 변경되기 때문입니다. 변경을 수용할 수 있는 설계가 중요한 이유는 코드가 변경할 때 버그가 추가될 가능성이 높기 때문입니다.
  • 코드를 수정하지 않는다면 버그는 발생하지 않습니다. 요구사항 변경은 필연적으로 코드 수정을 초래하고, 코드 수정은 버그가 발생할 가능성을 높입니다.
  • 버그의 가장 큰 문제점은 코드를 수정하려는 의지를 꺾습니다. 코드 수정을 회피하려는 가장 큰 원인은 두려움입니다. 그리고 그 두려움은 요구사항 변경으로 인해 버그를 추가할지도 모른다는 불확실성에 기인합니다.

객체지향 설계

  • 우리가 진정으로 원하는 것은 변경에 유연하게 대응할 수 있는 코드입니다.
  • 객체지향 프로그래밍은 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공함으로써 요구사항 변경에 좀 더 수월하게 대응하 수 있는 가능성을 높여줍니다.
  • 변경 가능한 코드란 이해하기 쉬운 코드입니다. 코드를 이해할 수 없다면 코드가 변경에 유연하다고 하더라도 아마 코드를 수정하겠다는 마임이 선뜻 들지는 않을 것입니다.
  • 객체지향 패러다임은 여러분이 세상을 바라보는 방식대로 코드를 작성할 수 있게 돕습니다. 세상에 존재하는 모든 자율적인 존재처럼 객체 역시 자신의 데이터를 스스로 책임지는 자율적인 존재입니다. 객체지향은 여러분이 세상에 대해 예상하는 방식대로 객체가 행동하리라는 것을 보장함으로써 코드를 좀 더 쉽게 이해할 수 있게 합니다.
  • 객체지향의 세계에서 애플리케이션은 객체들로 구성되며 애플리케이션의 기능은 객체들 간의 상호작용을 통해 구현됩니다. 그리고 객체들 사이의 상호작용은 객체 사이에 주고받는 메시지로 표현됩니다.
  • 애플리케이션의 기능을 구현하기 위해 객체들이 협력하는 과정에서 객체들은 다른 객체에 의존하게 됩니다. 메시지를 전송하기 위한 지식이 두 객체를 결합하고 이 결합이 객체 사이의 의존성을 만듭니다. 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계입니다. 세상에 객체가 실행되는 주변 환경에 강하게 결합할수록 변경하기 어려워집니다. 객체 간의 의존성은 애플리케이션을 수정하기 어렵게 만드는 주범입니다.
  • 데이터와 프로세스를 하나의 덩어리로 모으는 것은 훌륭한 객체지향 설계로 가는 첫걸음일 뿐입니다. 진정한 객체지향 설계로 나아가는 길은 협력하는 객체들 사이의 의존성을 적절하게 조절함으로써 변경이 쉬운 설계를 만드는 것입니다.

참고