問題タブ [ooad]

小売業者向けのシステムを設計しているシナリオがあります。これは適切なライブ アプリケーションではなく、私の OO 設計スキルが正しいかどうか、および私の考えが正しいかどうかを確認するための単なるシナリオです。私はまだここで学んでいます。私はこれをc#でやっています。

シナリオは次のとおりです。

ステーショナリー製品を販売する小売業者は、さまざまな固定数のサプライヤーから最良の価格を選択し、そのサプライヤーに注文するシステムを設計したいと考えています。簡単にするために、文房具製品を同じ会社の 1 つの製品、XYZ ペンに絞りました。各供給業者は、尋ねられたときに XYZ ペンの見積もりを提供し、小売業者のシステムがさまざまな販売業者から最良の価格を選択して、その販売業者に注文します。

アプローチ 1:

1. サプライヤーの抽象クラスと各サプライヤーの実装を作成します。
2. PlaceOrder() メソッドとコスト プロパティを持つ各サプライヤ実装。
3. DataLayer は、サプライヤーの実装ごとにコスト プロパティを設定します。
4. 各実装を評価して最適な価格を決定し、適切な実装に発注する CheckBestRetailer クラスを作成します。

アプローチ 2:

1. Cost プロパティと PlaceOrder() メソッドを使用してタイプのサプライヤのリストを作成します。
2. 各サプライヤに対して、データ レイヤーは新しいサプライヤ タイプをリストに追加し、データベースから取得したコストの詳細を設定します。
3. CheckBestRetailer クラスはそのリストをループし、各オブジェクトを評価して最適な価格を見つけ、適切な実装に注文を出します。

上記の2つのうち、アプローチ1はOOPに近いと思いますが、一定数のサプライヤーがいる場合. データベースから取得したデータに応じてサプライヤーの数が変わる可能性がある場合は、アプローチ 2 の方が優れています。

どう思いますか？

OOAD をテストするための最適なシナリオがここにない可能性があります。私も一緒に作業できるいくつかのサンプル シナリオがあればいいのにと思います... 可能であれば、デザインのヒントがあれば。

御時間ありがとうございます。

最近、オブジェクト指向の分析と設計について勉強していて、全体的にかなり良い感じになったと感じています。

しかし、この小さなシナリオは私を悩ませ続けています。

私が単純なボードゲームを設計しているとしましょう。ボードとプレーヤーに関する情報を保持するクラス Game があります。プレーヤーはクラス Player から作成されます。すべてのプレイヤーは、クラス BankAccount から作成された銀行口座を持っています。

My Game は、移動後に何が起こるべきかについてのロジックを処理します。ほとんどの場合、これにはプレイヤーの銀行口座からの引き出しまたは入金が含まれます。

My BankAccount には、残高の引き出し、入金、および返却の方法があります。しかし、私のゲームはプレイヤーの銀行口座を知りません。プレイヤーについてのみ。Player クラスにメソッド getAccount を与えて、呼び出すことができるようにしplayerObject.getAccount().withdraw()ますか? または、この行動の責任をどのように割り当てることができますか? Player クラスは、関連するアカウント オブジェクトをwithdraw()呼び出すだけのメソッドを実装する必要がありますか?account.withdraw()

職業訓練を管理するためのシステムには、CourseBase抽象クラスがあります。これは、仮想の基本エンティティICourseから派生したすべてのクラスの実装コードの重複を避けたいため、インターフェイスを優先して使用することにしました。Course各コースには、科目のリストがあり、任意の科目がSubjectBase抽象クラスによって定義されています。だから、私は例えば

LocalCourseここで、オブジェクトのコレクションを含む具象クラスを追加したいのですLocalCourseSubjectが、のインターフェイスを使用していないためCourseBase、共分散を失いSubjects、新しいもので抽象ベースのプロパティを非表示にする必要があります。

OOの観点から、ここで非常に明白な何かが欠けていると確信していますが、私が見ることができる唯一の解決策は次のとおりです。

1. 抽象ベースからSubjectsを完全に省略し、派生クラスに特別に型指定されたコレクションプロパティのみを追加します。
2. ISubjectCollectionOwner抽象ベースや具象クラスなどのインターフェースを実装します。

ここでぼんやりとすみません。このようなデザインの問題に遭遇することができて久しぶりです。

I am working on a multithread app that has about 4 basic Entities at its core

e.g

I have a 4 step process where I am using the Producer/Consumer Pattern with BlockingCollections to manage these process's. It is a production line and I modify state on a object once complete, make a copy of the stats & enque onto the next process queue where it waits for the next process/task to be preformed.

I am at that critical juncture of architecture design of whethere I need to look at serializing some of the BlockingCollections to DB or can I run with about 10 million objects of the type above in the Pipe on a Highend server.

I have a queue dedicated to stats on each process I.e Timetaken/Success for the UI Or should I look at storeing this info with the objects ?

Speed/Effeciency is crtical in this process.

Are there any ways to calculate Memory requirements or is this a case of suck it & see

Update At this stage I dont need to persist the data for crashes etc as the metadata objects are modified and writen out to disk...i.e unprocessed folder/processed folder

最近はオブジェクト指向デザインをやっています。ORMとしてEF4.1も使用しています。クラスとその関連付けを設計するとき、2つのアプローチを考えることができます。1つは、たとえば、教師が科目を教えることです。したがって、Teacherクラスは、サブジェクトオブジェクトの参照をプロパティとして持つことができ（参照ベースのアプローチ）、SubjectIdをプロパティとして持つことができます（IDベースのアプローチ）。どのアプローチをとるべきか、そしてその理由がわかりません。IDベースのアプローチはリレーショナルデータアプローチであり、参照ベースのアプローチは真のOOアプローチであると私は信じています。しかし、私にはわかりません。

XML ファイルを解析するプロセスがあります。

これは、パッケージ クラスで発生しています。

Package クラスには、オブジェクトを無効な状態に設定し、Package クラスで発生したエラーに関する詳細情報を取得する Delegate があります。

簡単にするために、パッケージに渡される filitem を示しています。

つまり `

パッケージ内での検証は次のようになります

この検証では、ラベルに "" が返されるかどうかを確認します...もしそうなら、エラー情報で Failpackage を呼び出し、例外を作成します

含まれている try catch ブロックを介してキャプチャされる

私の懸念は、プログラムフローの例外を使用していることです...他にどのようにこの問題にアプローチする必要があるか、これは有効なパターンですか.

次のようなクラスを持つC＃コンポーネントがあります。

別の既存のC＃アプリケーションでは、このコンポーネントを参照しています。この同じクラスをインスタンス化する必要がありますが、以下のように追加の識別子を使用します。

クライアントアプリケーションには、追加の識別子に依存するいくつかのメソッドがあります。そのため、コピーコンストラクターをエミュレートしてこのオブジェクトを作成し、追加のパラメーターを入力するのは非常に魅力的です。このようにして、クラスへの変更を最小限に抑えながら、既存の関数をそのまま使用できます。

別の方法は、クライアント側の実装への参照として残りの詳細を追加することです。

どちらのオプションが良いですか？この点でのベストプラクティスは何ですか？

環境：VS2008、C＃、WinXP / Win7

次の問題は何ですか?また、オブジェクト指向の原則を使用してより適切に実装するにはどうすればよいですか?

Shape私のアプリにはCircle、Rectangle、Triangle、 などからすべて継承する多数の形状クラスが含まれています。これらの一部は画面に表示する必要があり、その場合、共通の画面ロジックを活用する必要があるためScreenShape、共通のロジックを含むスーパークラスがあります。およびScreenCircle、ScreenTriangle子クラス。

まったくリファクタリングされていないコードがあります。ある程度リファクタリングしましたが、これ以上何も考えられないところに行き詰まりました。

トラクター.java:

TractorInDitchException.java

MethodsInterface.java

他に何をリファクタリングできますか...何か提案はありますか?

唯一の操作として領域を含む Shape があるという要件があるとします。では、抽象メソッドとして area() を使用して、インターフェイスまたは抽象クラスを使用する必要がありますか? この質問をする理由は次のとおりです。純粋なオブジェクト指向の用語では、すべての動作がメソッドにマップされ、属性がデータ メンバーにマップされます。それで、領域はクラスの動作または（計算された）属性ですか？そして、特定のユースケースにはどちらが適していますか? メソッドとして area() を使用するインターフェイス、または抽象メソッドとして area() を使用する抽象クラス ?