객체지향 디자인
Sep 8, 2018 · 3 min read
객체지향 디자인의 실패는 코딩 능력 부족이 아닌 관점의 실패다.
일단 객체지향 관점을 얻고 나면 나머지는 자연스럽게 따라온다.

What is Object-oriented design
객체지향 디자인은 세상을 이미 정해진 절차들의 묶음으로 생각하지 않고, 객체가 서로 주고 받는 메시지들의 연쇄로 파악할 것을 요구한다.
디자인의 목적
변화가 쉬운 코드
- 변화는 피할수 없다. 피할수 없다면 즐겨라.
- 변화가 쉬운 소프트웨어를 만드는것, 이것이 디자인의 최종목적이다.
의존성
객체에게 메시지를 송신하기 위해서는 송신하는 객체가 수신하는 객체에대해 필연적으로 어느 정도 알고 있어야 한다.
하지만 필요 이상의 의존성은 애플리케이션을 수정하기 어렵게 만든다.
객체지향 디자인은 변화에 유연하기 위하여 의존성을 관리하는 코딩 기술의 묶음이다.
- 필연적으로 어느정도 알고있어야 한다면 최소한의 지식만 알고있게 하자
- 그러한 지식들의 공개여부(public, private), 방향을 관리해야 한다.
지식의 종류
- 다른 클래스의 이름.
- 메세지의 이름
- 메세지의 인자들
- 인자들의 순서
- Context
작은 애플리케이션
‘좋지 않은 디자인의 작은 애플리케이션’이 갖는 문제는 이 애플리케이션이 발전해서 ‘좋지 않는 디자인의 큰 애플리케이션’이 된다는 데 있다.
예측하지 않기, 공간을 남겨두기
미래의 특수한 요구사항을 미리 예측하는 디자인은 거의 언제나 좋지 않은 결과를 낳는다.
- 실용적 디자인은 우리 애플리케이션에 어떤 일이 벌어질지 예측하는 것이 아니라, 단지 언젠가 무언가는 변한다는 사실 그리고 지금은 무엇이 변경 될지 알 수 없다는 사실을 받아들이는 것이다.
- 디자인은 미래를 예측하지 않는다. 변화하고 움직일 수 있는 공간을 남겨 놓을 뿐이다.
커다란 디자인을 먼저 구상하기, BUFD(Big Up Front Design)
말도 안되는 방법이다. 예측하지 말자.
정말로 리펙토링 해야 할까?
(투명함과 적절함을 잃을때) 다른 객체와 의존성이 생기면 그 순간이 리펙토링을 고려해야 할때이다. 그런데 정말 하면 좋을까? 그건 상황에 따라 다르다.
- 지금 아무것도 하지 않는다면 나중에 어떤 대가를 치르게 되지?
- 더 많은 정보를 얻을 때까지 일단은 그냥 기다리고 있는 쪽이 가장 비용-효율적인 접근일수 있다.
- 현재 코드 수정 비용 = 이후 코드 수정 비용 라고 한다면, 미루자.
- 완벽하게 디자인된 애플리케이션이란 없다. 모든 결정에는 대가가 따른다.
- 왜 문제인지 파악하고
- 개선 코드(디자인)을 보여주고
- 문제가 정말 해결되었는지 파악하기
