TIL (Today I Learned) 날짜

2022. 05. 19

오늘 읽은 범위

4장. 실용주의 편집증

책에서 기억하고 싶은 내용을 써보세요.

- Tip> 완벽한 소프트웨어는 만들 수 없다.

- 정확한 프로그램이란 무엇인가? 스스로 자신이 하는 일이라고 주장하는 것보다 많거나 적지도 않게 딱 그 만큼만 하는 프로그램을 말한다. 이 주장을 문서화하고 검증하는 것이 계약에 의한 설계(Design By Contract), DBC 의 핵심이다.

- 선행조건(precondition): 루틴이 호출되기 위해 참이어야 하는 것. / 후행조건(postcondition): 루틴이 자기가 할 것이라고 보장하는 것. / 클래스 불변식(class invariant): 호출자의 입장에서 볼 때는 이 조건이 언제나 참이라고 클래스가 보장한다.

- 만약 호출자가 루틴의 모든 선행조건을 충족한다면 해당 루틴은 종료시 모든 후행조건과 불변식이 참이 될 것을 보증해아 한다.

- Tip> 계약에 따른 설계를 하라.

- 시작하기 전에 자신이 수용할 것에 대해서는 엄격하게 하고, 내어줄 것에 대해서는 최소한도를 약속하는 것이다.

- 서브클래스는 사용자가 차이점을 모르고서도 기반 클래스 인터페이스를 통해 사용할수 있어야 한다.

- 서브타입이 정말 베이스타입의 '한 종류'여야 한다. 즉, 동일한 메서드들을 지원하고, 그 메서드들은 동일한 의미 를 가져야 한다.

- 계약을 기반 클래스에 오로지 한 번만 명기하면, 자동으로 미래의 모든 서브클래스에 적용되도록 할 수 있다.

- 서브클래스는 자신의 부모 이상으로 받아들이고, 최소한 자신의 부모만큼은 보증해야 한다.

- 기반 클래스 계약을 만들면, 이제는 어떤 미래의 서브클래스이건 우리 메서드의 의미를 변경할 수 없다고 확신할 수 있다.

- 루프 불변식은 루프의 최종 목적에 대한 진술문이지만, 일반화되어 있기 때문에 루프가 시작하기 전과 루프 진행 중 매 반복 시 적용된다.

- 의미론적 불변식을 사용하면 일종의 '철학적 계약' 인 불변의 요구사항을 표현할 수 있다.

- Tip> 일찍 작동을 멈추게 하라.

- 되도록 빨리 종료해야 할 일이다. 일반적으로, 죽은 프로그램이 입히는 피해는 절름발이 프로그램이 끼치는 것보다 훨씬 덜한 법이다.

- Tip> 단정문을 사용해서 불가능한 상황을 예방하라.

- '하지만 물론 그건 절대 일어나지 않을 거야.' 라는 생각이 든다면, 그걸 확인하는 코드를 추가하라. 이걸 하는 가장 간단한 방법은 단정문(assertion)을 사용하는 것이다.

- 진짜 에러처리 대신으로 단정을 사용하지는 마라. 단정은 결코 일어나면 안되는 것들을 검사한다.

- Tip> 예외는 예외적인 문제에 사용하라.

- Tip> 시작한것은 끝내라.

- 리소스를 할당하는 루틴이 해제 역시 책임져야 한다는 것이다.

- 리소스를 할당한 순서의 반대로 해제하라. / 코드의 여러 곳에서 동일한 리소스 집합을 할당하는 경우, 할당 순서를 언제나 같게 하라. 교착(deadlock) 가능성이 줄어들 것이다.

- 최상위 구조 자신이 자기 안에 들어있는 하위 구조들의 할당을 해제할 책임이 있다. 하위 구조들은 또다시 재귀적으로 자기 안에 들어있는 자료들을 해제할 책임이 있고 이런 식으로 진행된다.

- 최상위 구조에서 그냥 할당이 해제된다. 그 안에서 참조하던 (다른 곳에서 참조하지 않는) 구조들은 모두 연결이 끊어져 고아가된다.

- 최상위 구조는 하나라도 하위 구조를 가지고 있을 경우 자기의 할당 해제를 거부한다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

- 프로그래밍을 할 때 내 자신에게 너무 포용적인 것 같다는 생각이 많이 들었다.

- 이번 챕터를 읽으면서 에러를 예방하는 여러가지 방법들에 대한 것들을 알았으며, 최대한 적용해 보도록 해야겠다.