問題タブ [nested-class]

ごく最近まで、通常のクラスと内部クラス/サブクラスの間に違いがあることを気にしていませんでした。

内部クラスのインスタンスとそれを含むクラスのインスタンスの間の関係は何ですか?また、内部クラスの目的は何ですか?それらの違いは何ですか?

配列を使用してネストされた構造体を作成するのを手伝ってください。このコードを修正するにはどうすればよいですか？

ありがとう。

私は現在、いくつかのフレームワーク クラスにリファクタリング (+ 新機能の追加) を行っています。状況は、分割したい一連のロジックを実行する単一の (神のような) クラスがあるということです。このクラスは、会計コードの検証規則のようなものを表します。そのため、人の名前、生年月日などの検証を行います.

私がやろうとしているのは、それを単一のルールに分割することです。基本的には、会計コードに対して個人の名を検証するルール、生年月日などを検証するルールです。最後にプログラマーにとっては、ほとんど同じように見えます。FiscalCode ルールの巨大なコンストラクターを呼び出す代わりに、彼は次のようなことをFiscalCode.GetRules(...)行い、ここでパラメーターを渡します。次にGetRules(...)、 は単一のルールを内部的に構築し、それらを配列として返します。それは完全に問題なく、私たちにとって正しいです。

あなたの背景についてはこれで終わりです。今、私の質問は次のとおりです。FiscalCode クラス (現在の強力な神のクラス) には、これから作成する単一の「ルール クラス」の多くで必要となるユーティリティ メソッドが多数あります。私が知っていることは、それを行うために何らかの形で FiscalCode クラスが必要になるというGetRules(...)ことです (これは、プログラマーがまったく新しいことをしなければならないということではなく、プログラマーにとって何らかの形で一定であり続けるためです)。

私の頭に浮かぶ2つのオプションがあります。

1. 新しいルール クラスを作成し、FiscalCode クラスの public static ユーティリティ メソッドにアクセスする
2. 新しいルール クラスを FiscalCode クラス st の内部のネストされたクラスとして作成します。既にユーティリティ メソッドにアクセスしています (したがって、ユーティリティ メソッドを公開する必要はありません)。

私はすでにお気に入りを持っていますが、最初にいくつかの意見を聞きたいです。

どうも

リフレクターを使用してフレームワーク内のいくつかのクラスを見ると、フォームとユーザー コントロールが非公開になり、親クラスにネストされていることがわかります。

たとえば、そのコントロールに固有のポップアップ フォームを使用するコントロールがあります。現時点では、ポップアップ フォーム フレンドにアクセスできるようにしています。フレームワークの方法で実行したい場合は、それを非公開にして、コントロール クラスに入れ子にします。ただし、これを行うと、IDE を使用してフォームを設計できなくなり、コンパイルしようとするとエラーが発生します。だから、私は2つの質問があります：

(1) Microsoft は最後の最後に、すべてを非公開にするために何かを行いますか?

(2) 彼らの方法が好ましい方法ですか、それとも友人のアクセサーに固執する必要がありますか?

具体的には、ネストされたクラスを使用する場合と使用しない場合の具体的な例を誰か教えてもらえますか?

この機能については以前から知っていましたが、使用する理由がありませんでした。

ありがとう。

設計が不十分な API を使用しています。シリアル化する必要があるクラスがあり、クラスの構成を制御できますが、クラスがシリアル化するプロパティを構成する型は制御できません。以下に例を示します。

問題は、「インストール」タイプと「アンインストール」タイプを制御できず、それらのネストされたタイプが同じ名前になっていることです。「インストール」は MyCompany.Install.dll にあり、「アンインストール」は MyCompany.Uninstall.dll にあります。しかし、問題は、MyCompany.Uninstall.dll が MyCompany.Install.dll を参照していることです。これはまったく無意味です。私はこれが悪い設計であることを知っています (私が扱っているフレームワーク全体がひどいものです) が、それを扱う選択肢はありません。

私が得るエラーは次のとおりです。

「タイプ 'MyCompany.Install.Uninstall.DefaultStep' および 'MyCompany.Install.DefaultStep' は両方とも、名前空間からの XML タイプ名 'DefaultStep' を使用します。XML 属性を使用して、一意の XML 名および/または名前空間を指定します。タイプ。"

「Install」および「Uninstall」クラスを含むアセンブリをまったく制御できないことを除けば、それは良い考えです。

何か案は？

私は次のことをしようとしています：

…しかし、私のコンパイラはこれを窒息させているようです。これは合法的なC++ですか？そうでない場合は、同じことを達成するためのより良い方法がありますか？基本的に、よりクリーンなクラス命名スキームを作成したいと思います。Animal（共通の基本クラスから内部クラスを派生させたくありません）

ネストされたプライベート実装を含む抽象基本クラスがあります。抽象化されていないネストされた実装をインスタンス化しようとすると、Visual C++ で次のエラーが発生します。

エラー C2259: 'node::empty_node': 抽象クラスをインスタンス化できません (32 行目)

私が知る限り、基本クラスのすべての抽象メンバーをオーバーライドしました

コードは次のとおりです。

この質問にタグを付け直して、関連する言語を含めてください

したがって、私のJavaの本には、ネストされたクラスに関する章全体がありましたが、「構成関係のモデル化と非表示にしたいクラスの内部の実装」に関してのみ、それらを実際に使用する必要があることに注意して終了しました。それでは、ネストされたクラスといくつかの例をいつ使用するかについて説明しましょう。

このための命名法がすでにあるかどうかはわかりませんが、この質問のために、ピア実装またはネストされた実装という 2 つの用語を定義して、多くの親子エンティティ関係を含むデータ モデルにコレクション クラスを実装する方法を説明します。

ピアという用語を使用して、エンティティ クラスと一緒にモデル レイヤーにコレクション クラスを実装し、基本的に API でそれらをピアにするシナリオを説明します。

ここでの主な利点は、たまたま同じ型の子を格納している他のエンティティ クラスでコレクション クラスを再利用できることです。

ネストされたという用語を使用して、次のようにネストされたクラスとして実装するシナリオを説明します。

ここでの主な利点は、各親が独自のコレクション クラスを実装して、その特定の親に最も最適化された方法で子を格納できることです。たとえば、ある親エンティティは配列データ構造が適切に機能することを発見し、別の親エンティティはスプレイ ツリーを使用する場合があります (よくわかりませんが、私の要点をよく示しています)。

Microsoft がさまざまな .NET 関連のフレームワークで両方のイディオムを使用していることに気付きました。System.Windows.Forms 名前空間は、入れ子になった実装に大きく依存しているようです。より多くの作業が必要ですが、私もこの方法を好む傾向があります。

推奨事項、コメント、代替案はありますか?