問題タブ [inheritance]

あいまいなタイトルを許してください、私はそれを説明する方法がわかりませんでした.

一般的なモデル「アーカイブ」がある場合、ユーザーが選択した「タイプ」に基づいてさまざまなビュー/フォームをどのように表示しますか?

たとえば、ユーザーは新しい「アーカイブ」を作成し、ビデオ、本、オーディオなどの選択肢を取得します。そこから、アーカイブの種類に基づいてさまざまな形式を取得します。

それとも、ビデオ、ブック、オーディオなどの異なるモデルに分割したほうがよいでしょうか?

または、モデルを継承できます (ビデオがアーカイブを拡張するように)。これは基本的な OOP / クラスだと思いますが、ここでそれを適用する方法がわかりません。

任意の MVC フレームワークからの例を歓迎します!

classなぜその中に作成できないのVB.NETですinherits System.IO.Directoryか？Lutz Roederによると、それは！として宣言されていません。NotInheritable

utility classに機能を追加するを作成したいと思いますDirectory class。たとえば、Directory.Move関数を追加したいと思います。

アドバイスしてください。6パックをお送りします。OK、私はあなたに何も送っていないことを気にしないでください、しかしあなたが今夜バーに来るならば、私はあなたを引っ掛けて、それからあなたをプールで殴ります。

私は、約 60 の異なる「タイプ」のイベントがあるイベントのログを扱っています。各イベントは約 10 個のプロパティを共有し、さまざまな追加プロパティを共有するイベントのサブカテゴリがあります。

これらのイベントをどのように処理するかは、イベントの種類または実装するカテゴリ インターフェイスによって異なります。

しかし、コードの肥大化につながっているようです。サブクラス メソッドは同じインターフェイスをいくつか実装しているため、サブクラス メソッドには多くの冗長性があります。

「タイプ」プロパティを持つ単一のイベント クラスを使用し、タイプをチェックしてタイプのカテゴリの編成を維持するロジックを記述する方が適切ですか (たとえば、カテゴリ a のイベント タイプのリスト、カテゴリ b の 2 番目のリスト、等）？それとも、この場合、サブクラスの設計の方が適切ですか?

最初のアプローチ:

2 番目のアプローチ:

私の個人的な意見では、単一のイベント オブジェクトが適切であると思われます。なぜなら、私が正しく考えている場合、継承を使用してモデルを表現する必要はないからです。なぜなら、変更されるのは実際には動作と私の条件だけだからです。タイプに基づいています。

次のようなコードが必要です。

これは、instanceof の代わりにイベントでメソッドを呼び出して、適切なサブクラスのそれぞれに「同じコード」を実装できるという点で、最初のアプローチでうまく機能します。

しかし、2 番目のアプローチははるかに簡潔です。次に、次のようなものを書きます。

また、すべての「処理ロジック」は単一のクラスに編成でき、サブクラス間で冗長に分散されることはありません。では、これは OO の方が適切に見えますが、そうでないほうがよいというケースですか?

言い換えれば、使用するのは正しいですか：

それ以外の：

CustomerList を 1 回定義するだけで済み、顧客リストが必要になるたびに常に同じ型を使用するため、最初のアプローチを使用したいと思います。一方、名前のエイリアシング アプローチを使用すると、どこでも再定義する必要があるだけでなく、誰かがそれを使用するたびに (大きなチームを考えてみてください)、別のエイリアスが与えられる可能性があり、コードが読みにくくなります。

この場合の意図は、クラスを拡張することではなく、単にエイリアスを作成することであることに注意してください。

私はさまざまな理由で独自のTree実装を作成し、2つのクラスを考え出しました。1つはロジックがぎっしり詰まったジェネリックツリーノードである「base」クラスで、もう1つはより特殊なクラスを拡張するクラスです。

私の基本クラスでは、特定のメソッドに新しいツリーノードのインスタンス化が含まれます（子の追加など）。これらのインスタンス化はロジック内にあり（たとえば、ネストされたループ内）、ロジックをインスタンス化から分離するのが困難になります。

したがって、特定のクラスでこれらのインスタンス化をオーバーライドしないと、間違ったタイプのノードが作成されます。ただし、これらのメソッドには、複製してはならない共有ロジックも含まれているため、これらのメソッドをオーバーライドしたくありません。

問題はこれに要約することができます：

私の頭に浮かんだ最初のものは、拡張クラスがオーバーライドできる「作成フック」を持っているでしょう：

今。それは素晴らしい最初の考えでしたが、そのコードから何かひどい悪臭が出てきました。何か非常に...それについて間違っています。

それは裸で料理をするようなものです-それは危険で不必要だと感じます。

では、この状況にどのように対処しますか？

次の宣言があるとします。

私は次のことができることを知っています：

しかし、Over2 なしで Under2 を宣言する方法はありますか?

Under1 の派生物を使用するには Over1 を拡張する必要があるため、これはばかげているように思えるかもしれませんが、この状況では、30 種類の Under のフレーバーが存在する可能性があります。次のいずれかを実行できます。

• それらをすべて Over1 内に配置する: Over2 はそれらの 1 つまたは 2 つしか使用しない可能性があるため、魅力的ではありません
• それらをそれぞれ独自のバージョンの Over に配置します。魅力的ではありません。そのため、ほぼ同じクラスから複数の継承を行う必要があります。
• Over1 の子を作成せずに Under1 の子を作成する方法を見つける

それで、これは可能ですか？

ありがとう。

Java では、「final」キーワードを使用してこれを行うことができました。C# に「final」が表示されません。代替品はありますか？

あなたが私に発砲し始める前に、私はこれを行うつもりはありませんが、別の投稿の誰かが可能だと言いました. それはどのように可能ですか？リフレクションを使用して何かから継承することは聞いたことがありません。しかし、私はいくつかの奇妙なものを見てきました...

私の知る限り、C＃2.0で次のことを行うことはできません

派生クラスでプロパティを「新規」として作成することで問題を回避しますが、もちろんそれはポリモーフィックではありません。

2.0で何か解決策はありますか? この問題に対処する 3.5 の機能はどうですか?

プロキシオブジェクトでラップしたい（不十分に記述された）基本クラスがあります。基本クラスは次のようになります。

そして、私のプロキシは次のようになります。

「fakeOut」コンストラクターがない場合、基本コンストラクターが呼び出されることが期待されます。しかし、それで、私はそれが呼ばれないことを期待しました。いずれにせよ、基本クラスのコンストラクターを呼び出さない方法か、この（邪悪な）クラスを効果的にプロキシする他の方法が必要です。