Java設計上の決定を実施するための言語構造
OOP言語（特にJava）のどの構造で、設計上の決定と意図を強制できますか？
いくつかの例は、「final」キーワード、アクセス修飾子、テンプレートメソッド、おそらくインターフェイスだと思いますが、明らかに、網羅的なリストを作成するのに問題があります。
継承などの一部の構成要素は、この基準に適合しているように感じますが、その理由を正確に説明するのは難しいと思います。
[編集]列挙型、コンストラクター、定数、ジェネリック型など、さらにいくつかのメモを削除しました。すべてのものと同様に、例をリストするよりも理由を説明することが重要になります。
まず第一に、あなたの質問は、最近非常に重要なトピック、すなわち設計の決定/意図について考え、文書化するに当てはまると思います。
Javaでは、使用可能なキーワードを使用するだけでなく、実際に意図を表現する主なメカニズムは、アサーションおよびアノテーションです。これは、たとえば、事前/事後条件、不変条件、さらにはコードよりも高いレベルの抽象化が可能なプログラムの部分に関する仕様。他の誰かが書いたコードを読んだり維持したりする必要があり、その機能を理解できない場合に、この利点が明らかになります。
それに加えて、各キーワードにはもちろんいくつかのセマンティクスがあり、このため、それを使用するときに本質的に何らかの意図を表現します。実際のところ、言語の使用法でさえすでに設計上の決定であるとしても、任意の言語で事前定義されたキーワードを使用することは設計上の決定と見なされる可能性があると言えます。
重要な点は、「全体像」を失うことなく、コードやコメントですべての意図を表現することはできないということです。つまり、コードは間違いなくnot唯一の真実です。したがって、architectureと呼ばれる「構成」があります。これは、システムについて考えているときに作成している設計上の決定と意図を可視化し、文書化することを目的としています。確かに、それらはコードをより読みやすく、ナビゲートしやすくするためにコードで強制することができますが、コードは意図が述べられている主要な場所であってはなりません。