抽象クラスの一般的な名前を避ける方法は？

一般に、ファイルハンドルやUNIXプロセスなどを扱っていない限り、ルーチン名やクラス名の一部として「ハンドル」や「プロセス」などの単語を使用しないことをお勧めします。しかし、抽象クラスは、処理などの他に何かをどうしようとしているのか、実際には分からないことがよくあります。私の現在の状況では、ユーザーの受信ボックスにログインして、そこからのメッセージを処理する「EmailProcessor」があります。次のスタイルの問題が発生することに気づきましたが、これをより正確な名前にする方法は本当にわかりません。

• 派生クラスをクライアントとして扱い、実装する機能の一部によって基本クラスに名前を付けた方が良いですか？より意味を与えますが、is-aに違反します。たとえば、EmailAcquirerは、派生クラスのために取得しているため、適切な名前になりますが、派生クラスは誰のためにも取得しません。
• あるいは、派生クラスが何をするのか誰が知っているので、本当にあいまいな名前です。ただし、「Processor」は、ログインやIMAPの使用など、関連する多くの操作を実行しているため、まだ一般的すぎます。

このジレンマから抜け出す方法はありますか？

問題は、「これは何をするのか」という質問に実際に答えることができない抽象メソッドの場合により明白になります。答えは単に「クライアントが望むものは何でも」だからです。

問題は名前ではなく、1つのクラスに入れすぎていることです。

あなたの例のクラスでは、いくつかの部分は非常に具体的です（メールが取得される方法）。その他の部分は非常に抽象的です（メールで行うこと）。

継承よりも、別個のクラスを使用する方が適切です。

私は提案します：

• POPMailBoxDownloaderによってサブクラス化された抽象MessageIterator

• POPMailBoxDownloaderを所有し、メッセージを処理する別のクラス。

クラスの適切な名前が見つからない場合は、クラスのインラインコードドキュメントを作成します。クラスの目的を一文で説明しています。通常、この説明からクラスの適切な名前を取得できます。これは、抽象クラスにも役立ちます。

クラスの説明が「ユーザーの受信トレイにログインし、そこからのメッセージを処理する」である場合、クラス名として「InboxProcessor」をお勧めします。派生クラスに「ユーザーの受信トレイにログインし、スパムメールをスパムフォルダーに移動する」という説明がある場合、名前として「InboxSpamMover」を選択します。

「プロセッサ」のような総称名を使用しても、抽象クラスの総称的な目的を反映していれば、問題は発生しません。

1つまたは2つのセンテンスでクラスの目的を説明することに問題がある場合は、デザインに問題がある可能性があります。たぶん、クラスはあまりにも多くを行っており、単一責任原則に違反しています。これは抽象クラスにも適用されます。

フランク・ザッパを言い換えれば、それはそれであり、そのように命名されるべきです。あなたの例では、どのような処理が行われているかを十分に掘り下げていません。それはEmailToTroubleTicketProcessor、EmailGrammarCorrectorかEmailSpamDetector？

問題は、「これは何をするのか」という質問に実際に答えることができない抽象メソッドの場合により明白になります。答えは単に「クライアントが望むものは何でも」だからです。

それは正確には当てはまりません。あなたが抽象的なものに答えることができない質問は、「それはそれが何をするのですか？」です。それは実装固有であるためです。EmailSenderクラスにDeliveryStatus deliver(Email e)メソッドがある場合、実装が電子メールを受け取り、それを配信して、それがどのように行われたかについてステータスを返すという暗黙の契約があります。SMTPサーバーに接続するか、印刷してホーミングハトに縛られるかは関係ありません。アブストラクトはその約束を数値化するだけなので、実装は「そうです、私はそうします」と言うことができます。

なぜそのような言葉を使うのが悪いのか考えてください。それらは説明的ですか？クラスを説明する言葉はありますか？EmailBaseClass？それは、EmailManagerや類似のものを言うよりも説明的でしょうか？重要なのは、問題のクラスについての洞察を得ることです。したがって、適切な動詞または名詞を見つけます。コードを詩のように扱います。