0

私はオブジェクト指向プログラミングに少し慣れていないので、概念を学んでいます。今のところ、クラスを論理的に整理するための助けが必要なだけです。私が理解できるメソッド、属性、およびコンストラクターに関する部分。私はこの次の問題を割り当てられました。

Holiday Travel Vehiclesは、新しいRV車とトラベルトレーラーを販売しています。新しい車両がHolidayTravelVehiclesに到着すると、新しい車両レコードが作成されます。新しい車両レコードには、車両のシリアル番号、名前、モデル、年式、メーカー、および基本コストが含まれています。顧客がHolidayTravelVehiclesに到着すると、販売員と協力して車両の購入について交渉します。購入が合意されると、販売員が販売請求書に記入します。請求書には、完全な顧客情報、下取り車両に関する情報（存在する場合）、下取り手当、および購入した車両に関する情報を含む、購入が要約されています。顧客がディーラーがインストールしたオプションを要求した場合、それらは請求書にも記載されています。請求書には、交渉価格も要約されています。加えて、該当する税金とライセンス料。トランザクションは、売上請求書に顧客の署名を付けて終了します。

これまで私が考えていたのは、車両情報と顧客情報が請求書に記載されているため、顧客と車両のサブクラスで請求書をスーパークラスにすることです。しかし、車両はディーラーに到着すると記録を取得するので、エンジンを搭載しているものと搭載していないものがあるので、サブクラスのトラベルトレーラーとRVを使って車両を独自のクラスにすることも考えました。ただし、請求書で車両記録と車両情報を作成している場合、車両を独自のクラスと請求書のサブクラスの両方にすることはできません（私が言っていることがすべて意味をなさない場合は、本当に混乱して申し訳ありません）。では、これらのクラスをどのように配置する必要がありますか？私は本当に迷っています。

4

3 に答える 3

2

Holiday Travel Vehiclesは、新しいRV車とトラベルトレーラーを販売しています。新しい車両がHolidayTravelVehiclesに到着すると、新しい車両レコードが作成されます。新しい車両レコードには、車両のシリアル番号、名前、モデル、年式、メーカー、および基本コストが含まれています。顧客がHolidayTravelVehiclesに到着すると、販売員と協力して車両の購入について交渉します。購入が合意されると、販売員が販売請求書に記入します。請求書には、完全な顧客情報、下取り車両に関する情報（存在する場合）、下取り手当、および購入した車両に関する情報を含む、購入が要約されています。顧客がディーラーがインストールしたオプションを要求した場合、それらは請求書にも記載されます。請求書には、最終的な交渉価格に加えて、該当する税金とライセンス料も要約されています。

  1. このシナリオで説明されているデータエンティティを特定します（6つあるはずです）。顧客は、Holiday Travel Vehiclesから最初に購入するときに、顧客IDが割り当てられます。顧客の名前、住所、電話番号が記録されます。下取り車両は、シリアル番号、メーカー、モデル、および年によって記述されます。ディーラーがインストールしたオプションは、オプションコード、説明、および価格で説明されています。

  2. 各エンティティの属性のリストを作成します。各請求書には、1人の顧客のみが記載されています。人は車を購入するまで顧客にはなりません。時間の経過とともに、顧客はホリデートラベルビークルから多数の車両を購入する可能性があります。すべての請求書は、1人の営業担当者のみが記入する必要があります。新しい営業担当者は車両を販売していない可能性がありますが、経験豊富な営業担当者はおそらく多くの車両を販売しています。各請求書には、1台の新しい車両のみが記載されています。在庫のある新車が販売されていない場合、請求書はありません。車両が販売されると、請求書は1つだけになります。顧客は、車両にオプションを追加しないことを決定したり、多くのオプションを追加することを選択したりする場合があります。オプションは、請求書に記載されていない場合もあれば、多くの請求書に記載されている場合もあります。顧客は、新しい車両を購入する際に1台以下の車両を下取りすることができます。下取り車両は別の顧客に販売される場合があり、その顧客は後で別のホリデートラベル車両に下取りします。

  3. Holiday Travel Vehiclesで施行されているこれらのビジネスルールに基づいて、ERDを作成し、適切なカーディナリティおよびモダリティとの関係を文書化します。

于 2012-11-16T13:13:21.903 に答える
1

車両と顧客を請求書のサブクラスにすることは、あまり意味がありません。私が望むのは、車両クラスと顧客クラスを作成することです。次に、請求書クラス内で、車両オブジェクトとそれが指示する顧客オブジェクトのインスタンスを保持できます。

public class Invoice {
    private Vehicle MyVehicle;
    private Customer MyCustomer;
    //...etc
}

public class Customer {
    private String FirstName;
    //...etc
}

public class Vehicle{
    private String Model;
    //...etc
}

トラベルトレーラーとRVクラスの場合、それらは本質的に車両であり、多くの共通変数を車両と共有するため、車両をサブクラス化する方が理にかなっています。あなたが自分自身に尋ねる必要がある質問は、is何か他のもの（RVisは車両）なのか、それともpoints何か（請求書には車両への参照がある）なのかということです。それがはっきりしていることを願っています、それは私が最初にそれを学んだときに私が苦労したことを確かに覚えているものです。

于 2012-09-04T20:27:49.253 に答える
0

1つのヒントを紹介します。一部の要素が機能を共有していることに気付いた場合は、常に継承を使用しますが、共有する機能は1つだけですが、継承を使用します。現在、共通の機能は1つしか表示されませんが、いつの日か、それらが複数の機能を共有していることに気付くかもしれません。

私が言えるもう1つの重要なことは、関係のない要素の階層を構築するべきではないということです。たとえば、スーパークラスの車両と2つのサブクラスの車と馬を構築するべきではありません。おそらく、それらはいくつかの機能を共有していると思いますが、同じカテゴリの要素に含まれていない場合は、より研究された階層の方が適しています。

継承に関連するもう1つの重要なことは、ポリモーフィズムと動的バインディングの概念であり、非常に便利です。

それがあなたに役立つことを願っています、

于 2012-09-04T21:02:14.453 に答える