0

私はOOP/OODにかなり慣れていませんが、学ぶことがたくさんあることに気付いたので、SOコミュニティに意見を求めたいと思います。

基本的に、私はCakePHPのMVCフレームワークを使用しており、構築しているオンラインストアは、次のCREATEステートメントで記述されたCategoryとProductの2つのモデルを使用しています。

CREATE TABLE `categories` (
    `id` int(11) unsigned NOT NULL auto_increment,
    `name` varchar(255) default NULL,
    `parent_id` int(11) default NULL REFERENCES categories(`id`),
    `lft` int(11) default NULL,
    `rght` int(11) default NULL,
    PRIMARY KEY (`id`)
);
CREATE TABLE `products` (
    `id` int(11) unsigned NOT NULL auto_increment,
    `name` varchar(255) default NULL,
    `artist_id` int(11) default NULL REFERENCES artists(`id`),
    `description` text default NULL,
    `category_id` int(11) default NULL REFERENCES categories(`id`),
    `status` enum('in stock', 'pre-order', 'out of stock') NOT NULL,
    `price` decimal(6,2) default NULL,
    `picture` varchar(255) default NULL,
    `picture2` varchar(255) default NULL,
    PRIMARY KEY (`id`)
);

オンラインストアには以下が含まれます。

  • 音楽
    • CD
    • DVD
  • 衣服
    • パーカー
    • Tシャツ
      • 長袖Tシャツ
      • 赤ちゃんの人形
    • 帽子
  • その他の商人
    • ステッカー
    • ポスター
    • トートバッグ
  • ダウンロード
    • 着メロ
    • MP3

基本的にはこれがカテゴリツリーの構造ですが、将来的には新しいカテゴリを追加する可能性があります。現在、すべての製品はProductクラスオブジェクトとして同等に扱われ、category_idがさまざまなタイプの製品を区別する唯一の方法です。オンラインストアもサイトのほんの一部です。サイトの残りの部分には、アーティストの経歴やディスコグラフィーなどの情報が含まれています。したがって、 Artist、Album、Trackのモデル/テーブルもあります。

これは良いアプローチですか？または、Productクラスから継承するCD/Tシャツ/MP3/ ...用に個別のサブクラスを作成する必要がありますか？ストア内の各音楽CDをディスコグラフィーエントリにリンクして、製品説明のトラックリストやその他の情報を自動的に生成したいと思います。

これが物事を進めるのに良い方法ではない場合、代わりにどのようにそれを行いますか？また、Category / Productクラスにはどのメソッド/プロパティを含める必要がありますか？また、カテゴリツリーのリーフノードにのみ製品をリストする必要がありますか？

編集：
明らかに、この設計は不完全です。Cyrilが指摘したように、Product.priceフィールドが欠落しており、販売の準備はまだありません。私は実際、ストアのこれらの側面を設計および実装するための最善の方法をまだ模索しています。ほとんどの場合、Ordersという別のモデルがありますが、実際には、配送先と注文に含まれる内容に基づいて異なる配送料金を適用しているため、注文の処理はより複雑になります。

4

5 に答える 5

2

サブクラスではなく、構成と動作のアプローチの方が好きです。

これは、カテゴリレベルでの動作のビットである可能性があります。シナリオによっては、カテゴリに関係なく特定の製品に適用されるものなど、一部の動作を個別の製品タイプに関連付けることができます。この最後の部分では、これらの追加の動作を追加のカテゴリに関連付けることができるため、喫煙の提案も非常に理にかなっています。このようにして、すでにコーディングされた動作を使用している限り、サポートする動作を示す新しいカテゴリを追加できます。

小さなバリエーションは、ビットではなく、カテゴリに関連付けられた動作のリストです。

追加のクラスは、製品クラスの下ですべてを混合するのではなく、動作用です。これらの余分なものにUIを関連付ける必要がある場合は、製品タイプに関係なく、UIを動作に関連付けることができます。

于 2009-04-10T02:51:08.363 に答える
1

多態的な動作を使用する場合は、製品テーブルを保持し、さまざまな「製品のサブカテゴリ」を作成できます。これは、すべての一般的なデータ（価格など）を1か所に保持する簡単な方法です。

または、テーブル属性で同じポリモーフィック動作を使用し、製品固有のものを属性として追加することもできます（名前=>値のペア）。それはすべてあなたの頭の中のアイデアとデータの量に依存します。

大規模なデータベースを計画している場合は、最初の解決策の方がおそらく優れています。

于 2009-04-10T13:42:37.953 に答える
1

category_id 列をスキップして、タグ クラウドのような関係をモデル化する必要があります。各製品を 1 つ以上のカテゴリに関連付ける必要があります。

artist_id 列をスキップして、タグ クラウドのような関係をモデル化する必要があります。最終的には、製品を複数のアーティストに関連付けたいと思うでしょう。

カテゴリは古いので、タグ クラウドを使用する必要があります。原則として、参照ステートメントを使用してテーブルを作成しないでください。テーブルのすべての列に参照ステートメントがある場合を除きます。

于 2009-04-10T01:26:37.303 に答える
1

はい、特にタイプ固有の機能を持つ場合は、さまざまなタイプの製品に対して個別のサブクラスを作成する必要があります。あなたが言及したトラックリストの自動生成のように。

しかし、それがなくても、個別に名前が付けられた製品クラスを使用することで、製品タイプ固有のコードを扱うときに、コードをより読みやすく、より論理的にすることができます。

より具体的なデータベース モデルを作成することもできます。お気に入り

表: 製品
の prod_id
...一般的なもの..

product_clothes
prod_id
...服固有のもの...

product_music
prod_id
...音楽固有のもの...

product_merch
prod_id
...商品固有のもの..

音楽にはインチ単位のサイズがなく、服にはビットレートがないからです。

于 2009-04-10T00:37:19.573 に答える
0

いいえ、

単純なカテゴリ分割を実現できない巨大なジャンボ マジック (カスタム T シャツ ロゴなど) が必要でない限り、個別のサブクラスを作成しないでください)。その場合でも、カテゴリ クラス (HasLogo など) に追加のフラグ フィールドを入れても安全かもしれません。

しかし、デザインはまだ私を感動させません。売り場がない店ってどんな店？価格フィールドはどうですか？

柔軟性のために、Picture を別のテーブルに配置することもできます。

lft/rght を何に使用していますか? 単純な Inde プロパティを使用してツリー内のカテゴリの場所を保存できますが、カテゴリを削除/追加するたびに更新する必要があることに注意してください。

于 2009-04-10T00:57:24.270 に答える