'오브젝트: 코드로 이해하는 객체지향 설계' 의 인상깊은 글귀들
기억해야 할 만한기억해야 할 만한 글귀들을 적는 공간입니다. 개인적으로 이해하기 쉽게 바꾼 말도 있으니, 맥락만 봐주시길 바랍니다. 문서의 변경이 있을 수 있습니다.
모든 소프트웨어 모듈에는 세 가지 목적이 있다.
- 실행 중에 제대로 동작하는 것. 이것은 모듈의 존재 이유다.
- 변경을 위해 존재한다. 대부분 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다.
- 코드를 읽는 사람과 의사소통하는 것이다. 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다.
프로그래밍 패러다임의 공존. - 절차형 패러다임과 객체지향 패러다임은 공존할 수 없는가?
예를 들어 절차형 패러다임 과 객체지향 패러다임 이 공존할 수는 없는 걸까?
서로 다른 패러다임이 하나의 언어 안에서 공존함으로써 서로의 장단점을 보완한다.
프로그래밍 패러다임은 과거의 패러다임을 폐기시키는 혁명적인 과정을 거치지 않는다.
오히려 과거 패러다임의 단점을 보완하는 발전적인 혁명을 거친다.
이는 비록 객체지향 패러다임을 주로 사용한다고 해도, 다른 패러다임을 배우는 것이 도움이 될 것이라는 사실을 암시한다.
은총알은 없다 라는 말을 기억하라. 객체지향이 적합하지 않은 상황에서는 언제라도 다른 패러다임을 적용할 수 있는 시야를 기르고, 지식을 갈고닦아야 한다.
객체 사이의 의존성 - 설계의 목표
의존성은 변경에 대한 영향을 암시한다. 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼있다.
그렇다면 객체 사이의 의존성을 완전히 없애야 하는 것인가? 아니다. 객체지향 설계는 서로 의존하며 협력하는 객체들의 공동체를 구축하는 것이다
따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
설계는 균형의 예술이다.
- 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.
- 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다.
설계는 균형의 예술이다. 훌륭한 설계는 적절한 트레이드오프의 결과물이다.
소프트웨어는 곧 생물이다. - 의인화
현실에서는 수동적인 존재라 하더라도, 객체지향의 세계에서는 모든 것이 능동적이고 자율적인 존재다.
현실의 전화는 서로에게 전화를 걸지 않으며, 색은 스스로 칠하지 않는다. 반드시 인간이 필요하다.
하지만 객체지향의 세계에서 객체들은 _능동적이고 자율적인 존재_다.
소프트웨어는 태어나고, 삶을 영위하고, 그리고 죽는다.
객체지향은 말 그대로 객체를 지향하는 것.
객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때만 얻을 수 있다. 다음 두 가지에 집중하자.
- 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라.
- 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추상화한 것이다.
- 따라서 클래스의 윤곽을 잡기 위해서는 어떤 객체들이 어떤 상태와 행동을 가지는 지를 먼저 결정해야한다.
- 객체를 중심에 두는 접근 방법은 설계를 단순하고 깔끔하게 만든다.
- 객체는 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원이다.
- 객체는 홀로 존재하지 않는다. 다른 객체에게 도움을 주거나 의존하면서 살아가는 협력적인 존재다.
- 이 관점으로 바라보는 것은 설계를 유연하고 확장 가능하게 만든다.
- 객체를 고립된 존재로 바라보지말고, 협력에 참여하는 협력자로 바라볼 것.
- 객체들의 모양과 윤곽이 잡히면, 공통된 특성과 상태를 가진 객체들을 타입으로 분류하고, 이 타입을 기반으로 클래스를 구현할 것.
- 훌륭한 협력이 훌륭한 객체를 낳고 훌륭한 객체가 훌륭한 클래스를 낳는다.