클린 소프트웨어 책 정리

Chapter 8. 단일 책임 원칙

한 클래스는 단 한 가지의 변경 이유만을 가져야 한다.

책임 : 변경을 위한 이유
변경의 축은 변경이 실제로 일어날 때만 변경의 축이다. 아무 증상도 없는데 SRP나 다른 원칙을 적용하는 것은 현명하지 못하다.

Chapter 9. 개방 폐쇄 원칙

소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.

OCP가 잘 적용된다면, 이미 제대로 동작하고 있던 원래 코드를 변경하는 것이 아니라 새로운 코드를 덧붙임으로써 나중에 그런 변경을 할 수 있게 된다.

OCP의 두 가지 중요한 속성

1. 확장에 대해 열려 있다

모듈의 행위가 확장될 수 있음을 의미. 애플리케이션의 요구사항이 변경될 때, 이 변경에 맞게 새로운 행위를 추가해 모듈을 확장할 수 있다. 즉, 모듈이 하는 일을 변경할 수 있다.

2. 수정에 대해 닫혀 있다

어떤 모듈의 행위를 확장하는 것이 그 모듈의 소스 코드나 바이너리 코드의 변경을 초래하지 않는다. 그 모듈의 실행 가능한 바이너리 형태는 링킹 가능한 라이브러리, DLL 이나 자바의 .jar에서도 고스란히 남아 있다.

추상화를 통해 OCP를 달성

추상화는 추상 기반 클래스이자, 모든 가능한 파생 클래스를 대표하는 가능한 행위의 제한되지 않은 묶음.
스트래티지 패턴/템플릿 메소드 패턴은 OCP 원칙을 따르도록 함.
추상 클래스는 자신을 구현하는 클래스보다도 클라이언트에 더 밀접하게 관련되어 있기 때문에 클라이언트와 연관된 이름으로 지음

chapter 10. 리스코프 치환 원칙

서브타입(subtype)은 그것의 기반 타입(base type)으로 치환 가능해야 한다.

타입 S의 객체 O1과 타입 T의 각 객체 O2가 있을 때, T로 프로그램 P를 정의했음에도 불구하고, O2를 O1으로 치환했을 때 P의 행위가 변하지 않으면, S는 T의 서브타입이다. : 바버라 리스코프

‘IS-A’는 행위에 대한 것

행위는 소프트웨어의 모든 것. IS-A 관계는 개념적 관계가 아니라 객체의 행위적 관점에서 파악해야 한다.

계약에 의한 설계 (DBC : Design By Contract)

DBC를 사용하면, 어떤 클래스의 작성자는 그 클래스의 계약사항을 명시적으로 정한다. 이 계약은 모든 고객 코드의 작성자가 신뢰할 수 있는 행위에 대해 알려준다. 또한 이 계약은 각 메소드의 사전조건과 사후조건을 선언하는 것으로 구체화된다. 메소드를 실행하기 위해서는 사전조건이 참이 되어야 한다. 메소드는 완료되고 나면 사후조건이 참이 됨을 보장한다.

각 메소드의 주석에서 이런 사전조건과 사후조건을 문서화해두면 유용하다.

계약은 단위 테스트를 작성함으로써 구체화될 수 있다. 단위 테스트는 어떤 클래스의 행위를 철저하게 테스트함으로써, 그 클래스의 행위를 좀 더 분명하게 만들어준다.

chapter 11. 의존 관계 역전 원칙

a. 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다.
b. 추상화는 구체적인 사항에 의존해서는 안 된다. 구체적인 사항은 추상화에 의존해야 한다.

잘 설계된 객체 지향 프로그램의 의존성 구조는 전통적인 절차적 방법에 의해 일반적으로 만들어진 의존성 구조가 ‘역전’된 것이다.

References

• 클린 소프트웨어 (애자일 원칙과 패턴, 그리고 실천 방법), 로버트 C. 마틴 지음