디자인 시 고려할 점.

Posted 2007. 9. 18. 04:27

모듈이 할 수 있는 일을 클라이언트가 하게 하지 말아야 한다.

사용자가 단순 반복되는 코드(boilerplate code)를 작성하지 않도록 해야 한다. 반복되는 코드는 주로 잘라 붙이기(cut-and-paste)를 통해 구현되며, 이렇게 작성된 코드는 실수를 범하기가 쉽다. 따라서 API를 사용해 여러 유스 케이스를 구현해보고, 동일한 코드가 반복된다면 해당 코드를 API 안으로 집어넣어서 사용자가 쉽게 사용할 수 있어야 한다.

사용자가 놀라게 하지 말아야 한다(The Principle of Least Astonishment).

API는 사용자가 예상치 못했던 행동을 해서 놀라게 하는 일이 없어야 한다. 대표적인 예가 Thread 클래스에서 interrupted() 메서드를 불렀을 때 인터럽트 되었는지 여부를 리턴할 뿐만 아니라, 인터럽트 플래그를 클리어시키는 것이다. interrupted() 메서드 이름만 봤을 때는 이진 플래그를 리턴하는 간단한 질의 메서드를 떠올리게 되는데, 사용자가 예상치 못하게 플래그를 클리어하는 부작용이 있다. 이 메서드가 하는 중요한 역할은 인터럽트 플래그를 리턴하는 것이 아니라 인터럽트 플러그를 클리어하는 데 있으므로, clearInterrupt()라고 명명하는 것이 나았을 것이다.

빨리 실패해야 한다.

문제가 있으면 최대한 빨리 발견되는 것이 좋다. 타입 검사를 통해 컴파일 타임에 발견되면 제일 좋고, 런타임의 경우 잘못된 메서드가 호출되었을 때 즉시 이상이 있음을 알리는 것이 좋다. 문제가 중첩되고 있는데, 나중에서야 알려주면 문제가 시작된 지점이 언제인지 찾기가 어려워진다. 결국 디버깅이 불가능해진다.


역시 마소 원고 쓰다가 남은 부분입니다. 전체 리스트는 아니고 고려해야할 사항 중에 일부입니다.