問題タブ [class-design]

C++ 初心者の質問です。正しく行っていることを確認してください。

私は小さな子供たちを生み出すグローバルアプリケーションクラスを持っており、子供たちにいくつかのアプリケーション機能へのアクセスを与える必要があります。だから私はそれらを参照して子供たちに渡すことにしました。

以下に示すように、アイデアをテストしました。それはうまくいくようです。危険なことをしていないことを確認したかっただけです。私が見落とした落とし穴があるかもしれませんか？

お父さんは子供を作り、車の鍵を渡します。

従来の IBM ユニバース データベースに接続する ASP.NET アプリケーションを作成する必要があり、サーバー側プログラムの接続、読み取り、書き込み、選択、実行などを可能にする mv.net という製品を使用しています。

コードの繰り返しをできるだけ少なくしたいのですが、データ転送もできるだけ少なくしたいと考えています。

接続を開くには、まず次のようなコードを使用してアカウントへの参照を取得する必要があります。

次に、アイテムを読み取ることができます。

これで完了です。

モジュールごとにクラスがあるため、INVOICE、PURCHASE_ORDER、RMA、REQ、SHIPMENT などがある場合があります。INVOICE 内で、CUSTOMER、INVOICE、TERMS、SHIPVIA などの複数のテーブルにアクセスする必要がある場合があります。

私が計画していたのは、データベースの名前である TechDB というクラスを作成し、そこにコードを配置することでした。そのため、私の INVOICE クラスでは次のように言えます。

これを行うと、私の TechDB クラスは接続を開き、レコードを読み取り、すべて 1 ステップでログアウトします。

私は正しい道を進んでいると思いますが、そうでない場合はお知らせください。これに関する私の問題は次のとおりです。

1. INVOICE クラスでエラーを返すにはどうすればよいですか? たとえば、データベースに接続できない、ファイルを開くことができない、レコードを読み取ることができない場合、エラーが発生する可能性があります。

2. 次に、INVOICE からデータを取得して TERMS テーブルを読み取る必要がある場合はどうでしょうか。データベースを開いたばかりのときに、データベースへの新しい接続を開く必要はありません。

3. これを持つすべてのクラスで Dispose メソッドを呼び出す必要がありますか? たとえば、mvAccount には Dispose メソッドがあります。ドキュメントのどれもそれを呼び出すとは言っていませんが、Logout() の後にすべきですか?

4. myAccount.Logout() を実行する Dispose メソッドを TechDB クラスに作成できますか? そうすれば、接続は開いたままになり、完全に完了したら INVOICE クラスから閉じることができますか?

これを処理する最善の方法について意見を聞かせてください。私の目標は、変更が容易で、コードの繰り返しができるだけ少ない堅牢なアプリケーションです。

Bar 型のプロパティを持つ Foo があるとします。両方とも、ID で取得できるデータベースに永続化されます。(ID は実際には顧客サービス要求によって基幹業務で使用されます。したがって、それらは単なるインデックス プレースホルダーではありません。) b1 または b2 で示したアプローチを取ることができます。

エンティティを連鎖させると怖くなります。これをやりすぎると、簡単に Null がポップアップしてしまうからです。一方で、ID をどこにでも表示することは、不要な言葉遣いを追加しているように見えます。

注: これは .NET エンティティ フレームワークに関するものではありません。実体という言葉は、ここでは一般的な意味で使用されています。

クラスファイルを動的に作成したい。ここに行きます... 指定された ResultSet を使用してメタデータを抽出する ResultSet に存在するすべての列のゲッター メソッドとセッター メソッドを使用してクラス ファイルを動的に構築したいと考えています。また、生成されたこのクラス ファイルを、後で使用するときにいつでも使用できるようにする必要があります。これを実装するためのより良い方法を提案してくれる人はいますか。また、これを実装するために利用可能な既存のjarファイルがあれば、それは役に立ちます。

私は最近、あるユーザーが「マネージャー」クラスの作成に反対した OOP 関連の質問に関する興味深いコメントを読みました。

クラス名について話すときは、マネージャーという単語を語彙から削除してください。クラスの名前は、その目的を説明するものでなければなりません。マネージャーはゴミ捨て場の別の言葉です。どんな機能もそこに収まります。その言葉は、多くの非常に悪いデザインの原因となっています

このコメントは、優れたオブジェクト指向開発者になるための私の苦労を体現しています。私は、手続き型コーダーしかいない組織で、手続き型コードを長い間行ってきました。私たちが生成する比較的小さなオブジェクト指向コードの背後にある主な戦略は、問題を個別のユニットとして簡単に識別できるクラスに分割し、残りの/一般化されたビットを「マネージャー」クラスに入れることです。

手続き的な習慣 (Manager クラスなど) を断ち切るにはどうすればよいですか? ほとんどの OO の記事/書籍などでは、本質的にオブジェクト グループ (たとえば、車両 -> 車) に変換しやすい問題の例を使用しているため、より複雑なシステムを分解するためのガイダンスはあまり提供されていません。

新しいオブジェクトモデルを設計するとき、私は常にVisualStudioのクラス図関数から始めます。最初のバージョンのドラフトを作成したら、新しい情報の収集や要件の変更に基づいていくつかの調整を行い、実際の実装に取り​​組み始めます。

開発が忙しくなり、目標を達成する必要があるため、図は途中で終わります。これは、最終的に、最初から設計されたモデルとは異なるモデルで終わります。

プロジェクトのライフサイクル中に、クラスオブジェクトモデルとコード実装の同期をどのように維持しますか？

クラス フレンドシップは C++ の最後の手段の 1 つですが、このパターンは理にかなっていますか?

このパターンの理由は、ピアがすべて同じランクにあり、互いに知識を共有する必要があるためです。ただし、この知識は秘密です。ピア以外の誰も使用しないか、プログラムが無効になるためです。 .

これの非常に現実的な例の 1 つは、あるピアが別のピアからコピー構築されている場合、そのソース ピアからの秘密情報にアクセスする必要があるということです。

固定サイズの循環 bufferを実装する単純なクラスが必要です。効率的で、見やすく、一般的に型付けされている必要があります。

今のところ、MT 対応である必要はありません。後でいつでもロックを追加できますが、いずれにしても同時実行性は高くありません。

メソッドは次のようにする必要があります。すべてのエントリを取得する場所です.Add()。.List()考え直して、検索はインデクサーを介して行うべきだと思います。いつでもバッファ内の任意の要素をindexで取得できるようにしたいと考えています。ただし、循環バッファがいっぱいになってロールオーバーするため、ある瞬間から次の Element[n] が異なる可能性があることに注意してください。これはstackではなく、循環バッファーです。

「オーバーフロー」について: 内部的にはアイテムを保持する配列があり、時間の経過とともにバッファの先頭と末尾がその固定配列を中心に回転することが予想されます。しかし、それはユーザーから見えないはずです。外部から検出可能な「オーバーフロー」イベントまたは動作があってはなりません。

これは学校の課題ではありません。通常、MRU キャッシュ、固定サイズのトランザクション、またはイベント ログに使用されます。

WebアプリケーションのビジネスレイヤーにPlayerというクラスがあります。

Playerクラスには、PlayerID、CategoryID、CountryIDのフィールドがあります

Playerクラスの関数は、データアクセス層のPlayerDBクラスの関数を呼び出します。この関数は、PlayerテーブルからPlayerID、CategoryID（Categoryテーブルへの外部キー）およびCountryID（Countryテーブルへの外部キー）のデータを返すストアドプロシージャを呼び出します。 。

上記の呼び出しに国名と国の画像（URLパス）を追加して、CountryIDごとにCountryテーブルから新しいフィールドを返す状況が発生しました。

私の質問は、国名と国の画像を追加のフィールドとしてPlayerクラスに追加しますか、それともCountry（BLL）とCountryDB（DAL）という新しいクラスと新しいストアドプロシージャがありますか？

最も簡単な方法ではなく、ベストプラクティスを実行したいと思います。

関連する場合は、ASP.NET、VB.NET、およびSQL2005を使用しています。

あなたはおそらく私が初心者であると言うことができるので、私が私の質問で正しい用語を使用しなかったならば私を許してください。私はあなたがその考えを理解することを望みます。