1장 객체, 설계

정리

소프트웨어 설계와 유지보수에 중점을 두려면 이론이 아닌 실무에 초점을 맞추는 것이 효과적이다.

모듈은 제대로 실행돼야 하고, 변경이 용이해야 하며, 이해가 쉬워야 한다.

객체지향 설계란 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.

→ 따라서 우리는 애플리케이션 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거해야 한다.                                                               

결합도, 캡슐화, 응집도, 자율성

객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.

객체 사이의 의존성이 과한 경우를 가리켜 결합도가 높다고 한다.

캡슐화의 목적은 변경하기 쉬운 객체로 만드는 것으로 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것이다.

캡슐화를 통해 객체 사이의 결합도를 낮출 수 있어 설계를 좀 더 쉽게 변경할 수 있다.

밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도가 높다고 한다.

자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮추고 응집도를 높일 수 있다.

절차적 프로그래밍과 객체지향 프로그래밍

절차적 프로그래밍 : 프로세스와 데이터를 별도의 모듈에 위치시키는 방식.

객체지향 프로그래밍 : 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식.

절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약할 수 밖에 없다.

→ 프로세스의 적절한 단계를 데이터로 이동시킴으로써 자신의 데이터를 스스로 처리도록하여 해결할 수 있다.

객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리하여 객체 사이의 결합도를 낮추는 것이다.

책임의 이동

책임의 이동은 절차지향과 객체지향 사이의 근본적인 차이를 만드는 것이다.

책 내 예제를 봤을 때 절차지향에선 작업의 흐름이 Theater에 의해 제어된 반면, 객체지향 설계에서는 Theater에 몰려 있던 책임이 개별 객체로 이동했다.

이를 책임의 이동이라고 한다.

따라서 각 객체는 자신을 스스로 책임지고, 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로써 완성된다.

훌륭한 설계?

기능을 설계할 때 여러 방법으로 설계할 수 있기 때문에 설계는 트레이드오프의 산물이다.

→ 훌륭한 설계는 적절한 트레이드오프의 결과물.

레베카 워프스브룩은 능동적이고 자율적 존재로 소프트웨어 객체를 설계하는 원칙을 의인화라고 부른다.

설계가 필요한 이유

설계는 코드 작성의 일부이며 코드를 작성하지 않고서는 검증할 수 없다.

설계란 코드를 배치하는 것이다.[metz12]

변경을 수용할 수 있는 설계가 중요하다.

• 요구사항이 항상 변하기 때문이다.
• 코드를 변경할 때 버그가 추가될 가능성이 높기 때문이다.

느낀점

---

1장에서 훌륭한 설계는 적절한 트레이드오프의 결과물이라고 했는데 이 말을 하기에 앞서 ‘설계는 균형의 예술이다’라고 한 부분이 인상깊었다.

3달 뒤 예술적인 균형을 갖고 설계하고 있을 나를 기대하게 되었다.