状況は次のとおりです。同じインターフェースを実装する 2 つのクラスがあり、両方のクラスが連携してビジネス プロセスを完了します。
たとえばnetworkUserManager、メソッドを持つlocalUserManager実装します。 を取得する要求をキューに入れ、応答を返します。 キューから要求を取得し、何らかのデータベースでユーザー情報を見つけて、ユーザー データで応答します。IUserManagergetUser()networkUserManager.getUser()UserlocalUserManager.getUser()
これと似たようなことが行われているのを見たとき、これは設計が悪いのではないかと思わずにはいられませんでした。これは悪い設計ですか?そうでない場合、このようなことをするのが良い考えである例は何ですか?
それは私にはかなり悪いにおいがします。もちろん、異なるクラスが同じ名前のメソッドを持っている場合もありますが、両方が同じインターフェースを実装している場合は、同じことを行うと想定されます。ここで彼らは反対のことをしています！
おそらくそれは私の側の想像力の欠如ですが、なぜそれが良い考えになるのか理解できません。
デコレータパターンを説明しているようです。この場合、はNetworkUserManagerによって提供される機能に加えて追加の機能を提供しますLocalUserManager。使用している言語はわかりませんが、このパターンはjava.ioパッケージ全体に表示されます。
一方、LocalUserManager.getUser()キューからメッセージをプルするという説明は間違っているように見えます。これは、動作の逆NetWorkUserManagerです。を呼び出す他の何か（おそらく）に応答してLocalUserManager、データベースにアクセスした場合、これは適切なデコレータであると見なします。NetworkUserManagerServicegetUser()
networkUserManagerネットワーク全体からデータを取得する必要があるとします。そのため、リクエストをその情報を持つネットワークサーバーへのリクエストキューに入れ、localUserManagerサーバー上に座って実際にそのリクエストを処理します。ソフトウェアのシングルマシンバージョンを作成する場合、理由もなく開発者がその領域を書き直すのに時間を費やすよりも、ほぼ同じバージョンを維持する方がおそらく良いでしょう。
最初のレベルでは、それは基本的な生産-消費キューのように見えると思います。
私があなたを正しく理解していれば、あなたには待ち行列があります。プロセスAは、名前に関係なく、物事をキューに入れます。プロセスBは、名前に関係なく、キューから物を取り出して処理します。
次に、そのプロセスにマイナーな複雑な要素を追加します。Aは、キューの処理結果を通知する必要があります。大きな問題ではない。
ここに悪い習慣があるとすれば、それはクラスの命名と共通のインターフェースの使用だと思います。彼らは同様のタスクを実行しているようには見えません。おそらく、両方が同じクラス/オブジェクト（このキュー）で動作しているようです。
悪臭。インターフェイスは、実装クラスが従うことに同意するコントラクトを定義します。デコレータ パターンの場合、同じコントラクトを実装する複数のクラスがあるため、複数のクラスをまとめてスナップできます。ここでそのようなことが起こっているかどうかは明らかではありません。
ここでの問題は、「getUser」が意味のある抽象化であるかどうか、および階層化されたアクセスのように見えるロジックをカプセル化するかどうかです。私はそれが照らす以上のものを隠すと主張したい. たとえば、java.io デコレータは (ほとんどの場合) 任意の順序でスナップできます。あなたが説明している階層型アクセスを考えると、 LocalManager.getUser(NetworkManager.getUser()) は理にかなっていますが、 NetworkManager.getUser(LocalManager.getUser()) は理にかなっていません。
これをアンチパターンと呼ぶことはしませんが、インターフェイスの実装は非常に貧弱です。（このスレッドで言及されている「悪臭」？）
これらの2つのgetUser（）メソッドは、同じ戻り値と引数を持たないものの、「セマンティック」インターフェースが明らかに異なるため、異なる名前を付ける必要があるとさえ主張します。