問題タブ [class-structure]

INI ファイルを管理するために作成した古いクラスを改善しようとしています。クラスには、手順を分離して整理するための 3 つのサブクラス ( File、Key、Section) が含まれています (一般的には ini のプロシージャ、キーを管理するプロシージャ/値、およびセクション名を管理するためのプロシージャ)。

さて、私が抱えている問題は、古いクラスではすべてのメンバーが共有されており (props/vars/objects/methods)、明らかにそれが非類似性につながる可能性があることです。メンバーの可視性を完全なものにしたいと思います。私が立ち往生しているところがあります。

クラスの現在の使用法は次のようになります。

そして、私が望む使用法は次のようになります:

以下は、この例に関連するコードです。変数とメソッドの両方を私のように設定していないため、最上位クラスにある変数にアクセスできないためExist、クラスのメソッドに行き詰まっています私の古いクラスバージョンでやった...FileFilePathExistShared

...では、どうすればこれを改善できますか?

注:他の 2 つのサブクラスには、クラス内だけでなく、名前が付けられたメソッドExistと、" " などの同じ名前の他のメソッドが必要であることに注意してください (それが問題になるかどうかはわかりませんが、さらに多くのことが必要になる可能性がありますレタッチします）。[Get]File

単純な Spring コードの例に従って、 Jackson を使用してJSONを Java クラス構造に解析することに成功しました。

今、キー名のない JSON データに対して同じことを行う方法のヒントを探しています。

子オブジェクトがインスタンスを作成する前にパラメーターを必要とするため、問題が発生する次のコードがあります。子オブジェクトの作成を処理するために何らかの関数を作成する必要がありますか?

私はできるようにしたい：

これは私のコードです:

私の実際のコードでは、プロファイルを作成する Web サイト内のタスクを自動化するための Python ラッパーを作成しています。各プロファイル内には多数の抽出があります。関連するすべてのルーチンを管理するには、この種のツリー構造が最適な方法であると考えました。

Web サイトへの接続側を維持するために親クラスが必要であり、各プロファイルparent.profile(profile_id)に関連するタスク/ルーチンを含めたいと考えています。次に、各抽出に関連するタスク/ルーチンを含めたいと思います。parent.profile(profile_id).extract(extract_id)

これは私の抽象クラスです:

これは私の派生クラスです:

Compiler さんは、Enemy クラスのメンバ HEALTH を static にすることも、abstract にすることもできないと言っています。

私の目標は、各子クラスに、親クラスからアクセスできる静的フィールドまたは定数フィールドを強制することです。

これに対する解決策はありますか？そうでない場合、最もエレガントな回避策は何ですか? プロパティを非静的にしますか?

宿題として、Rail Fence Cipher と呼ばれる方法に基づいて文字列を暗号化するプログラムを作成するタスクが割り当てられました。（これが一般的な知識であるかどうか、またはあなたがそれが何であるかを正確に知りたいかどうかさえわからないので、もしあなたが見たい場合はウィキペディアのリンクを含めました）.

ストレートなメイン メソッドで文字列を正常に暗号化できました。クラスを使用してコードを正しく記述できるようになりました。

通常のクラスを使用してオブジェクトを作成する必要があるかどうかはわかりません。私の最初の傾向は、クラスを抽象化し、単純にデータを操作して、暗号化されたメソッドを返すことです。これについて正しい方法が何であるかはよくわかりません。抽象クラスまたはオブジェクトクラスでコードを書くのに問題があるとは思えません。どちらが正しいと考えられるかはわかりません。

誰でもガイダンスを提供できますか？抽象クラスを使用しない最大の理由は、このプログラムが単純であり、いかなる種類のインターフェースも使用しないことです。

私はPHP Webアプリケーションを構築しています。これは、ユーザーと別の人/組織との間の(ConnectDirectまたはファイル転送ゲートウェイ)接続の「インストール」/セットアップを注文する可能性をユーザーに提供する必要があります。

(接続実装の技術仕様は重要ではありません。アプリケーションでは、注文および管理できる製品としての接続のみが重要です。)

そのモデル レイヤーのクラス階層は、次の現実世界のインフラストラクチャを表す必要があります。

• 注文できる接続があります。
• 接続は、IBM Connect:Direct 接続または IBM File Transfer Gateway 接続のいずれかです。
• CD接続は、 A (ソース) から B (ターゲット) への直接接続です。
• FTGW接続は、物理的に 2つの接続で構成されます。FTGW サーバーへの A (ソース) と FTGW サーバーから B (ターゲット) への接続ですが、論理的には (注文ユーザーにとって) 1 つの接続でもあります。
• (Connect:Direct をプロトコルとして使用する FTGW 接続の場合もあります。)
• すべてのエンドポイントは、ソースまたはターゲットのいずれかです。

したがって、次の論理要素が表示されます: logical connection、physical connection、role ( sourceおよびtarget )、connection type、order、endpoint、endpoint type (CD および FTGW)。

私が現在持っている構造は次のようになります。

しかし、それにはいくつかの問題があります:

1. 2 つの階層ツリーがあり、一方の要素には他方の特定のサブセットの要素が含まれます (各 CD 接続は CD エンドポイントで構成され、各 FTGW 接続は 2 つの FTGW エンドポイントで構成されます。より正確には、各 FTGW 論理接続は2 つの物理的な FTGW 接続 -- それぞれが FTGW エンドポイントと 2 番目のエンドポイントとしての FTGW サーバーで構成されます)。

   別の方法として、関係 betweetEndpointとPsysicalConnectionを 2 つの関係 (EndpointCD-PsysicalConnectionCDと) に置き換えることもできますEndpointFTGW-PsysicalConnectionFTGW。

長所: より一貫性があります。任意のエンドポイントのペアからすべての接続 (タイプ) を構築する偽の可能性の論理的な不正確さ (またはおそらく間違い) を排除します。反対: 実際には、2 つのエンドポイントを含むという要件は、すべての物理的な接続の特徴です。この観点からすると、これに適した場所は非常に基本的なPsysicalConnectionクラスです。

2. すべてのエンドポイントはソースとターゲットの両方になることができ、共通のエンドポイント プロパティだけでなく、ソース プロパティとターゲット プロパティも含まれます。つまり、エンドポイントの現在の役割に応じて、一部のプロパティが Waste になります。また、これはデータベース構造にも影響を与えます (列、時には設定する必要があり、時にはbi にする必要があります)。NULL

   別の方法は、階層を拡張することです...

   a. ... のようなクラスによってEndpointSource、EndpoitTargetから直接Endpoint継承され、クラスによって継承されますEndpointCD(EndpointFTGWつまり、2 つの同一のサブツリー -- の下EndpointSourceと下EndpointTarget);

   b. ... and ( class から継承) およびEndpointCDSourceand ( class から継承) のようなクラスによって、具体的な CD または FTGW エンドポイント クラスによってそれぞれ継承されます (つまり、2 つの同一のサブツリーが 2 倍になることを意味します)。EndpointCDTargetEndpointCDEndpointFTGWSourceEndpointFTGWTargetEndpointFTGW

   c. ...具象エンドポイントクラスと同様のクラスMyConcreteEndpoint***SourceとMyConcreteEndpoint***Target継承するクラスによって（つまり、すべてMyConcreteEndpointのクラスが抽象になり、2つのサブレスを取得します-たとえば、MyConcreteEndpoint***Sourceandは抽象になり、 and に継承されます）。MyConcreteEndpoint***TargetEndpointCDLinuxEndpointCDLinuxSourceEndpointCDLinuxTarget

   長所: 廃棄物の特性を排除します。Contra : (より) 複雑なクラス階層。

まあ、それはソフトウェア アーキテクチャに関するものであり、私の設計上の決定であるべきです (もちろんそうなるでしょう)。しかし、専門家（または専門家ではない）の考え、そのようなケースをどのように処理するかを聞いたり読んだりするといいでしょう。私が説明したようなインフラストラクチャの論理アイテムを整理する適切な方法は何ですか?

私は現在、フラッターアプリケーションに取り組んでいます。大きなウィジェットツリーを持つファイルがあります。理解しやすく、読みやすく、保守しやすいように、ウィジェット ツリーを「切り取る」必要がありました。

最初にやったのは、_createFancyImage()やなどのツリーのより大きな部分を表す複数の関数を作成することでした_createFancyContainer。いくつかの調査の後、そのような設計にはいくつかの欠点があることがわかりました ( https://github.com/flutter/flutter/issues/19269を参照)。そこで、StatelessWidget代わりに s を作成することにしました。ウィジェット ツリーのサイズが大きいため、3 つStatelessWidgetの論理に分割しました。FancyImage()これで、 or FancyContainer()which をそれぞれスタンドアロン ウィジェットとして使用できるようになりました。

StatelessWidget初心者として、これらのクラスを同じファイル内に保持する必要があるかどうかはわかりません。または、独立したファイルを作成することもできます。明確にしておくべきことは、私はこれらの派手なウィジェットを他の場所で使用していないということです。これらは、この 1 つの大きなウィジェット ツリーに固有のものです。

残念ながら、Dart と Flutter Repo のスタイル ガイド内やインターネット上で何かを見つけることができませんでした。

すべての提案に感謝します。

私は VB.NET を使用して最初の実際の WinForms アプリケーションに取り組んでおり、プロジェクトは当初の予想よりも少し大きくなっています。私は WinForms でこれを行うことに慣れていないので、見つけた解決策が正しい方法であるかどうかはわかりません。

多くの Control 要素、特に TextBoxes があるため、さまざまなイベントを処理するためのコードを別のクラスに移動する必要があります。私が見た限りでは、作業しているプログラムの種類に応じて、これを行う方法はさまざまです。最も理解しやすいのは、追加のクラスを作成し、WithEvents を使用して必要なすべての Control オブジェクトを宣言することです。たとえば、私のメインクラスでは次のようになります。

代わりに、そのすべてのコードを新しいクラスに移動したい場合は、次のようになります。

つまり、メインクラスで今しなければならないことは次のとおりです。

他のすべての Control 要素についてもこれを行います。そうすれば、メイン クラスをよりクリーンに保つことができますが、イベント リスナー コードでいっぱいの巨大なクラスになってしまいます。これで少しは楽になると思うのですが、やはり下品な感じがします。私の次のアイデアは、これをさらに分割して、TextBox イベント用に 1 つのイベント クラスを作成し、Button イベント用に別のイベント クラスを作成することです。私は何かが完全に欠けています。

次のような構造があります。

FooにBarアクセスする必要がありますがBaz、Bazモジュールとそれをインポートする他のモジュールの両方に対して非公開のままにする必要があります。

質問:

1. と に共有Bazする方法はFooありBarますか?」
2. 必要なアクセスを許可するために使用できる他のクラス構造はありますか?