問題タブ [inheritance]

基本クラス B と派生クラス D があるとします。基本クラス内に、インスタンスの型に関係なく新しいオブジェクトを返すメソッド foo() が必要です。たとえば、B.foo() を呼び出すと B 型のオブジェクトが返され、D.foo() を呼び出すと D 型のオブジェクトが返されます。一方、実装は基本クラス B にのみ存在します。

これは可能ですか？

非常に多くの異なる可能性があり、それらにはすべて長所と短所があり、どれを使用すればよいかわからないため、私はデザインが得意ではありません。とにかく、ここに私の問題があります。さまざまなゆるやかに関連するクラスを検証する必要があります。ただし、これらのクラスの中には、検証を行うために追加情報が必要なものもあります。オブジェクトを検証するために使用できるメソッドvalidateが必要であり、オブジェクトがインターフェイスで検証可能かどうかを判断したいと考えていますValidatable。以下は、私が持つことができる2つの基本的な解決策です。

これは、検証可能な何かが実装され、検証に使用できる一般的なグローバルインターフェイスを持つ最初のソリューションですが、Object1validate()はこれをサポートしていないため、一種の機能不全ですが、Object2 はそれをサポートしており、他の多くのクラスも同様です。

別の方法として、次のようにすると、トップレベルのインターフェイスがなくなります。

私が抱えている主な問題は、少なくともXまたはYオブジェクトが検証可能であると言えるように、トップレベルのインターフェースを持つという考えに固執していることだと思います。

JSON を使用してオブジェクトを作成する方法は知っていますが、JSON を使用して特定のオブジェクト タイプのオブジェクトを作成する方法はないようです。

オブジェクトとそのインスタンスの作成の例を次に示します。

ここで、JSON を使用して新しい Person オブジェクトを作成し、GetFirstName 関数が機能するようにします。

これが私がやろうとしているようなものです（しかし、このコードは機能しません）：

JSONを使用して特定のタイプのオブジェクトを作成する方法はありますか?

更新: Person オブジェクトを使用した私のサンプルは、質問を単純化するためのものです。実際、インスタンスを作成する必要がある実際のオブジェクトのコンストラクターを変更することはできません。オブジェクトはサードパーティ ライブラリの一部です。

更新: 以下のいくつかの提案を使用して、オリジナルから継承するオブジェクトを作成し、そのコンストラクターで JSON を受け入れる方法を見つけることができました。これはきれいです！

Javascript の大きな利点の 1 つは、プロトタイプ ベースの言語であると言われています。

しかし、Javascript がプロトタイプ ベースであるとはどういう意味ですか? また、なぜそれが利点なのでしょうか?

ASP.Netの組み込みのカレンダーユーザーコントロールを継承するカスタムカレンダーコントロールを作成しようとしています。

コントロールの分離コードファイルは次のようになります。

正常にコンパイルされます。

ただし、カスタムコントロールをaspxページに配置しようとすると、次のようになります。

警告が表示されます'要素WeeklyEventsCalendarは既知の要素ではありません。これは、Webサイトにコンパイルエラーがある場合、またはweb.configファイルがない場合に発生する可能性があります。しようとしています

過去にファイルの場所を誤って入力したときのように、「ファイルが見つかりません」というエラーは発生しません。

ブラウザにaspxページを読み込もうとすると、エラーCS0115が発生します：'ASP.usercontrols_weeklyeventscalendar_ascx.FrameworkInitialize（）'：オーバーライドする適切なメソッドが見つかりません

私のコードのどこにもそのような関数を定義しようとしないので、これはさらに混乱します。

これは本当に簡単なはずです。どこが間違っているのですか？

データベースで継承をモデル化するためのベスト プラクティスは何ですか?

どのようなトレードオフがありますか (クエリ可能性など)?

(私は SQL Server と .NET に最も興味がありますが、他のプラットフォームがこの問題にどのように対処しているかについても知りたいです。)

Delphi 7 で、フォームに他のフォームからコンポーネントを継承させたいプロジェクトに取り組んできました。私はこれを機能させることができましたが、次の問題に遭遇しました（将来的に他の人を助けるために解決策を投稿するつもりです）：

1. フォームの .pas ファイルで、他のフォームから継承するようにフォームを変更しますが、祖先フォームからコンポーネントを取得しません。
2. 特定の子孫フォームの場合、設計時にフォームを開くと、次のエラー メッセージが表示されます。最初に先祖フォームを手動で開く必要があり、その後で子孫フォームを開くことができました。

私はまだデザインパターンに頭を悩ませようとしています.2回目は、パターンの解決策を求めているように見える同じ問題に直面しています.

複数のアカウント タイプを持つアカウント システムがあります。レストラン、ホテル、service_provider、および消費者のアカウント タイプがあります。将来的にはビジネス アカウントの種類が増えると確信しています。もちろん、グローバル管理者アカウントもあります。

そこで気になるのは、アカウント種別の切り替えをどう実装するかということです。例えば。各アカウントには 1 つ以上のプロファイルがありますが、プロファイルはアカウントの種類によって異なります。複数のタイプのアカウント (ポリモーフィズムまたは継承) を処理するには、ここでどのようなクラス関係を使用する必要がありますか?

他のプロファイルが拡張する必要がある抽象的な基本プロファイル クラスが必要なようですが、それを実装する方法がわかりません (たとえば、プロファイル タイプとアカウント タイプの間の結合テーブル?)。

また、ファクトリ パターンを実装する機会のようにも感じますが、どうすればよいかわかりません。

アイデアはありますか？

提案されたいくつかの例を提供するために編集されました：

プロファイルはアカウントの種類によって異なります。たとえば、レストラン タイプのアカウントにはメニューやワイン リストなどがあり、ホテル タイプのアカウントには部屋のタイプやアメニティがあり、消費者タイプのアカウントには個人的な好みがあります。 、母国など

問題は、これらの関係を最もよく実装する設計パターンは何かということでした。

それがより明確であることを願っています、ありがとう！

私は、C# に多重継承を含めることに反対する多くの議論に出くわしました。

• 多重継承は複雑すぎてあいまいな場合が多い
• インターフェイスは同様のものを提供するため、不要です
• コンポジションは、インターフェイスが不適切な場合の優れた代替手段です

私は C++ のバックグラウンドを持っているので、多重継承のパワーとエレガンスが恋しいです。すべてのソフトウェア設計に適しているわけではありませんが、インターフェイス、構成、および同様の OO 手法に対する有用性を否定するのが難しい状況があります。

多重継承の除外は、開発者がそれらを賢く使用するほど賢くなく、複雑さが生じたときに対処できないと言っているのですか?

個人的には、C# (おそらく C##) への多重継承の導入を歓迎します。

補遺: 単一 (または手続き型の背景) と複数の継承の背景から来る回答から知りたいです。多重継承の経験がない開発者は、パラダイムの経験がないという理由だけで、多重継承は不要であるという議論をデフォルトで行うことがよくあります。

次の継承ツリーが与えられた場合、機能する方法でそれを実装する最良の方法は何でしょうか?

これは失敗します: 'Bar.Bar()' is inaccessible due to its protection level.

コンストラクターをパブリックにしたくありません。継承するクラスのみがsFooを作成できる必要がありますBar。Barは特殊なFooであり、どのタイプの もFoo作成できるはずです。public internal は、ここでは「オプション」です。定義済みの拡張機能の大部分はFooDLL の内部にあるためです。ただし、後で独自の型のFooor Baz(これは発生する可能性が高い) は、デフォルトのCreateBar()実装に固執し、ニーズを満たす場合と満たさない場合があります。

おそらく、これをリファクタリングしてうまく機能させる方法はありますか？私はこれを設計しようとして壁に頭をぶつけていますが、うまくいきます。

編集 (詳細):

もう少し具体的に: Foo は IEnumerable を実装しており、簡単に言えば、Bar は同じインターフェイスを提供していますが、その列挙可能なオブジェクトの限られたサブセットに提供しています。すべての Foo は、自分自身のサブセット (つまり、Bar) を作成して返すことができる必要があります。しかし、Foo を実装したいすべての人にこれを心配させたくありません。なぜなら、Bar がプロキシを行い、範囲の制限などを心配するからです。