4

一方はもう一方よりも優れていますか？

それも有効な質問ですか？

私は最近、MyObject.DoSomething()かなり古いものであり、それを行うためのサービス方法が好まれているとアドバイスされました。そうですか？

例：

public class Policy : ICancellable
{
    public void Cancel()
    {
        // Code to cancel working with 'this'.
    }
}

vs

public class PolicyCancellationService
{
    public void Cancel(Policy policy)
    {
        // Code to cancel working with 'policy'.
    }
}

それを行うサービス方法が使用されている場合-オブジェクトは任意の機能に責任があるのでしょうか、それとも単に馬鹿げているべきでしょうか？

4

3 に答える 3

3

私は最近、MyObject.DoSomething()かなり古いものであり、それを行うためのサービス方法が好まれているとアドバイスされました。そうですか？

どちらの方法も有効です。高い凝集度と低い結合度につながる方を選択する必要があります。

経験則として、あなたはそれをクラス自体に入れようとすることから始めるべきです、すなわちMyObject.DoSomething()。

次の場合にのみ、個別の（サービス）クラスを使用する必要があります。

  • の機能はDoSomething、の責任に直接関係していませんMyObject。関係のないメソッドをに入れると、凝集度MyObjectが低くなります。
  • MyObjectを実行するために必要なすべての情報を持っているわけではありませんDoSomething。この追加情報をに与えるとMyObject、結合度が高くなります。

この例では、キャンセルがポリシーの重要な機能であり、ポリシーにこの操作を実行するために必要なすべての情報が含まれている場合は、それをPolicyクラスに保持する必要があります。

それを行うサービス方法が使用されている場合-オブジェクトは任意の機能に責任があるのでしょうか、それとも単に馬鹿げているべきでしょうか？

まったく逆です。ドメインオブジェクト自体にできるだけ多くの機能を保持する必要があります。サービスは、複数のドメインオブジェクト間のアクティビティの調整に限定する必要があります。できれば、ビジネスロジックを含めないでください。

于 2012-07-25T02:15:15.753 に答える
0

私の意見では、あなたが使用している最初のアプローチは、抽象化、カプセル化などの主要な OOP プリンシパルに関するものだと思います。

ただし、2 番目のアプローチでは、設計変更の原則に焦点を当てて、インターフェイスの分離、依存関係の逆転など、アプリケーションの再構築/再テストと再展開を容易にします。

私の意見では、どの方法が優先されるかという時代遅れの方法はありません。

于 2012-07-24T20:05:00.757 に答える
0

おそらく、それを呼び出す最も重要な議論Serviceは、プロセス間通信が遅くなる傾向があるということです。これは通常、サービスを使用することによって意味されます。正しく管理しないchatty interfacesと、パフォーマンスが低下する可能性があります。

したがって、この境界を明示的にモデル化することは良いことです。これにより、人々は外部サービスを呼び出すときに存在する可能性のある問題を認識し、いつサービスを呼び出すかについてより適切な決定を下すことができます。

ロジックに外部依存関係がない場合は、おそらくオブジェクト内に残して、「サービス」とは呼びません。

于 2012-07-24T20:49:26.827 に答える