naming-conventions - ネーミングの流行を処理する最良の方法はありますか?

Question

昨年、私のチームのコード ベースに少し取り組んでいると、命名規則が着実に進歩していることに気付きました。

たとえば、何かをするのに役立つクラスであることを表すために名前が付けられているクラスがたくさんあります。

ここに私が見つけたものがあります：

MyClassUtil
MyClassFactory
MyClassHelper
MyClassManager
MyClassService

時間が経つにつれて、人々は比較的同じものに対して命名規則を考え出すようになり、すべてに一貫した方法で名前を付ける代わりに、すべての規則を少しずつ持つコードベースになってしまうようです。すべての新しいものは、最新の流行の命名規則に基づいて命名されているため、当時流行していた規則によって、コードのビットの時代をほぼ知ることができます.

この傾向に対処する最善の方法は何ですか？それは本当に問題ですか？これらの命名の流行が流行するにつれて、最新の流行を使用する必要がありますか? 新しい命名規則ですべての既存のアイテムの名前を変更する必要がありますか? それとも、多様性を避けられないものとして受け入れる必要がありますか？

Answer 1

それらは流行のようには見えません...これらの名前はすべてクラスの目的を暗示しており、それらの目的は異なります。プログラミングでは、すべてが名前に含まれており、非常に慎重に選択する必要があります。多様性はエスケープする必要はありません。クラスの目的が異なるため、名前も異なります。

MyClassUtil - 付属していない MyClass を操作するためのユーティリティ。MyClass はあなたが使用しているライブラリに属しているかもしれませんが、それでいくつかの高レベル関数を使用することが多く、それらを配置する場所が必要です。

MyClassFactory - 抽象化された方法で MyClass のインスタンスを作成します。これにより、MyClass インスタンスを必要とするコードを記述できます。MyClassFactory からこれらの新しいインスタンスを取得できます。これにより、Factory を将来変更して、MyClass のさまざまな特定の実装を提供できるようになります。おそらく単体テストでは、Factory はダミー/モック MyClasses を提供するだけです。これは、ファクトリを使用するクラスを変更する必要なくテストできることを意味します。ファクトリを変更するだけで、テスト対象のクラスを分離できます。

MyClassHelper -わかりました。同意するかもしれません。おそらくこれはより具体的です。MyClass を支援するために何かを行いますが、それは何でしょう。これは MyClassUtil に少し似ているかもしれません。しかし、おそらく MyClassUtil は MyClass で動作する一般的な関数ですが、ヘルパーは MyClass の特定のインスタンスで初期化され、その 1 つのインスタンスで操作を実行できます。支援したい MyClass ごとに新しいヘルパーが必要です。

MyClassManager - おそらく、これは MyClass インスタンスのプールを処理し、それらを格納または調整します。例えば。CommunicationsManager では、このクラスは、イーサネットやシリアルなどのポートまたは接続との通信を処理するクラスと、パケットを転送できるように送信される通信プロトコルを処理するクラスとの配線を処理します。それらのパケットのメッセージ。

MyClassService - 特定の郵便番号をグリッド参照に変換するなど、サービスが処理を実行します。通常、サービスは多くの特定のものに解決できます。郵便番号の例では、このクラスには、さまざまな Web サイトと通信して変換を行うことができる実装が含まれている可能性があります。

Answer 2

これが普及している場合、チームはオブジェクト指向デザインの研究に時間を費やす必要があります。評判の高いオブジェクト指向フレームワークのソースコード、デザインパターンに関する本、またはEvansの「ドメイン駆動設計」などの本を読んでください。

「Util」と「Manager」は、多くの場合、不十分な設計の症状です-「コードの臭い」。特別なコンテキスト（Railsアプリ）の外にある「ヘルパー」も、しっかりと定着しています。

「ファクトリ」と「サービス」には正確な技術的意味があります。コードをチェックして、それらのデザインパターンに準拠しているかどうかを確認できます。

一般的な解決策は、チームと一緒に座って、これらの命名スキームから期待されるメリット、意味のあるものとそうでないものについて明確に話し合い、その後数か月にわたってリファクタリング手法を適用して段階的に廃止することです。あなたが決めた名前はコードの臭いです。

命名は重要です。それは軽視されるべきではなく、主観的な問題でもありません。確かに、特定の命名の問題には、多くの場合、複数の正解があります。ただし、以前の選択と一致する回答はほとんどありません。これが重要です。

Answer 3

上記のクラスの名前はすべて、オブジェクト指向の原則からの顕著な逸脱を示しています。「MyClassUtil」または「MyClassService」が何をするかを知る方法はありません。それは何でもかまいません。クラスの命名は具体的である必要があり、クラスの実際の機能を明確に伝える必要があります。これらのどれもしません。この傾向に対処する最善の方法は、オブジェクト指向プログラミングのスキルを磨き、それに応じてクラスに名前を付けることです。

さて、これらの例は、これらのクラスが表すアプリケーション アーキテクチャ内の機能を示している可能性があります。「MyClass」の使用は、実行時により決定的な何かの単なるプレースホルダーです。その場合、私は表示しません。これらは命名の流行としてではなく、アプリケーションの基礎となるアーキテクチャーの大まかなヒントとともに、クラス自体の機能を説明する指標としてのものです。

Answer 4

名前をより適切な名前に変更し、各クラスが明確な責任を持つようにコードをリファクタリングすることをお勧めします。使用する名前の種類を知るには、意味のある名前に関するTimOttingerの記事を読んでください。

クラスが1つのことだけを行う場合、通常、わかりやすい名前を付けるのは簡単です。「マネージャー」などの言葉は曖昧であり、クラスが非常に多くの無関係なことを行う責任があることを示している可能性があり、クラスが何をするかを簡単な名前で説明することはできません。クラスの名前を見ただけでクラスが何をするかを知ることができれば、そのクラスには良い名前が付いています。

Answer 5

静的分析ツールを使用して、一連のスタイルと整合性ルールを適用してみませんか？

.NETの世界にいる場合、MicrosoftはStyleCopと呼ばれるツールを提供しています

Answer 6

あなたが与えるクラス名の例では、「MyClass」は実際のクラス名を表しているので、「PersonnelRecordUtil」や「GraphNodeFactory」などの名前が実際に表示されていますか? MyClassFactory は、クラスの実際の名前としては非常に不適切です。

Answer 7

工場やサービスが特定の流行にどのように適合するかはよくわかりません...

Factory は設計パターンであり、クラスが実際に Factory である場合、それは完全に適切な名前です。

クラスが Windows サービスの場合、それをサービスと呼ぶことの何が問題になっていますか?

名前変更のリファクタリングをすべて実行したくてもコストがかかりすぎると思わない限り、問題はありません。