❓이론이 먼저일까, 실무가 먼저일까?
결론부터 말하자면 실무가 먼저라고 생각합니다. 왜냐하면 어떤 분야든 이론을 정립할 수 없는 시기(초기)가 존재하고, 그때는 실무가 먼저 급속한 발전을 이루게 됩니다. 그리고 실무가 어느 정도 발전하고 난 다음에야 실무의 실용성을 입증할 수 있는 이론이 갖춰지기 시작합니다.(결과 → 원인)
이러한 관점에서 소프트웨어 분야는 다른 분야(ex. 건축학)에 비해 역사가 짧기 때문에 현재로써는 이론보다는 실무가 앞서 있고 더 중요하다고 생각합니다.
하지만 현재 나와있는 설계 원칙과 개념들은 실무에서 반복적으로 적용되던 기법들을 이론화한 것들이므로 충분히 실무에 적용할 가치가 있고, 판단의 근거로 삼아도 된다고 생각합니다.
❓의존성, 결합도, 응집도
의존성(dependency)
의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실을 내포한다.
따라서, 우리는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거해야한다.
결합도(coupling)
객체 사이의 의존성이 관한 경우를 가르켜 결합도가 높다고 말한다. 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다.
따라서, 우리는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만들어야 한다.
응집도(cohesion)
밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도가 높다고 말한다. 객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다.
💬 소프트웨어 모듈이 가져야 하는 3가지 기능 (from 로버트 마틴)
1️⃣ 모듈은 제대로 실행돼야 한다.
2️⃣ 모듈은 변경이 용이해야 한다.
3️⃣ 모듈은 이해하기 쉬워야 한다.
💡 구체적인 Tip
- 객체가 다른 객체의 상세한 내부 구현까지 알지 못하도록 정보를 차단하자. (캡슐화)
- 객체가 자신의 데이터를 자신이 처리하는 자율적인 존재로 만들자.
- 캡슐화를 하면 객체의 자율성과 응집성이 높아진다.
- 객체를 인터페이스와 구현으로 나누고 인터페이스만 공개하자. (객체 사이 결합도 ↓)
- 객체 간의 상호작용은 메시지(메서드)를 통해서만 이루어지게 하자.
💬 변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계다.
- 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약할 수 밖에 없다.
- 객체지향 프로그래밍은 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 하기 때문에 하나의 변경으로 인한 여파가 여러 클래스로 전파되는 것을 효율적으로 억제할 수 있다.
💬 객체지향 설계의 핵심은 적절한 객체에 적절한 책임(기능)을 할당하는 것이다.
- 한 객체에 몰려 있던 책임이 개별 객체로 이동하는 것을 책임의 이동이라고 한다.
- 객체가 어떤 데이터를 가지느냐보다는 객체에 어떤 책임을 할당할 것이냐에 초점을 맞춰야 한다.
❓좋은 설계란?
오늘 요구하는 기능을 온전히 수행하면서, 내일의 변경을 매끄럽게 수용할 수 있는 설계입니다. (요구사항은 바뀔 수 밖에 없다.)
이러한 관점에서 객체지향 설계는 요구사항 변경에 좀 더 수월하게 대응할 수 있는 가능성을 높여준다는 점에서 좋은 설계 방식이라고 생각합니다.
- bc. 객체지향 설계는 의존성을 효율적으로 통제할 수 있는 다양한 방법(ex. 캡슐화, 추상화, 다형성)을 제공하기 때문에
- bc. 객체의 의존성을 통제해 응집도↑ 결합도↓ 모듈을 만들어야 변경에 유연하기 때문에
💬 훌륭한 설계는 적절한 트레이드오프의 결과물이다.
- 어떤 기능을 설계하는 방법은 한가지 이상일 수 있다.
- 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다.
- 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수는 없다.
