メソッドを戻り値の型または引数で整理しますか？

Question

私はこの問題を明確に表現するのに苦労しています。異なるタイプの場合、異なるタイプに変換するために関係をトラバースするメソッドをどのように編成するかに関して、どのような考慮事項がありますか？ Car、GarageとParkingPass：正確なモデリングについて寛容でありながら

、例えば、すべての相互間の多対多の関係を持つ3つのクラスがあると想像。

• 車が複数の駐車場を持つことができますが
• 駐車場のパスは車が複数台
を使用することができ、同じパスが複数のガレージ
• 同じパスに使用することができ
• ガレージに駐車することができます渡します

私は擬似Java構文を使用しますが、これは言語固有のものではないと思います。誰かが中に駐車することができます車をガレージ何かを見つけたい場合は、以下の方法が同等に有効なようです：車を与えられたガレージのGarageオブジェクトをお願い

Car { 
    Collection<Garage> getGarages(); 
} 

：

はCarそのガレージのオブジェクトを尋ねます：

Garage { 
    Collection<Garage> for(Car); 
} 

いずれかの方法で、オブジェクトは、リレーションシップ・マッピングを解決するためにParkingPassクラスを通じて移動する必要がありますので、一つのオブジェクトと他の間には直接の変換はありません。

JavaのArrays.asList（クラスとほぼ同じ型の引数をとり、別のクラスを生成します）のような例を見ると、Car.getGarages()メソッドを実行することが正当だと思われます。代わりに、GuavaのImmutableList.ofを見ると、これは "異なる"型の引数をとり、クラスと同じ型の値を返します。

メソッドを配置する場所を決定する方法をガイドするベストプラクティスはありますか？考えられる解決策には、次のものがあります。

1. メソッドの戻り値の型と一致するクラスにメソッドを配置します。これは、クラスが他のオブジェクトを自分自身に変換する方法を「知っている」ことを意味します。
2. メソッドの引数と一致するクラスにメソッドを配置します。これは、クラスが自分自身を他のオブジェクトに変える方法を「知っている」ことを意味します。
3. 、一つのオブジェクトを消費するユーティリティクラスを紹介し、いくつかのドメイン固有の操作を行い、これらの方法のすべてのための共通の失敗は、順列の問題である別の

を返します - あなたのクラスは非常に連結グラフ方の溶液を形成した場合大規模に成長することが選択されています。

Answer 1

それが自然だ - OOの観点から - 。それはで駐車することができますどのようなガレージCarを依頼するOTOH、それはでないそれが照会されているGarageインスタンスを必要とするため、そのことについてGarageを聞いて非常に自然他のガレージについての知識がある。

Answer 2

ここではより良い解決方法を提案していますが、セマンティクスによって、実際にモデルについてどのように考えるかが決まります。また、両方のメソッドを紹介し、実際の値を他のメソッドに求める方法もあります。ですから、どのメソッドが実際の情報源であるかという問題です。

この具体的なケースでは、モデルParkingPassをクラスとして使用しないと、なぜそれ自体に含まれる情報を実際に提供するのでしょうか。

class ParkingPass { 
    Collection<Garage> for(Car); 
} 

これは私のためにここで行うべき正しいことと思われます。

Answer 3

メソッドをどのように構成するのかという問題は、「戻り値型」、「引数型」などの点で答えられるとは思いません。むしろ、メソッドが属している場所一般的）は常にコードによって表されるモデルに依存するので、自分自身に質問する必要がある質問は次のとおりです。実装しようとしているモデルをコードでどのように表現するのがベストでしょうか？。あなたがこの質問をしたのを見て、これはおそらくあなたの目標です。私はすでにこれに同意していると思います。しかし、私は詳しく説明しましょう。

あなたの車とガレージであなたの例を見てみましょう。だから私たちは車が駐車できる駐車場が何であるかを知りたがっています。車は駐車場に駐車することができますか？私は最終的に車を収容するかどうかはガレージの決定であると言います。車がそのガレージに駐車することができるかどうかを決定する方法をガレージクラスに入れるのは意味があります。これがどのような状況にあるかは、パーキングパス、車のナンバープレート、色などがガレージの唯一の関心事であるかもしれません。

今、ガレージへのアクセスが許可されているかどうかに影響する可能性のあるパーキングパスがあります。これは駐車場で駐車場をガレージに駐車することが許可されているかどうか、ガレージクラスに入れた検証方法がパーキングパスのクラスに入るかどうかを判断することができますか？いいえ、駐車場は車がガレージに駐車することが許可されているクレームしかできませんが、この請求はガレージの同意を得てのみ有効であるため、ガレージクラスの検証方法は問題ありません。

もちろん、パーキング・パスにその条件について照会することは有用であり、これを実装することは、2つの構成が異なるものを表すので、検証メソッドをガレージ・クラスに入れることと矛盾しません。それを認識して。それでは、パーキングパスの条件をどのように実装しますか？再び、これはパーキングパスのモデルに依存する。パーキングパスは、限定された有限のガレージセットにアクセスできますか？次に、パスにはCollectionのガレージが含まれています（たとえば、Set）。しかし、おそらくパーキングパスはガレージの特定の財産、例えばその場所、またはそれが所有する会社に基づいてガレージへのアクセスを許可するかもしれない。その後、Collectionは、このパーキングパスの条件を表すものではありません。たとえあなたが駐車場の条件が適用されるすべてのガレージを集めることができたとしても（つまり、特定の場所内のすべてのガレージは有限集合でしかない）、Collectionは駐車場の条件を表すものではなく、これは、新しいガレージが建てられるか、またはガレージが閉鎖されるとすぐに関連します。この場合、駐車場の条件を表現するためのより良い方法は、単にPredicate<Garage>です。確かに、これは、この車が駐車する可能性があるすべてのガレージを繰り返し処理することはできません（最終的にはガレージが決定し、「おそらくは」ということを覚えておいてください）が、これはコードの欠点ではありません。私たちがコードで表現するモデルに固有のものです。

駐車場モデルは単なる単純な例であり、この質問をするときに気づいた問題はもっと複雑ですが、あなたが求めた質問は一般的に答えられるとは思わないので、私は駐車場モデルに答えようとしました。