問題タブ [encapsulation]

私は多くの場所で、アセンブリ言語は通常完全なプログラムを作成するために使用されませんが、特定の手順、特に1秒間に数千回呼び出される手順をより効率的にするために他のプログラムによって使用されることを読みました。アセンブリコードの小さなビットがどのように大きなプログラムに組み込まれるのか疑問に思っています。

• 小さな実行可能ファイルを作成して別のプログラムから実行できると思いましたが、それは非効率的です。

• 次に、Visual Studioのインラインアセンブリについて考えましたが、これはMicrosoftに固有のものであり、より良い方法があるようです。

では、個別のプログラムを作成したり、Visual Studioインラインアセンブリを使用したりせずに、大きなプログラム内で小さなアセンブリコードを使用するにはどうすればよいでしょうか。

私の特定のシナリオでは、プライベートメソッド内で正規表現を使用してテキスト変換を行います。プライベートメソッドはpreg_replace_callbackを呼び出しますが、コールバックはオブジェクトに対してパブリックである必要があるようです。そのため、プライベートの世界から抜け出し、実装の詳細を公開したくないときに立ち往生しています。

つまり、簡単に言うと、カプセル化を失うことなく、インスタンスメソッドをコールバックとして使用できますか？

ありがとう。

かなり大きくなった MainForm を使用してデスクトップ アプリケーションを開発しています。さまざまなレベル (SplitContainers、TabPages、Panels) の複数のコンテナーに多数のコントロールがあります。

ここで、データバインディングとコントロールのクリア、またはユーザー操作の実行を担当するすべてのコントローラーコードを個別のコントローラークラスに分離することにより、このクラスをリファクタリングしたいと考えています。

[編集]

目的

このアプリケーションの目的は、注文 (ジョブと呼ばれる) とその位置 (ジョブアイテムと呼ばれる) を追跡することです。各ジョブは顧客に関連し、各ジョブアイテムは記事に関連しています (ジョブアイテムには、その記事の製造プロセスに固有の情報が含まれているため、記事をラッピングしています)。Job、Joitem、Customer、および Article には、PropertyManager クラスによって管理される動的プロパティ (基本的なキーと値のペア) があります。

建築

私のアプリケーションは 2 つのメイン プロジェクトに分割されています。コアには、3 つの LinqToSQL DataContext クラスのデータ モデルが含まれています。

• ArticleManagement
• JobManagement
• PropertyManagement

すべての DataContext クラスにはXyzManager、コレクション内の LinqToSQL オブジェクトを GUI に提供し、LinqToSQL データ ソースをカプセル化するクラスがあります。また、対応する DataContext タイプの作成、削除、および変更も処理します。

次に、GUI プロジェクトを作成しました。当然、メイン フォームと、オプションなどの追加フォームがいくつか含まれています。現在、私の GUI プロジェクトは、各 XyzManager クラスへの参照を保持し、Manager クラスを介してデータを取得および設定します。すべての制御ロジックを含む、ユーザー インタラクションによって指示されます。

このための独立したロジックのほとんどを、メイン フォーム クラスの外にある静的なユーティリティ クラスに入れましたが、それは理想的とは言えない方法だと思います。

[/編集]

これは私の最初の大きなデスクトップ アプリケーションであり、GUI をカプセル化するのに苦労しています。現時点では、ユーザー インタラクションの処理を担当するすべてのコントローラー コードは MainForm クラス内にあります。

MVC パターンについては知っていますが、現在のデザインで C# WinForm に適用する方法がわかりません。

私のカスタム コードだけでも 2,400 行を超える長さのコードがあり、フォームの自動生成されたコードにはカウントされず、増加傾向にあります。これをリファクタリングしたいのですが、よりエレガントな方法でこれを解決する方法がわかりません。

一般に、OOP パラダイムによると、カプセル化に関する私の理解は基本的に次のように述べています。

1. メンバーがプライベートの場合、クラスからのみアクセスできます。
2. メンバーが保護されている場合、基本クラスと派生クラスからのみアクセスできます。
3. メンバーが公開されている場合は、誰でもアクセスできます。

入れ子になったクラスがある場合、そのクラスと入れ子になっている親クラスのみがアクセスできるようにプロパティを宣言できますか? 例えば：

この例では、これらのメンバーが Private または Protected の場合、ContainerClass のインスタンスから myNestedObject.myInt または myNestedObject.myDbl に直接アクセスすることはできません。しかし、それらをパブリックにしたくないとします。なぜなら、あまりにも公開されてしまうからです。これらは、ContainerClass オブジェクト内だけでなく、どこからでも変更できます。それらを Friend として宣言しても、アプリケーション内のどこからでも変更できるため、依然として弱すぎます。

私がここで行っていることを達成する方法はありますか? そうでない場合、このようなことを達成するためのより賢明な方法を考えられる人はいますか?

次のタイプのデータがあるとします。

次に、各顧客が各サービスにいつ接続したかを覚えておく必要があります。
私は構造を作ります：

または、id で検索できるようにするには、equal() と hashCode() をすべて記述する必要はありません。

これで LastConnection データにアクセスできるようになりました

特に、LastConnections のマップのマップを期待する数十のメソッドにパラメーターとして渡す必要があるため、次のような独自のクラスを作成することを考えています。

継承が 3v1l であることはすでにわかったので、構成を試してみましょう。

問題は、SOLID の原則とすべてのベスト プラクティスを尊重する最善のアプローチが何であるかがわからないことです。既存のコレクションを拡張する以外に何もしないクラスを作成することは、必要以上にエンティティを増やすように見えますが、私のコードをより明確にします (特に次のレベルがある場合 - 月ごとの AllConnections のマップなど)。道順は？

C＃では、他の言語よりも簡単な方法でゲッター/セッターを作成できます。

これにより、直接アドレス指定できない内部プライベート変数が作成され、外部プロパティ「FooBar」を使用して直接アクセスできます。

私の質問は-これが乱用されているのをどのくらいの頻度で見ますか？カプセル化のベストプラクティスに違反する可能性が高いようです。誤解しないでください。私はそれを適切に使用し、読み取り専用の書き込み専用タイプのプロパティに部分的なバリエーションを使用していますが、コードベースの他の作成者からの不快な経験は何ですか？

明確化：意図された乱用の定義は、プライベート変数が適切な場合にそのようなプロパティを作成することです。

クラスBによってのみ操作されるべきクラスAを適切にカプセル化しようとしています.

ただし、クラス B から継承したい。

友達がいる B はうまくいきません。友情は継承されません。

私が望むものを達成するための一般的に受け入れられている方法は何ですか、それとも私は間違いを犯していますか?

もう少しわかりやすいように、クラス A は複雑なシステムの状態を表します。これは、クラス A の状態を変更するために適用できるアクションである B によってのみ変更される必要があります。

私は、コーディング時にアクセス修飾子をメンバー/型に適切に適用する方法をさらに理解するのに役立つリソースを探している学生です。

私は (C# で) プライベート、パブリック、プロテクテッドなどのアクセス修飾子がどのような制限を設けているかを知っています。自分の小さなプロジェクトをコーディングするときは、すべてを公開する傾向があります。カプセル化を窓の外に放り出すだけなので、これは絶対に恐ろしい習慣だと確信しています。内部対プライベートのようなものをいつ使用するのが正しいのか、私にはわかりません。

アクセス修飾子の適切な使用法を理解するのに役立つリソースはありますか?

m_MAXとask（）はrun（）によって使用されますが、それ以外の場合はパブリックにしないでください。これはどのように行うことができますか？

私の職場の「アーキテクト」から受け継がれた悪い慣行を数年間守り、もっと良い方法があるに違いないと考えた後、私は最近、TDD と DDD について読んでいます。私たちが作成するソフトウェアの複雑さに非常に適しています。

しかし、私が見た TDD サンプルの多くは、ドメイン オブジェクトのメソッドを呼び出してから、オブジェクトのプロパティをテストして、動作が正しく実行されることを確認しています。

一方、業界で尊敬されている何人かの人々 (Greg Young は、CQRS に関する彼の講演で最も顕著です) は、すべての「ゲッター」を削除することによって、各ドメイン オブジェクトを完全にカプセル化することを提唱しています。

したがって、私の質問は次のとおりです。状態の取得が禁止されている場合、ドメインオブジェクトの機能をどのようにテストしますか?

私は何か基本的なことが欠けていると思うので、遠慮なく私をバカと呼んで教えてください - どんなガイダンスも大歓迎です.