OOPのドキュメントでは、「getter」が計算を実行するかどうかの指定を避ける必要がありますか？

私の学校のCSプログラムでは、オブジェクト指向プログラミングについては一切言及していません。そのため、私はそれを補足するために独力で読んでいます。具体的には、Bertrand MeyerによるObject Oriented Software Constructionです。

Meyerは、クラスが実装に関する可能な限り多くの情報を隠すべきであると繰り返し指摘していますが、これは理にかなっています。特に、彼は、属性（つまり、クラスの静的で計算されていないプロパティ）とルーチン（関数/プロシージャ呼び出しに対応するクラスのプロパティ）を互いに区別できないと繰り返し主張しています。

たとえば、クラスPersonに属性がある場合、定数属性として定義されている場所またはのようなものに内部的に対応するageかどうかを表記法から判断Person.ageすることは不可能であると主張します。これは私にとって理にかなっています。ただし、彼は次のように主張し続けています。return current_year - self.birth_datereturn self.ageself.age

クラスの短い形式として知られるクラスの標準クライアントドキュメントは、特定の機能が属性または関数のどちらであるかを明らかにしないように考案されます。

つまり、クラスのドキュメントでさえ、「getter」が計算を実行するかどうかを指定することを避けるべきだと主張しています。

これ、私は従わない。この区別をユーザーに知らせることが重要になるのは、ドキュメントだけではありませんか？Personオブジェクトで満たされたデータベースを設計する場合Person.age、高価な呼び出しかどうかを知ることは重要ではないので、何らかのキャッシュを実装するかどうかを決定できますか？彼が言っていることを誤解していませんか、それとも彼はOOP設計哲学の特に極端な例ですか？

Meyerのポイントは、高価な操作がある場合にユーザーに伝えるべきではないということではありません。関数がデータベースにアクセスするか、ウェブサーバーにリクエストを送信し、コンピューティングに数時間かかる場合、他のコードはそれを知る必要があります。

ただし、クラスを使用するコーダーは、実装したかどうかを知る必要はありません。

return currentAge;

または：

return getCurrentYear() - yearBorn;

これら2つのアプローチ間のパフォーマンス特性は非常に小さいため、問題ではありません。クラスを使用しているコーダーは、実際にあなたが持っているものを気にするべきではありません。それがマイヤーのポイントです。

ただし、常にそうとは限りません。たとえば、コンテナにサイズメソッドがあるとします。それを実装できます：

return size;

または

return end_pointer - start_pointer;

または、次のようになります。

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

最初の2つの違いは実際には重要ではありません。しかし、最後のものはパフォーマンスに深刻な影響を及ぼす可能性があります。そのため、たとえばSTL .size()はそうO(1)です。サイズの計算方法は正確には文書化されていませんが、パフォーマンスの特性はわかります。

そのため、パフォーマンスの問題を文書化します。実装の詳細を文書化しないでください。std :: sortが適切かつ効率的に処理する限り、どのようにソートするかは気にしません。また、クラスは物事の計算方法を文書化するべきではありませんが、予期しないパフォーマンスプロファイルがあるものがある場合は、それを文書化します。

アカデミックまたはCSの純粋主義者の観点からは、当然ながら、機能の実装の内部についてドキュメントに何かを記述することは失敗です。これは、クラスのユーザーがクラスの内部実装について想定しないことが理想的だからです。実装が変更された場合、理想的にはユーザーが気付かないことはありません。この機能は抽象化を作成し、内部は完全に非表示のままにしてください。

ただし、実際のプログラムのほとんどは、Joel Spolskyの「漏れやすい抽象化の法則」に苦しんでいます。

「自明でない抽象化はすべて、ある程度漏れやすい。」

つまり、複雑な機能を完全にブラックボックスに抽象化することは事実上不可能です。そして、この典型的な症状はパフォーマンスの問題です。したがって、実際のプログラムでは、どの呼び出しが高価であり、どれがそうでないかが非常に重要になる可能性があり、優れたドキュメントにはその情報を含める必要があります（またはクラスのユーザーがパフォーマンスについて仮定することが許可されている場所とそうでない場所を言う必要があります） ）。

したがって、私のアドバイスは次のとおりです。実世界のプログラムのドキュメントを作成する場合は高価な呼び出しの可能性に関する情報を含め、パフォーマンスの考慮事項を保持する必要があるため、CSコースの教育目的のみで作成するプログラムの場合は除外します意図的に範囲外です。

特定の呼び出しが高価かどうかを書くことができます。ベターは、のような命名規則を使用してgetAgeすばやくアクセスし、loadAgeまたはfetchAge高価な検索のため。メソッドがIOを実行しているかどうかをユーザーに確実に通知する必要があります。

ドキュメントで提供するすべての詳細は、クラスが尊重しなければならない契約のようなものです。重要な動作について通知する必要があります。多くの場合、大きなO表記で複雑さを示します。しかし、あなたは通常短く、要点になりたいです。

Personオブジェクトで満たされたデータベースを設計する場合、Person.ageが高価な呼び出しであるかどうかを知ることは重要ではないでしょうか？

はい。

そのため、Find()関数を使用して呼び出しに時間がかかることを示すことがあります。これは何よりも慣習です。（それはユーザーに対するのかもしれませんが）、それは返す関数や属性にかかる時間は、プログラムに違いはありません、プログラマの間で存在があることを属性として宣言されている場合、それを呼び出すためのコストがあるべき、という期待は、低い。

いずれにせよ、何かが関数か属性かを推測するのに十分な情報がコード自体にあるはずなので、ドキュメントでそれを言う必要性は本当にありません。

この本の初版は、OOPの初期の1988年に書かれたことに注意することが重要です。これらの人々は、今日広く使用されている、より純粋なオブジェクト指向言語で作業していました。今日最も人気のあるオブジェクト指向言語であるC ++、C＃、Javaは、初期のより純粋なオブジェクト指向言語が機能する方法とはかなり大きな違いがあります。

C ++やJavaなどの言語では、属性へのアクセスとメソッド呼び出しを区別する必要があります。instance.getter_methodとには違いのある世界がありinstance.getter_method()ます。1つは実際に価値を獲得し、もう1つは獲得しません。

SmalltalkまたはRubyの説得力のあるより純粋なOO言語（この本で使用されているEiffel言語がそうであるように見える）を使用する場合、完全に有効なアドバイスになります。これらの言語は、暗黙的にメソッドを呼び出します。との間に違いはinstance.attributeありませんinstance.getter_method。

私はこの点に汗をかいたり、独断的に考えたりしません。意図は良いです-クラスのユーザーに無関係な実装の詳細を心配させたくない-しかし、それは多くの現代言語の構文にきれいに翻訳しません。

ユーザーとして、何かがどのように実装されているかを知る必要はありません。

パフォーマンスが問題になる場合は、クラス実装内ではなく、クラス実装内で何かを行う必要があります。したがって、正しいアクションは、クラスの実装を修正するか、メンテナーにバグを報告することです。

ルーチン/メソッドの複雑さのコストについてプログラマーに通知できないプログラマー向けのドキュメントには欠陥があります。

• 私たちは副作用のない方法を生み出そうとしています。

• メソッドの実行に以外の実行時の複雑さやメモリの複雑さがある場合O(1)、メモリまたは時間に制約のある環境では、副作用があると見なすことができます。

• メソッドがまったく予想外のことを行うと、最小限の驚きの原則に違反します。この場合、メモリの占有やCPU時間の浪費です。

あなたは彼を正しく理解していたと思いますが、良い点もあると思います。Person.age高価な計算で実装されている場合、ドキュメントでもそれを見たいと思います。繰り返し呼び出す（安価な操作の場合）か、一度呼び出して値をキャッシュする（高価な場合）かで違いが生じる可能性があります。確かにわかりませんが、この場合、マイヤーはドキュメントに警告を含めることに同意するかもしれません。

これを処理する別の方法は、名前が長い計算（などPerson.ageCalculatedFromDB）を行うことを意味する新しい属性を導入Person.ageし、クラス内にキャッシュされた値を返すことですが、これは常に適切であるとは限らず、複雑すぎるようです私の意見では、物事。

オブジェクト指向クラスのドキュメントには、多くの場合、クラスのメンテナーに設計を変更する柔軟性を与えることと、クラスのコンシューマーがその可能性を最大限に活用することとのトレードオフが含まれます。不変クラスは、特定の持っているであろう多くの特性があります場合は、正確な互いの関係（例えばLeft、RightおよびWidth整数座標グリッド整列長方形のプロパティ）、2つのプロパティの任意の組み合わせを格納するクラスを設計して3番目のプロパティを計算するか、3つすべてを格納するように設計することができます。インターフェースについて何も保存されているプロパティが明確にならない場合、クラスのプログラマーは何らかの理由でそうすることが役立つと判明した場合にデザインを変更できる可能性があります。対照的に、たとえば、プロパティの2つがfinalフィールドとして公開され、3 つ目のプロパティが公開されていない場合、クラスの将来のバージョンは常に「基底」と同じ2つのプロパティを使用する必要があります。

プロパティが正確な関係を持っていない場合（たとえば、プロパティがであるfloatかとdoubleいうよりもint）、クラスの値を「定義する」プロパティを文書化する必要がある場合があります。たとえば、LeftプラスWidthが等しいと想定されていてもRight、浮動小数点演算はしばしば不正確です。たとえば、Rectangle型を使用するa がFloat受け入れLeft、WidthコンストラクタパラメータLeftとしてas 1234567fおよびWidthas が指定されて構築されるとし1.1fます。float合計の最適な表現は1234568.125 [1234568.13と表示される場合があります]; 次に小さいのfloatは1234568.0です。クラスが実際に保存しLeft、Width、指定された幅の値を報告する場合があります。しかし、コンストラクタが計算した場合Rightには、渡されたに基づくLeftとWidth後で、および計算Widthに基づくLeftとRight、それはとして幅を報告する1.25fのではなく渡されたとして1.1f。

相互に関連する値の1つを変更すると、少なくとも1つの他の値が変更されることになるため、変更可能なクラスではさらに興味深いことがありますが、どちらが常に明確であるとは限りません。いくつかのケースでは、そのようなとしての「セット」単一のプロパティメソッドを避けるために最もよいが、代わりにどちらかの例にメソッドがありSetLeftAndWidth、またはSetLeftAndRightプロパティが指定されており、変更されているものを、または他のmakeがクリアに（例えばMoveRightEdgeToSetWidth、ChangeWidthToSetLeftEdgeまたはMoveShapeToSetRightEdge） 。

どのプロパティの値が指定され、どのプロパティの値が他から計算されたかを追跡するクラスがあると便利な場合があります。たとえば、「時間の瞬間」クラスには、絶対時間、現地時間、タイムゾーンオフセットが含まれる場合があります。このような多くのタイプと同様に、2つの情報があれば、3番目の情報を計算できます。知っている情報の一部は計算されましたが、重要な場合があります。たとえば、イベントが「17:00 UTC、タイムゾーン-5、現地時間12:00 pm」に発生したと記録され、後でタイムゾーンが-6であることが検出されたとします。UTCがサーバーから記録されたことを知っている場合、記録を「18:00 UTC、タイムゾーン-6、現地時間12:00 pm」に修正する必要があります。誰かが現地時間をオフクロックで入力した場合、「17:00 UTC、タイムゾーン-6、現地時間11:00 am」になります。ただし、グローバル時間とローカル時間のどちらを「より信頼できる」とみなすべきかを知らなければ、どの修正を適用すべきかを知ることはできません。ただし、レコードが指定された時刻を追跡している場合、タイムゾーンを変更すると、一方が変更されずに他方が変更される可能性があります。

クラス内の情報を非表示にする方法に関するこれらのすべてのルールは、クラスのユーザーのうち、内部実装への依存関係の作成を間違える人から保護する必要があるという前提で完全に理にかなっています。

クラスにそのような視聴者がいる場合、そのような保護を組み込むことは問題ありません。しかし、ユーザーがクラス内の関数への呼び出しを記述するとき、ユーザーは実行時の銀行口座であなたを信頼しています。

ここに私がよく見る種類のものがあります：

1. オブジェクトには、何らかの意味で古いかどうかを示す「修正」ビットがあります。十分に単純ですが、従属オブジェクトがあるため、「変更」をすべての従属オブジェクトを合計する関数にするのは簡単です。次に、下位オブジェクトのレイヤーが複数ある場合（同じオブジェクトを複数回共有する場合）、「変更された」プロパティの単純な「Get」が実行時間の健全な部分を占めることになります。

2. オブジェクトが何らかの方法で変更される場合、ソフトウェアの周りに散らばっている他のオブジェクトは「通知」される必要があると想定されます。これは、さまざまなプログラマーによって記述されたデータ構造、ウィンドウなどの複数のレイヤーで行われ、場合によっては保護が必要な無限の再帰で繰り返されます。それらの通知ハンドラーのすべてのライターが時間を無駄にしないように十分に注意している場合でも、複合相互作用全体が予測時間の非常に大きな実行時間の一部を使用することになり、単純に「必要」であるという仮定は快く行われます。

だから、私は外の世界にきれいで抽象的なインターフェースを提供するクラスを見たいのですが、私はそれらがどのような働きをしているのかを理解するためだけに、それらがどのように機能するかについていくつかの概念を持ちたいです。しかし、それを超えて、私は「少ないほど多い」と感じる傾向があります。人々はデータ構造に夢中になっており、より多くの方が優れていると考えています。パフォーマンスチューニングを行うとき、パフォーマンスの問題の普遍的な大規模な理由は、人々が教えられる方法で構築された肥大化したデータ構造への奴隷的遵守です。

それでは、図に進みます。

「計算するかどうか」や「パフォーマンス情報」などの実装の詳細を追加すると、コードとドキュメントの同期を維持するのがより困難になります。

例：

「パフォーマンスが高い」メソッドがある場合、そのメソッドを使用するすべてのクラスにも「高価な」ドキュメントを作成しますか？実装を変更して、もう高価にならないようにしたらどうでしょう。この情報もすべての消費者に更新しますか？

もちろん、コード管理者がコードのドキュメントからすべての重要な情報を取得するのは良いことですが、もう有効でないものを主張するドキュメントは好きではありません（コードと同期していない）

受け入れられた答えが結論に達すると：

そのため、パフォーマンスの問題を文書化します。

そして自己文書化されたコードは、ドキュメントよりも優れていると考えられている、メソッド名があること、次の必要があり、異常なパフォーマンスの結果を述べます。

まだPerson.ageですreturn current_year - self.birth_dateが、メソッドが年齢を計算するためにループを使用する場合（はい）：Person.calculateAge()