web-dev-qa-db-ja.com

ユーティリティクラスとメソッドの命名規則と構造

ユーティリティクラスを整理して名前を付ける方法について何か意見はありますか？

コードの重複に遭遇したときはいつでも、ほんの数行のコードである可能性がありますが、それらをユーティリティクラスに移動します。

しばらくすると、多くの小さな静的クラスを取得する傾向があります。通常は1つのメソッドのみで、通常はクラスで肥大化するutility名前空間に配置します。

例：

ParseCommaSeparatedIntegersFromString( string )
CreateCommaSeparatedStringFromIntegers( int[] )
CleanHtmlTags( string )
GetListOfIdsFromCollectionOfX( CollectionX )
CompressByteData( byte[] )

通常、命名規則では、クラスに名詞として名前を付けるように指示されています。 HtmlHelper、CompressHelperのようなクラスがたくさんあることがよくありますが、それらはあまり有益ではありません。また、HtmlTagCleanerのように具体的にしようとしましたが、通常、ユーティリティメソッドごとに1つのクラスになります。

これらのヘルパーメソッドに名前を付けてグループ化する方法について何かアイデアはありますか？

naming-conventions
25
Bjorn

私は信じています複雑さの連続性があるため、対応する組織。次に例を示し、プロジェクトとユーティリティの複雑さに応じて選択し、他の制約に適応します。

  1. いくつかのメソッドを持つ1つのクラス（ヘルパーと呼ばれる）
  2. 1つのパッケージ（ヘルパーと呼ばれる）、いくつかのクラス（XXXHelperと呼ばれる）、各クラスにはいくつかのメソッドがあります。あるいは、クラスが適合する場合は、いくつかの非ヘルパーパッケージに分割することもできます。
  3. 1つのプロジェクト（ヘルパーと呼ばれる）、いくつかのパッケージ（XXXと呼ばれる）、各パッケージには...または、パッケージが収まる場合は、いくつかの非ヘルパーパッケージに分割できます。
  4. いくつかのヘルパープロジェクト（層ごと、使用中のライブラリごと、またはその他）...

各グループ化レベル（パッケージ、クラス）：

  • 意味の共通部分はグループ名の名前です
  • 内部コードはもはやその意味を必要としません（したがって、それらの名前はより短く、より焦点を絞っており、略語を必要とせず、フルネームを使用します）。

プロジェクトの場合、私は通常、スーパーパッケージ名で一般的な意味を繰り返します。理論的には私の好みの選択ではありませんが、クラスのインポート元のプロジェクトがIDE（Eclipse）に表示されないため、情報を繰り返す必要があります。プロジェクトは実際には次のようにのみ使用されます。 ：

  • 出荷単位：一部の成果物または製品には瓶がありますが、それを必要としないものには瓶がありません）、
  • 依存関係を表現するには：たとえば、ビジネスプロジェクトはWeb層ヘルパーに依存しません。プロジェクトの依存関係において、見かけの複雑さを改善したことを表明しました。またはそのような依存関係を見つけると、何かが間違っていることがわかり、調査を開始します...;また、依存関係を減らすことで、コンパイルとビルドを高速化できます..。
  • コードを分類し、より速く見つけるために：それが巨大な場合にのみ、私はプロジェクトの何千ものクラスについて話している

上記のすべては、静的メソッドだけでなく、動的メソッドにも適用されることに注意してください。これは、実際にはすべてのコードに対する私たちのグッドプラクティスです。

私はあなたの質問に答えようとしましたが（広い意味ではありますが）、別の考えを追加しましょう
（あなたがそれを求めなかったことを私は知っています）。

静的メソッド（静的クラスメンバーを使用するメソッドを除く）はコンテキストなしで機能するため、すべてのデータをパラメーターとして渡す必要があります。 OOコードでは、これは推奨される方法ではないことは誰もが知っています。理論的には、メソッドに最も関連するオブジェクトを探し、そのオブジェクト上でそのメソッドを移動する必要があります。覚えておいてください。 コード共有は静的である必要はありません、パブリック（またはその他の方法で表示）である必要があります。

静的メソッドを移動する場所の例：

  1. パラメータが1つしかない場合は、そのパラメータに。
  2. 複数のパラメータがある場合は、メソッドを：に移動するかどうかを選択します。
    • 最も使用されるパラメーター：複数のフィールドまたはメソッドが使用されているパラメーター、または条件付きパラメーターによって使用されているパラメーター（理想的には、一部の条件文はサブクラスのオーバーライドによって削除されます）...
    • いくつかのパラメータへのアクセスがすでに良好な1つの既存のオブジェクト。
    • その必要性のために新しいクラスを構築する

このメソッドの移動はOO純粋主義者にとっては思えるかもしれませんが、これは長期的には実際に役立つことがわかります（そして、アルゴリズムを変更するためにサブクラス化する場合に非常に役立ちます）。 Eclipseは（すべての検証を含めて）1分未満でメソッドを移動します。コードを探すとき、またはすでにコーディングされているメソッドを再度コーディングしない場合は、1分をはるかに超える時間がかかります。

制限事項：一部のクラスは、通常、制御不能であるために拡張できません（JDK、ライブラリなど）。これは変更できないクラスにメソッドを配置する必要がある場合の本当のヘルパーの正当化だと思います。

その場合、私たちの良い習慣は、ヘルパーにサフィックスを付けて、拡張するクラスの名前でヘルパーに名前を付けることです。 （StringHelper、DateHelper）。コードを配置するクラスとヘルパーの間のこの密接な一致により、プロジェクトの他の誰かがそのメソッドを作成したかどうかを知らなくても、数秒でそれらのメソッドを見つけることができます。

19
KLE

Helperサフィックスは適切な規則です。他の言語で使用されているためです（少なくともJavaでは、IIRC Rails使用してください）。

ヘルパーの目的は、メソッド名でtransportedであり、クラスをプレースホルダーとしてのみ使用する必要があります。たとえば、ParseCommaSeparatedIntegersFromStringは、いくつかの理由で不適切な名前です。

  • 長すぎる、本当に
  • 冗長です。静的に型指定された言語では、署名から推測されるため、FromStringサフィックスを削除できます。

についてどう思いますか：

CSVHelper.parse(String)
CSVHelper.create(int[])
HTMLHelper.clean(String)
...
8
dfa