OOP 문서는 "getter"가 계산을 수행하는지 여부를 지정하지 않아야합니까?

우리 학교의 CS 프로그램은 객체 지향 프로그래밍에 대한 언급을 피하므로 직접 Bertrand Meyer의 객체 지향 소프트웨어 구성 을 보완하기 위해 독자적으로 독서를 해왔습니다 .

Meyer는 클래스가 가능한 한 구현에 대한 많은 정보를 숨겨야한다는 점을 반복해서 지적합니다. 특히 그는 속성 (즉, 정적, 계산되지 않은 클래스의 속성)과 루틴 (함수 / 프로 시저 호출에 해당하는 클래스의 속성)은 서로 구별 할 수 없어야한다는 주장을 반복적으로 주장합니다.

클래스가 예를 들어, Person속성을 가지고 age, 그는 여부, 표기법에서 얘기하는 것은 불가능해야한다는 주장 Person.age에 대응 내부적으로 같은 것으로 return current_year - self.birth_date하거나 return self.age, self.age일정한 속성으로 정의되어 있습니다. 이것은 나에게 의미가 있습니다. 그러나 그는 계속해서 다음을 주장합니다.

클래스의 짧은 형식으로 알려진 클래스의 표준 클라이언트 문서는 주어진 기능이 속성인지 함수인지를 나타내지 않도록 고안 될 것입니다.

즉, 그는 클래스 의 문서 조차도 "getter"가 계산을 수행하는지 여부를 지정하지 않아야한다고 주장합니다 .

나는 따르지 않는다. 문서가 사용자에게이 구별을 알리는 것이 중요한 장소가 아닙니까? Person객체로 채워진 데이터베이스를 디자인하려는 Person.age경우 비싼 통화 인지 여부를 아는 것이 중요 하지 않으므로 일종의 캐시를 구현할지 여부를 결정할 수 있습니까? 그가 말한 것을 잘못 이해 했습니까? 아니면 OOP 디자인 철학의 극단적 인 예일까요?

Meyer의 요점은 비싼 작업을 할 때 사용자에게 말해서는 안된다는 것입니다. 함수가 데이터베이스에 도달하거나 웹 서버에 요청하고 컴퓨팅에 몇 시간을 소비하는 경우 다른 코드에서이를 알아야합니다.

그러나 클래스를 사용하는 코더는 구현했는지 여부를 알 필요가 없습니다.

return currentAge;

또는:

return getCurrentYear() - yearBorn;

이 두 가지 접근 방식 간의 성능 특성은 매우 적으므로 중요하지 않습니다. 클래스를 사용하는 코더는 실제로 어떤 것을 신경 쓰지 않아야합니다. 이것이 요점입니다.

그러나 항상 그런 것은 아닙니다. 예를 들어 컨테이너에 크기 방법이 있다고 가정하십시오. 그것은 구현 될 수 있습니다 :

return size;

또는

return end_pointer - start_pointer;

또는 다음이 될 수 있습니다.

count = 0
for(Node * node = firstNode; node; node = node->next)
{
    count++
}
return count

처음 두 가지의 차이는 중요하지 않습니다. 그러나 마지막 것은 심각한 성능 저하를 초래할 수 있습니다. STL과, 예를 들어, 그 말한다 이유 .size()입니다 O(1). 크기가 어떻게 계산되는지 정확하게 설명하지는 않지만 성능 특성을 제공합니다.

따라서 : 성능 문제를 문서화하십시오. 구현 세부 사항을 문서화하지 마십시오. std :: sort가 적절하고 효율적으로 수행되는 한 내 항목을 정렬하는 방법에 관심이 없습니다. 또한 클래스는 계산 방법을 문서화해서는 안되지만 예상치 못한 성능 프로파일이있는 경우이를 문서화하십시오.

학계 또는 CS 순수 주의자 입장에서 볼 때, 기능 구현의 내부에 대한 내용은 문서에 설명하지 않은 것은 물론입니다. 클래스의 사용자는 클래스의 내부 구현에 대해 어떠한 가정도하지 않아야하기 때문입니다. 구현이 변경되면 이상적으로 사용자가 눈치 채지 못할 것입니다.이 기능은 추상화를 생성하고 내부는 완전히 숨겨져 있어야합니다.

그러나, 대부분의 실제 프로그램은 조엘 Spolsky`s 고통 "새는 추상화의 법칙" 라고하는,

"모든 사소한 추상화는 어느 정도 누설된다."

즉, 복잡한 기능의 완전한 블랙 박스 추상화를 만드는 것은 사실상 불가능합니다. 그리고 이것의 전형적인 증상은 성능 문제입니다. 따라서 실제 프로그램의 경우 호출 비용이 높고 비싸지 않은 것이 매우 중요 할 수 있으며, 좋은 문서에는 해당 정보가 포함되어야합니다 (또는 클래스 사용자가 성능에 대한 가정을 할 수있는 위치와 그렇지 않은 위치를 말해야 함). ).

따라서 내 조언은 : 실제 프로그램에 대한 문서를 작성하는 경우 잠재적으로 비싼 전화에 대한 정보를 포함하고 성능 고려 사항을 유지해야한다는 점을 고려하여 CS 과정의 교육 목적으로 만 작성하는 프로그램의 경우 제외하십시오. 의도적으로 범위를 벗어났습니다.

주어진 통화가 비싸거나 그렇지 않은 경우 쓸 수 있습니다. 더 나은이 같은 이름 지정 규칙을 사용하여 getAge신속하게 액세스 및 위해 loadAge또는 fetchAge고가의 조회에. 메소드가 IO를 수행하고 있는지 확실히 사용자에게 알리고 싶습니다.

문서에 제공하는 모든 세부 사항은 클래스가 준수해야하는 계약과 같습니다. 중요한 행동에 대해 알려 주어야합니다. 종종 O 표기법이 큰 복잡도 표시가 나타납니다. 그러나 일반적으로 짧고 요점을 밝히기를 원합니다.

Person 객체로 채워진 데이터베이스를 디자인 할 경우 Person.age가 비싼 호출인지 아닌지 아는 것이 중요하지 않습니까?

예.

그렇기 때문에 Find()호출하는 데 시간이 걸릴 수 있음을 나타내는 함수를 사용 하는 경우가 있습니다. 이것은 다른 것보다 더 많은 관습입니다. 이 프로그래머들 사이 있지만 그것을 반환하는 함수 나 속성에 걸리는 시간은 프로그램에 차이를 (이 사용자에 대한 수도 있지만)도하지 않습니다 이다 이 속성으로 선언 된 경우, 비용이해야 호출 할 수 있다는 기대가 낮은.

어쨌든 코드 자체에는 어떤 것이 함수인지 속성인지를 추론하기에 충분한 정보가 있어야하므로 문서에서 실제로 말할 필요가 없습니다.

이 책의 첫 번째 판은 1988 년 OOP 초기에 작성되었다는 점에 유의해야합니다. 이 사람들은 오늘날 널리 사용되는보다 순수한 객체 지향 언어를 사용하고있었습니다. 오늘날 가장 널리 사용되는 OO 언어 (C ++, C # 및 Java)는 초기의보다 순수한 OO 언어가 작동하는 방식과는 상당한 차이가 있습니다.

C ++ 및 Java와 같은 언어에서는 속성 액세스와 메소드 호출을 구별해야합니다. instance.getter_method와 사이에는 차이가 instance.getter_method()있습니다. 하나는 실제로 당신의 가치를 얻고 다른 하나는 그렇지 않습니다.

좀 더 순수하게 OO 언어, 스몰 토크 또는 루비 설득 (이 책에서 사용 된 에펠 언어 인 것 같습니다)에 대해 작업 할 때 완벽하게 유효한 조언이됩니다. 이러한 언어는 암시 적으로 메소드를 호출합니다. instance.attribute와 사이에는 차이가 없습니다 instance.getter_method.

나는이 점을 땀내거나 너무 독단적으로 받아들이지 않을 것이다. 의도는 좋으며 클래스의 사용자가 관련이없는 구현 세부 사항에 대해 걱정하지 않기를 원하지만 많은 현대 언어의 구문으로 명확하게 번역되지는 않습니다.

사용자는 무언가가 어떻게 구현되는지 알 필요가 없습니다.

성능이 문제라면 클래스 구현 내부에서가 아니라 무언가를 수행해야합니다. 따라서 올바른 조치는 클래스 구현을 수정하거나 관리자에게 버그를 제출하는 것입니다.

루틴 / 방법의 복잡성 비용에 대해 프로그래머에게 알리지 못하는 프로그래머 중심의 문서에는 결함이 있습니다.

• 우리는 부작용이없는 방법을 생산하려고합니다.

• 방법의 실행 시간 복잡도 및 / 또는 이외의 메모리 복잡도를 실행 한 경우 O(1), 메모리 - 시간 또는 제약 환경에서 부작용이 고려 될 수있다 .

• 방법이 완전히 예기치 않은 작업을 수행하는 경우 ( 최소한의 놀라움 의 원칙은 이 경우 메모리를 낭비하거나 CPU 시간을 낭비하는 경우) 위반됩니다.

나는 당신이 그를 올바르게 이해했다고 생각하지만, 나는 또한 당신이 좋은 지적을 가지고 있다고 생각합니다. 경우 Person.age고가의 계산으로 구현되어, 나는 내가 너무 설명서에이를보고 싶은 생각합니다. 반복적으로 호출하거나 (비용이 저렴한 경우) 한 번 호출하고 값을 캐싱하는 것 (비용이 많이 드는 경우) 사이에 차이를 만들 수 있습니다. 확실하지는 않지만이 경우 Meyer 가 문서에 경고를 포함해야한다는 데 동의 할 것입니다.

이 처리하는 또 다른 방법은 이름이 긴 계산 (예 일어날 수 있음을 의미 새로운 속성 소개 할 수 있습니다 Person.ageCalculatedFromDB후 한)와 Person.age클래스 내에서 캐시 된 값을 반환을하지만,이 항상 적절하지 않을 수 있으며, 복잡하게 보인다 내 의견으로는.

객체 지향 클래스에 대한 문서화는 클래스 관리자에게 클래스 유연성을 부여하여 클래스의 소비자가 잠재력을 최대한 활용할 수있게하는 것 사이의 트레이드 오프와 관련이 있습니다. 불변의 클래스는 어떤 것 곳의 호텔이 경우 정확한 (서로의 관계를 예를 들면 Left, Right및Width정수 좌표 격자 정렬 된 사각형의 속성)의 경우 두 속성의 조합을 저장하도록 클래스를 설계하고 세 번째 속성을 계산하거나 세 가지를 모두 저장하도록 설계 할 수 있습니다. 인터페이스에 대해 어떤 속성이 저장되어 있는지 명확하지 않으면 클래스의 프로그래머가 어떤 이유로 도움이 될 경우 디자인을 변경할 수 있습니다. 반대로, 예를 들어 두 속성이 final필드 로 노출되고 세 번째 속성이 필드 로 노출 되지 않으면 클래스의 향후 버전에서는 항상 "기본"과 동일한 두 속성을 사용해야합니다.

(그들은이기 때문에 예를 들어 속성 정확한 관계가없는 경우 float또는 double이 아닌 int), 다음 속성이 클래스의 값을 "정의"문서에 필요할 수 있습니다. 예를 들어, Left더하기 Width가 같 더라도 Right부동 소수점 수학은 정확하지 않은 경우가 많습니다. 예를 들어, 가정 Rectangle유형을 사용하는이 Float수용 Left및 Width생성자 파라미터로하여 구성된다 Left으로 주어 1234567f와 Width같이 1.1f. float합계 의 최상의 표현은 1234568.125입니다 [1234568.13으로 표시 될 수 있음]. 다음으로 작은 float것은 1234568.0입니다. 클래스가 실제로 저장 Left하고Width지정된대로 너비 값을보고 할 수 있습니다. 그러나, 생성자는 계산 된 경우 Right인 - 통과를 기반으로 Left하고 Width이상 및 계산 Width에 근거 Left하고 Right, 그것으로 폭을보고하는 것 1.25f보다는 건네로 1.1f.

변경 가능한 클래스를 사용하면 상호 관련 값 중 하나를 변경하면 적어도 서로 변경되는 것을 의미하기 때문에 상황이 훨씬 더 흥미로울 수 있지만 항상 어느 것이 분명하지는 않습니다. 어떤 경우에는 같은있는 "설정"하나의 속성 방법을 피하기 위해 가장 좋은, 대신 중 예에 방법이있을 수 있습니다 SetLeftAndWidth또는 SetLeftAndRight속성이 지정되고 있으며, 변화하는 것, 또는 다른 make가 취소를 (예를 들어 MoveRightEdgeToSetWidth, ChangeWidthToSetLeftEdge또는 MoveShapeToSetRightEdge) .

때로는 어떤 속성 값이 지정되었고 다른 속성에서 계산되었는지 추적하는 클래스를 갖는 것이 유용 할 수 있습니다. 예를 들어 "시간 순간"클래스에는 절대 시간, 현지 시간 및 시간대 오프셋이 포함될 수 있습니다. 많은 이러한 유형과 마찬가지로, 두 가지 정보가 주어지면 세 번째 정보를 계산할 수 있습니다. 어느 것을 알고그러나 일부 정보는 계산되었을 때 때때로 중요 할 수 있습니다. 예를 들어, 이벤트가 "17:00 UTC, 시간대 -5, 현지 시간 12:00 pm"에 발생한 것으로 기록되고 나중에 시간대가 -6이어야 함을 발견했다고 가정하십시오. UTC가 서버에서 기록되었다는 것을 알고 있으면 레코드는 "18:00 UTC, 시간대 -6, 현지 시간 12:00 pm"으로 수정해야합니다. 누군가 시계에서 현지 시간을 입력 한 경우 "17:00 UTC, 시간대 -6, 현지 시간 오전 11시"여야합니다. 그러나 전 세계 또는 현지 시간을 "보다 믿을만한"것으로 간주해야하는지 여부를 알지 못하면 어떤 수정을 적용해야하는지 알 수 없습니다. 그러나 레코드가 지정된 시간을 추적 한 경우 시간대를 변경하면 다른 시간대를 변경하는 동안 시간대를 변경할 수 있습니다.

클래스에서 정보를 숨기는 방법에 대한 이러한 모든 규칙은 내부 구현에 대한 종속성을 생성하는 실수를 저지르는 클래스 사용자 중 누군가를 보호해야한다는 가정하에 완벽하게 이해됩니다.

학급에 그러한 청중이 있다면 그러한 보호를 구축하는 것이 좋습니다. 그러나 사용자가 클래스의 함수를 호출하면 실행 시간 은행 계좌로 사용자를 신뢰합니다.

여기 내가 많이 보는 것들이 있습니다.

1. 개체는 어떤 의미에서 오래된 것인지를 나타내는 "수정 된"비트를 가지고 있습니다. 충분히 간단하지만 하위 개체가 있으므로 "수정 된"함수를 모든 하위 개체를 요약하는 함수로 만드는 것이 간단합니다. 그런 다음 하위 오브젝트의 여러 계층이있는 경우 (때로는 동일한 오브젝트를 두 번 이상 공유하는 경우) "수정 된"특성의 단순 "Get"은 실행 시간의 상당한 부분을 차지할 수 있습니다.

2. 어떤 방식으로 객체가 수정되면 소프트웨어 주위에 흩어져있는 다른 객체에 "알림"이 필요하다고 가정합니다. 이것은 서로 다른 프로그래머가 작성한 여러 계층의 데이터 구조, 창 등에서 발생할 수 있으며 때로는 보호해야 할 무한 재귀에서 반복 될 수 있습니다. 이러한 알림 처리기의 모든 작성자가 시간을 낭비하지 않도록 합리적으로주의를 기울이더라도 전체 복합 상호 작용은 예측할 수없고 고통스럽게 많은 실행 시간을 사용하여 끝날 수 있으며, 단순히 "필수"라는 가정은 엄청나게 만들어집니다.

그래서 저는 외부 세계에 깔끔하고 추상적 인 인터페이스를 제공하는 클래스를보고 싶지만 저를 구하는 작업을 이해하기 위해서만 어떻게 작동하는지에 대한 개념을 갖고 싶습니다. 그러나 그 이상으로, 나는 "더 적을수록"더 느낀다. 사람들은 데이터 구조가 너무 좋아서 더 나은 것으로 생각하고, 성능 조정을 수행 할 때 성능 문제의 보편적 인 큰 이유는 사람들이 가르치는 방식으로 구축 된 부풀린 데이터 구조에 종속되는 것입니다.

그러니 알아봐

"계산 여부"또는 "성능 정보"와 같은 구현 세부 사항을 추가하면 코드와 문서를 동기화 하기가 더 어려워집니다 .

예:

"고성능"메서드가 있다면이 메서드를 사용하는 모든 클래스에도 "고가"문서화를 원하십니까? 구현을 더 이상 비싸지 않게 변경하면 어떻게 될까요? 이 정보를 모든 소비자에게도 업데이트 하시겠습니까?

물론 코드 관리자가 코드 문서에서 모든 중요한 정보를 얻는 것이 좋지만 더 이상 유효하지 않은 것을 주장하는 문서는 좋아하지 않습니다 (코드와 동기화되지 않음)

받아 들여진 대답이 결론에 도달하면 :

따라서 : 성능 문제를 문서화하십시오.

및 자기 문서화 된 코드는 문서보다 더 나은 것으로 간주됩니다 는 메소드 이름이 그 다음 해야 이상한 성능 결과를 상태.

그래서 여전히 Person.age위한 return current_year - self.birth_date그러나 방법 (예) 나이를 계산하는 루프를 사용하는 경우 :Person.calculateAge()