728x90
반응형
책을 읽으면서 들었던 생각 또는 내용을 정리한 글입니다.
Software module의 3가지 목적
- 실행 중에 제대로 동작하는 것
- 실행 중에 제대로 동작하는 것은 기본적인 내용이지만 다르게 생각을해보건데 software가 하나의 제품이기 때문이지 않을까 싶다. 어떤 제품을 샀을 때 제품이 불량이고 하자가 많으면 사람들은 그 기업의 제품을 신뢰하려고 들까?
- 실행 중에 제대로 동작하는 것은 이처럼 하나의 소프트웨어 모듈은 제품이 가져야 하는 기본적인 요소라고 생각하자
- 변경을 위해 존재하는 것
- 그렇다고 소프트웨 모듈이 현실 제품의 그것과 똑같이 생각하면 안 된다. 소프트웨 모듈이라는 제품은 변경이 잦은 제품이다.
- 코드를 읽는 사람과 의사소통하는 것
- 변경이 잦고 어떤 이유를 거쳐 어떻게 만들어졌는가를 마치 설계도와 같다고 가정한다면 설계도를 읽는 사람은 그 내용과 구조가 명확해야 의도를 파악하고 유지보수가 잘 이루어질 것이다.
코드, 코드, 코드
- 예상을 빗나가는 코드
- 예상을 빗나가는 코드란 뭘까?, 아니 보다 더 세밀하게 들어가 보자 내가 쓴 코드를 다른 사람이 읽을 때 큰 그림에서 벗어나 있는 코드를 읽게 된다면 어떤 생각이 들까?
- 아마도 코드를 읽는 사람 입장에서 미처 파악하지 못한 세부사항이 존재하고 있다는 가정을 하게 되거나 그 코드에 대한 세부적인 내용을 다 파악한 채 유지보수를 할 것이다.
- 즉, 현실 세계에 존재하는 플로우와 그 자체를 직관적으로다가 코드를 읽는 사람에게 제공할 수 있어야 하지 않을까?
- 변경에 취약한 코드
- 의존성이 높은 코드
- 객체 사이의 의존성을 완전히 없애 버릴 순 없다. 그러므로 객체 지향적으로 설계하는 코드는 객체끼리 협력하는 공동체를 구축하는 것이라고 생각하자. 즉 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 작업에 신경 쓰자.
- 결합도가 높은 코드
- 객체끼리 협력하는 공동체를 구축할 때 서로 너무 많은 것을 의지하게 되면 변경의 비용이 발생한다. 그러므로 적당한 결합도를 유지하는 작업에 신경 쓰자.
- 의존성이 높은 코드
개선하기
- 앞서 예상을 빗나가는 코드라는 것에 대해 정리를 했다. 그렇다면 직관성을 제공할 수 있는 방법으로는 어떤 것이 존재할까?
- Encapsulation, 캡슐화
- 캡슐화의 목적은 변형하기 쉬운 객체를 만드는 것이다. 즉 캡슐화를 통해 내부로의 접근을 제한하면 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다.
- Cohension, 응집도
- 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더러 응집도를 높일 수 있다.
- Shift of Responsibility, 책임의 이동
- 책임은 객체의 기능을 가리키는 객체 지향 세계의 용어이다. 이러한 책임은 각 객체에 적절히 분배되어있어야 하며 한 객체가 너무 많은 책임을 지게 해서는 안된다.
- Encapsulation, 캡슐화
객체지향 설계
- 즉 진정한 의미의 객체지향 설계 혹은 훌룡한 객체지향 설계로 나아가려면 다음과 같은 사항들을 기억하자.
- 객체 간의 상호작용은 메시지를 통해 처리하자.
- 객체 간의 너무 세부적인 구현 사항을 알지 못하도록 처리하자.
- 각 객체는 자신을 스스로 책임진다. 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로 완성된다.
- 불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만 남기는 것이 훌륭한 객체지향 설계다.
- 현실에서의 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀜
- 레베카 워프스브룩은 이처럼 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화(Anthoropomorphism)라고 부른다.
- 훌륭한 객체지향 설계로 나아가는 길은 협력하는 객체들 사이의 의존성을 적절하게 조절함으로써 변경에 용이한 설계를 만드는 것이다.
728x90
반응형
