メソッド名での結合の使用が悪い命名規則であるのはなぜですか？

Question

私のチームでは、数人のソフトウェアアーキテクトと緊密に協力しています。彼らは私たちのプロジェクトのすべての設計決定を承認し、いくつかのコードレビューなどを行います。

私たちのプロジェクトは主に、Symfony 2フレームワークを使用してPHPに実装されたバックエンド機能で構成されています。したがって、構文的には、コード、命名規則、およびプロジェクト構造は、Java =のようになります（Symfony 2はそのような構造を推奨します）Java固有の規則が（可能であれば）私たちのケースにも適用されるため、これについて言及します。

最近、彼らは私が非常に奇妙だと思うことを提案しました：すべてのメソッドはそれらの名前に結合を持たなければなりません。 getEntityOrNull、setValueOrExceptionなど.

そのような命名規則は私には非常に間違っていると感じますが、具体的にこれに挑戦する具体的な議論やオンライン記事/ページを思いつくことはできません。

私が思いついた唯一のものは：

そのような情報は、@returnや@throwsのように、メソッドのアノテーションに存在する必要があります
メソッド名での接続詞（「and」、「or」など）の使用は、通常、単一責任原則が適切に尊重されていないことを示唆しています

この命名規則に対する他の具体的な議論は何ですか？

Neil · Accepted Answer

彼らはおそらく名前の衝突のためにそうしています。 getEntityという名前のメソッドを2つ持つことはできないと思います。1つは例外をスローする可能性があり、もう1つはnullを返すものです。したがって、それに応じて名前を付ける必要があります。

その理由は、特定のクラスだけが実行できるような変更を行わない限り、同じメソッドを呼び出すさまざまな方法があることは嫌いです。

つまり、getValueOrNullが単にgetValueOrExceptionを呼び出して例外を捕捉し、その場合にnullを返す場合、これは呼び出し側が実行できます。これは、実際には何も役立たないメソッドでクラスを混乱させます。むしろ私はgetValueを好み、それが例外をスローすることを知っています。さらに良いことに、すべてのgetメソッドは例外をスローする可能性があり、プロジェクト全体で動作が均一になるようにnullを返さないか、逆にすべてがnullを返す可能性があることを知りたい必要な場合は、呼び出し元が例外をスローする必要があることを知っています。

しかし、あなたがそれを担当していないことも事実です。私のアドバイスはそれを育てることですが、ささいなことに汗をかかないでください。結局のところ、そのような命名規則の責任は、彼らがあなたのアドバイスを受け入れるかどうかに関係なく、彼らの肩にかかっています。

Karl Bielefeldt · Answer

論理積の使用は、SRPの違反を示すことがよくありますが、この場合は、2つの値（nullまたは "成功"）のいずれかである、貧乏人の代数データ型の戻り値を示しているだけです。値。

彼らは、型システムの弱点、つまりnullにできない型の欠如を補うために、ある種のハンガリー語表記を使用しています。つまり、関数がnullを返さないことを@returnアノテーションで指定する方法はありません。逆に、関数が@returnアノテーションで指定する方法はありません。 nullを返す可能性があります。

また、@throwsアノテーションはphpでは必須ではないので、アノテーションがないことは例外がないことを示すものではありませんが、スタイルガイドでアノテーションを必須にすることで解決できます。

あなたが使用している言語のそれらの制限を考えると、それは完全に不合理なスタイルではありません。

Cerad · Answer

私のコードでは、getEntity（）やgetEntityOrNull（）などの名前を持つメソッドペアを作成することがあります。名前は、予想される動作を明確にします。 getEntity（）がエンティティを検出しない場合、例外がスローされます。 getEntityOrNull（）はnullを返します。

これにより、呼び出し元のコードが少し明確になります。呼び出し側のコードにエンティティが必要な場合は、getEntityが役立ちます。エンティティが何らかのオプションのThingeeである場合、getEntityOrNullが最適なメソッドです。

同じことを単一のメソッドで行うこともできますが、その場合、負担の一部が呼び出し側プログラムに移ります。常にnullをテストする必要があるか、try/catchブロックが必要です。どちらの方法でも、メソッドが呼び出されるたびに複製する必要がある追加のコードです。

あなたの建築家がこの種のメソッドペアを使用していない場合は、はい、サフィックスの必要性について質問します。

SetValueOrExceptionメソッドを見たことがない。そのための良い一般的なユースケースを考えることはできません。

建築家に理由を尋ねることを検討するかもしれません。私が知っている人たちは、彼らの決定をいつでも説明してくれてうれしいです。多くの場合、非常に詳細な（そして時には苛立たしい）詳細です。

Eben · Answer

あなたの2つの議論は正しいです。しかし、それらが命名規則の決定を担当するものである場合、それがあなたが同意しないものであることをあまり気にしないようにしてください。

その間、これらのメソッドが実際にメンバー変数を直接設定または取得しない限り、「取得」および「設定」部分を使用しないように説得する必要があります。