2007년 09월 18일
[참고] 디자인 시 고려할 점
모듈이 할 수 있는 일을 클라이언트가 하게 하지 말아야 한다.
사용자가 단순 반복되는 코드(boilerplate code)를 작성하지 않도록 해야 한다. 반복되는 코드는 주로 잘라 붙이기(cut-and-paste)를 통해 구현되며, 이렇게 작성된 코드는 실수를 범하기가 쉽다. 따라서 API를 사용해 여러 유스 케이스를 구현해보고, 동일한 코드가 반복된다면 해당 코드를 API 안으로 집어넣어서 사용자가 쉽게 사용할 수 있어야 한다.
사용자가 놀라게 하지 말아야 한다(The Principle of Least Astonishment).
API는 사용자가 예상치 못했던 행동을 해서 놀라게 하는 일이 없어야 한다. 대표적인 예가 Thread 클래스에서 interrupted() 메서드를 불렀을 때 인터럽트 되었는지 여부를 리턴할 뿐만 아니라, 인터럽트 플래그를 클리어시키는 것이다. interrupted() 메서드 이름만 봤을 때는 이진 플래그를 리턴하는 간단한 질의 메서드를 떠올리게 되는데, 사용자가 예상치 못하게 플래그를 클리어하는 부작용이 있다. 이 메서드가 하는 중요한 역할은 인터럽트 플래그를 리턴하는 것이 아니라 인터럽트 플러그를 클리어하는 데 있으므로, clearInterrupt()라고 명명하는 것이 나았을 것이다.
빨리 실패해야 한다.
문제가 있으면 최대한 빨리 발견되는 것이 좋다. 타입 검사를 통해 컴파일 타임에 발견되면 제일 좋고, 런타임의 경우 잘못된 메서드가 호출되었을 때 즉시 이상이 있음을 알리는 것이 좋다. 문제가 중첩되고 있는데, 나중에서야 알려주면 문제가 시작된 지점이 언제인지 찾기가 어려워진다. 결국 디버깅이 불가능해진다
원문: http://skyul.tistory.com/ 서광열의 소프트웨어 이야기
사용자가 단순 반복되는 코드(boilerplate code)를 작성하지 않도록 해야 한다. 반복되는 코드는 주로 잘라 붙이기(cut-and-paste)를 통해 구현되며, 이렇게 작성된 코드는 실수를 범하기가 쉽다. 따라서 API를 사용해 여러 유스 케이스를 구현해보고, 동일한 코드가 반복된다면 해당 코드를 API 안으로 집어넣어서 사용자가 쉽게 사용할 수 있어야 한다.
사용자가 놀라게 하지 말아야 한다(The Principle of Least Astonishment).
API는 사용자가 예상치 못했던 행동을 해서 놀라게 하는 일이 없어야 한다. 대표적인 예가 Thread 클래스에서 interrupted() 메서드를 불렀을 때 인터럽트 되었는지 여부를 리턴할 뿐만 아니라, 인터럽트 플래그를 클리어시키는 것이다. interrupted() 메서드 이름만 봤을 때는 이진 플래그를 리턴하는 간단한 질의 메서드를 떠올리게 되는데, 사용자가 예상치 못하게 플래그를 클리어하는 부작용이 있다. 이 메서드가 하는 중요한 역할은 인터럽트 플래그를 리턴하는 것이 아니라 인터럽트 플러그를 클리어하는 데 있으므로, clearInterrupt()라고 명명하는 것이 나았을 것이다.
빨리 실패해야 한다.
문제가 있으면 최대한 빨리 발견되는 것이 좋다. 타입 검사를 통해 컴파일 타임에 발견되면 제일 좋고, 런타임의 경우 잘못된 메서드가 호출되었을 때 즉시 이상이 있음을 알리는 것이 좋다. 문제가 중첩되고 있는데, 나중에서야 알려주면 문제가 시작된 지점이 언제인지 찾기가 어려워진다. 결국 디버깅이 불가능해진다
원문: http://skyul.tistory.com/ 서광열의 소프트웨어 이야기
# by | 2007/09/18 13:52 | ┣ Code | 트랙백 | 덧글(0)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]