1

質問の要点に飛び込む前に、これは純粋に理論的な質問であることに注意してください。私は実際的な理由でこれには興味がありません。このタイプの状況をどのように処理するかについての基礎となるOOP理論に興味があります。

私が取り組んでいるプロジェクトには、密接に関連する2つのクラスがあります。1つは一般的な「user」クラスです。もう1つはサブクラス化されており、特定のユーザーが使用する追加機能を追加します。一般的な例として、「モデレーター」クラスを考えてみてください。

子が呼び出しても意味がない、ユーザークラスで使用可能なパブリックメソッドを処理するにはどうすればよいですか？

たとえば、User :: getUserWithId（id）を呼び出すことは完全に理にかなっています（このメソッドはDBからデータを取得し、そのデータを使用してユーザークラスを初期化して返します）。モデレータークラスでそのメソッドを使用することは（もしあれば）あまり意味がありません。

無視する必要があります。ユーザーがmoderator::getUserWithId（id）を呼び出した場合でも、ユーザーは要求どおりのユーザーを取得しています。メソッド名に関係なく、モデレーターを返すためにオーバーライドする必要がありますか？それとも、私がよく知らないOOPランドに、通話を「ブロック」できるものがありますか？

4

2 に答える 2

1

昨日、どういうわけか迷子になったという返答を残しました。@Joe Alfanoには、あなたの「理論的」な質問や特定の質問に対処する非常に優れた説明があると思います。それに加えて、私の意見では、問題の原因の1つは、ドメインオブジェクトでデータベースアクセスを行っていることである可能性があります。一般に、やむを得ない理由がない限り、これは良い習慣ではありません。そのデータベースアクセスをデータアクセス層（DAL）などの別の層に削除すると、この問題は解消されます。クラスにUser::getUserWithId（id）のものはなく、DALで処理されます。好き

class UserDao {
     User getById(id)

}

Class ModeratorDao {

     Moderator getById(id)
}

DALのようなアプローチを採用する場合は、コードをリファクタリングする方法もありますが、これは別の方法です。

于 2013-01-22T15:30:17.027 に答える
1

基本クラスにサブクラスで意味をなさないメソッドがある場合、継承関係を介してこれらのクラスをモデル化する必要があるかどうかを再評価する必要があると思います。サブクラスの基本クラスのメンバーを非表示にする必要があることは、継承関係を介してこれをモデル化することに問題があることを示す危険信号です。

継承関係は、「isa」関係を示す必要があります。この例では、モデレーターオブジェクトは「ユーザーオブジェクト」であるため、ユーザーオブジェクトと同じメソッドとプロパティを持つ必要があります。そうでない場合は、基本ユーザークラスとの真の継承関係がないように見えます。

この場合、継承の代わりにインターフェースの使用を検討することをお勧めします。UserクラスとModeratorクラスの間の共通機能をインターフェースに組み込むことができます。共有できる共通のコードがある場合は、コンポジションを使用して、インターフェイスの共通の実装を作成し、このコードを再利用する必要のあるクラスに渡すことで、これを実現できます。詳細については、こことここを参照してください。

上記の2番目のリンクの作成者が述べているように：

  • TypeBは、TypeAが期待される場所でTypeBを使用できるように、TypeAの完全なインターフェイス（すべてのパブリックメソッド以上）を公開したいですか？継承を示します。

  • TypeBは、TypeAによって公開される動作の一部/一部のみを必要としますか？作曲の必要性を示します。

基本クラスのメンバーを非表示にする必要があることから、あなたは2番目のカテゴリに属しているようであり、構成とインターフェイスを使用して探索することをお勧めします。

于 2013-01-22T01:44:18.643 に答える