シナリオ
クラスVehicle
があります。このクラスには、CarBrand
、TransmissionType
、Color
などのオブジェクトを定義するいくつかのプロパティが含まれています..
車(車両)にもオプションがあり、最近は多くのオプションがあります。
私のアイデアは、Options
と呼ばれる別のクラスを作成し、ブール値として必要な必要なオプションをリストし、次にtrue
またはfalse
を使用して決定することです車両にそのオプションがあるかどうか。
これは良いアイデアと怠惰なアイデアのどちらと見なされますか?このために別のクラスを作成する気になるのか、それとも単にすべての情報を車両クラスに入れるのか。設計の観点からだけでなく、この情報を格納するためにデータベースも調べます。
車両クラスを他の複数のクラスの基本クラスにする意図はありません。
私の代わりは単に文字列値の配列です。これは、新しいオプションを追加する際の制限が少なくなり、データベースでのデータ使用の点でさらに優れていると思います(私はそう思います)。
投稿した2つ以外のアイデアも大歓迎です。
はい、コンパイラーにできる限りチェックしてもらいたいので、それは絶対に良い考えです。オプションが文字列のリストである場合、実行時まで、タイプミスは発見されません。
ソリューションに適合するものを確認するために実行できるテストは、次のとおりです。明日新しいオプションを導入する場合は、新しいコードで新しいバージョンをデプロイすることも、構成を介して変更を加えることもできます。
前者の場合、ブールプロパティの束を使用することの欠点はありません。
あなたの質問に直接答えるために:はい、boolean
sのみのクラスを作成することは可能です。
// C# example
public class VehicleOptions
{
public boolean DriversSideAirbags { get; set; }
public boolean PassengersSideAirbags { get; set; }
public boolean FrontCurtainAirbags { get; set; }
public boolean MiddleCurtainAirbags { get; set; }
public boolean RearCurtainAirbags { get; set; }
// Repeat until you run out of options
}
目標を達成する方法は他にもあります。
車両のこのインスタンスに特定のオプションがある場合のためにOptions
をboolean
としてのみ必要とする場合、List<String> Options
をクラスのフィールドとして設定する方が簡単な場合があります。オプションがリストにある場合、インスタンスにはそのオプションがあります。リストの検索は難しくありません。
// C# example
public class Vehicle
{
// If you require unique values for the Options field,
// change the declaration to:
// public HashSet<String> Options
public List<String> Options { get; }
// Other stuff in the class...
public boolean hasOption(string searchItem)
{
// Search the list for any element that contains the searchItem
return this.Options.Contains(searchItem);
}
}
データベースからオプションをロードするのではないかと思います。そのため、リストを使用すると、データとより一致する可能性があります。また、List<String>
をより複雑なリストオブジェクト(List<OptionDetail>
など)に交換する必要がある場合、変換が容易になります。関連する変数のシグネチャを変更するだけです(var
キーワードを使用してそれらを宣言しない場合)。
新しいオプションを選択するたびに新しいバージョンのアプリケーション/ Webサイトを構築して展開する場合は、機能(ビジネス)要件に応じて、ある方法を別の方法よりも選択するのはなぜですか製造元によってリリースされた、コーディングスタイルとチームのスタイル(コードがデータベース構造をオブジェクトとして模倣しているのか、チームリーダー/マネージャーからの指示を示しているのか、その他のさまざまな理由があるのか)。
オプションが名前だけでない限り、フルにOOして、IOption
インターフェイスを作成することもできます(C#はわかりませんが、これは多少コンパイルされるはずです)。
interface IOption {
String optionName();
double optionPrice();
List<IOption> exclusive(); //list of options that can't be selected with with this one
//etc
}
次に、各オプションがそのインターフェースを実装します(そして、必要に応じてそれらを追加できます-UIからオンザフライで含めます)。
class AmazingSound implements IOption {
//blabla
}
それからあなたはあなたの車の中にリストを持っているでしょう。
DB側では、車のテーブル、オプションテーブル、および特定の車のオプションをリストするcar_id、option_idを含むテーブルがおそらくあります。