"주석은 쓸모 없는 것" http://process.kaist.ac.kr/~gendoh/blog/18 이란 글을 작년에 썼는데 http://kaistizen.net/EE/index.php/weblog/benefits_of_documatation_tools/ 글을 또 발견하게 되서 좀더 보충.
OOPL(Object-Oriented Programming Language)들이 Method 혹은 포괄적인 의미의 Property(최근 언어들은 Member function과 Member variable의 구분이 점점 사라져 간다)에 대한 Polymorphism을 지원하는 과정들을 볼때 나름대로 내린 결론.
MFC(Microsoft Faoundation Class)의 훌륭한 점중 하나로 전반적인 사용의 통일성과 부모가 동일한 클래스는 대충 집어 던지면 잘 동작한다는 것을 들 수 있다. 통일성이라고 한다면 객체는 모두 "생성-초기화-사용-파괴"의 구조를 지키고 있기 때문에 새로운 클래스를 가져와 쓸 때도 특별한 케이스를 제외하곤 기존의 쓰던 가락대로 코드를 생성할 수 있다. 특히 파괴부분은 AutoDestroy를 지원하기 때문에 집어 넣고 나면 신경쓰지 않아도 되는 케이스가 많다.(물론 조금만 잘못 디자인 해도 AD를 쓰지 못하고 수동 파괴를 해 줘야 하는 케이스가 생기긴 하지만.. 뭐 양쪽다 문제) 더불어 Abstraction의 도움으로 부모클래스의 virtual function을 이용, 비슷한 놈들은 쉽게 집어 던질 수 있고 그 틀만 벗어나지 않으면 새로운 클래스도 그대로 들어간다는 점이다. 이는 최근의 언어들로 와서는 구지 부모가 같을 필요도 없고 몇개의 조건만 만족시키면 쉽게 된다. (iteration을 비교해 보면 느낄 수 있다. Ruby 정도 되면 매니악하다 ㄱ-)
사용자에 대한 User Interface를 디자인 할 때 일관성도 중요하여 메뉴 하나를 사용하는 학습을 하게 되면 그 가락으로 나머지 기능도 비슷하게 사용할 수 있도록 하는 것이 좋다고 한다. 이는 프로그래머에 대한 인터페이스에 대해서도 동일할 것이다. 함수마다 일일이 설명이 있는 것이 아니라 A4 한장정도 되는 문서에 라이브러리 사용하는 방법과 전반적인 구동 메커니즘만 설명하면 각 함수들을 예상되는 대로 사용가능토록 디자인 되도록 하는 것이 좋을 것이다.
어떤 객체이든 "생성-초기화-동작-파괴"의 일관된 사용과정을 가지고 다른 객체를 받아 들여야 하는 경우 그것이 무엇이든 알아서 구겨넣어 들어가게 디자인 하는것이다. 가령 ChangeCustomerName이란 함수를 제공하는 케이스라면 Customer 객체를 Assign 하는 것으로 이를 대체할 수 있고 근본적으로 새로운 Customer의 생성이나 각 프로퍼티의 변경을 Assign으로 단일화 할 수 있다. Data를 직접 들고 있는 객체 입장에선 받아들인 Customer객체를 어떻게 핸들링 해야 하는지 Determin 할 수 있기 때문이다(할 수 있게 디자인 해야 한다가 정확할 듯). Assign Operator 혹은 Function에서 Polymorphism을 이용하거나 데이터에 대한 추상화를 통해 나누어진 여러 기능을 쉽게 하나의 방법으로 구현가능할 것이다. Add와 Update가 다른 것 처럼 보여도 개념에 따라서는 동일하게 볼 수도 있다. 디자인의 차이다.
처음에 API에 대해선 예외를 적용했는데 그 이유는 당연하다. 그런 것은 낮은 레벨이기 때문이다. GendohSQL DBMS를 만들고 이것을 접근하는 Low API를 제공하려면 당연히 메뉴얼을 두껍게 만들어야 할 것이다. Exception 설명에만도 Appendix를 따로 할애해야 할지도 모른다. 허나 ADO혹은 더 높은 수준의 모델을 제공한다면 당연히 간단한 샘플로 끝낼 수 있어야 한다. 이는 인터페이스의 일관성은 물론이고 예외상황이 발생하여 프로그래머를 괴롭히는 것이 아니라 알아서 그것이 처리되어야 하고(밖으로는 차이가 없어야 한다) 사용법이 단순해야 한다는 점 등등을 요구할 것이다.
전자렌지의 경우 사용 설명서 없이도 많은 사람들이 잘쓴다. 30초를 돌리든 5분을 돌리든 사용방법이 동일하기 때문이다. 그리고 그 방법이 직관적이다. 가장 중요한 점은, 음식물이 핫바든 햄버거든 사용방법이 달라지지는 않는다. 한 병사의 죽음으로 개발된, 매우 어려운 물리적 현상으로 개발된 전자렌지가 가정마다 보급된 이유라 할 수 있다.
OOPL(Object-Oriented Programming Language)들이 Method 혹은 포괄적인 의미의 Property(최근 언어들은 Member function과 Member variable의 구분이 점점 사라져 간다)에 대한 Polymorphism을 지원하는 과정들을 볼때 나름대로 내린 결론.
운영체제를 만들거나 새로운 언어를 만드는 케이스가 아니라면 주석 따윈 필요없도록 디자인 할것.코드가 바로 주석인 정도가 아니라 아예 그런 것 조차도 필요없도록 Abstraction을 잘 해야 한다는 것이 지론이다.
MFC(Microsoft Faoundation Class)의 훌륭한 점중 하나로 전반적인 사용의 통일성과 부모가 동일한 클래스는 대충 집어 던지면 잘 동작한다는 것을 들 수 있다. 통일성이라고 한다면 객체는 모두 "생성-초기화-사용-파괴"의 구조를 지키고 있기 때문에 새로운 클래스를 가져와 쓸 때도 특별한 케이스를 제외하곤 기존의 쓰던 가락대로 코드를 생성할 수 있다. 특히 파괴부분은 AutoDestroy를 지원하기 때문에 집어 넣고 나면 신경쓰지 않아도 되는 케이스가 많다.(물론 조금만 잘못 디자인 해도 AD를 쓰지 못하고 수동 파괴를 해 줘야 하는 케이스가 생기긴 하지만.. 뭐 양쪽다 문제) 더불어 Abstraction의 도움으로 부모클래스의 virtual function을 이용, 비슷한 놈들은 쉽게 집어 던질 수 있고 그 틀만 벗어나지 않으면 새로운 클래스도 그대로 들어간다는 점이다. 이는 최근의 언어들로 와서는 구지 부모가 같을 필요도 없고 몇개의 조건만 만족시키면 쉽게 된다. (iteration을 비교해 보면 느낄 수 있다. Ruby 정도 되면 매니악하다 ㄱ-)
사용자에 대한 User Interface를 디자인 할 때 일관성도 중요하여 메뉴 하나를 사용하는 학습을 하게 되면 그 가락으로 나머지 기능도 비슷하게 사용할 수 있도록 하는 것이 좋다고 한다. 이는 프로그래머에 대한 인터페이스에 대해서도 동일할 것이다. 함수마다 일일이 설명이 있는 것이 아니라 A4 한장정도 되는 문서에 라이브러리 사용하는 방법과 전반적인 구동 메커니즘만 설명하면 각 함수들을 예상되는 대로 사용가능토록 디자인 되도록 하는 것이 좋을 것이다.
어떤 객체이든 "생성-초기화-동작-파괴"의 일관된 사용과정을 가지고 다른 객체를 받아 들여야 하는 경우 그것이 무엇이든 알아서 구겨넣어 들어가게 디자인 하는것이다. 가령 ChangeCustomerName이란 함수를 제공하는 케이스라면 Customer 객체를 Assign 하는 것으로 이를 대체할 수 있고 근본적으로 새로운 Customer의 생성이나 각 프로퍼티의 변경을 Assign으로 단일화 할 수 있다. Data를 직접 들고 있는 객체 입장에선 받아들인 Customer객체를 어떻게 핸들링 해야 하는지 Determin 할 수 있기 때문이다(할 수 있게 디자인 해야 한다가 정확할 듯). Assign Operator 혹은 Function에서 Polymorphism을 이용하거나 데이터에 대한 추상화를 통해 나누어진 여러 기능을 쉽게 하나의 방법으로 구현가능할 것이다. Add와 Update가 다른 것 처럼 보여도 개념에 따라서는 동일하게 볼 수도 있다. 디자인의 차이다.
처음에 API에 대해선 예외를 적용했는데 그 이유는 당연하다. 그런 것은 낮은 레벨이기 때문이다. GendohSQL DBMS를 만들고 이것을 접근하는 Low API를 제공하려면 당연히 메뉴얼을 두껍게 만들어야 할 것이다. Exception 설명에만도 Appendix를 따로 할애해야 할지도 모른다. 허나 ADO혹은 더 높은 수준의 모델을 제공한다면 당연히 간단한 샘플로 끝낼 수 있어야 한다. 이는 인터페이스의 일관성은 물론이고 예외상황이 발생하여 프로그래머를 괴롭히는 것이 아니라 알아서 그것이 처리되어야 하고(밖으로는 차이가 없어야 한다) 사용법이 단순해야 한다는 점 등등을 요구할 것이다.
전자렌지의 경우 사용 설명서 없이도 많은 사람들이 잘쓴다. 30초를 돌리든 5분을 돌리든 사용방법이 동일하기 때문이다. 그리고 그 방법이 직관적이다. 가장 중요한 점은, 음식물이 핫바든 햄버거든 사용방법이 달라지지는 않는다. 한 병사의 죽음으로 개발된, 매우 어려운 물리적 현상으로 개발된 전자렌지가 가정마다 보급된 이유라 할 수 있다.
'개발&Development > 프로그래밍 일반' 카테고리의 다른 글
코더의 길 (1) | 2006.09.01 |
---|---|
어플리케이션 속도 튜닝 노가다 (0) | 2006.08.09 |
GC's problem of JavaScript (0) | 2006.07.18 |
가비지 컬렉팅, Loosely type binding, 기타 등등 (2) | 2006.07.08 |
PHP를 VS에서 개발하면 좋은점 (0) | 2006.06.13 |