Является ли это звуком Objected Oriented Design для сайта электронной коммерции?

Question

Я довольно новичок в OOP / OOD, и я понимаю, что мне есть чему поучиться, поэтому я хотел бы попросить SO-сообщество поделиться их мнением.

По сути, я использую инфраструктуру CakePHP MVC, а созданный мной онлайн-магазин использует только две модели, Category и Product, описанные следующими операторами CREATE:

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`)
);

Интернет-магазин будет охватывать:

• Музыка
  • Компакт-диски
  • DVD-дисков
• Одежда
  • Толстовки
  • Футболки
    • Тройники с длинными рукавами
    • Эротические
  • Головные уборы
• Разное Мерч
  • наклейка
  • Плакаты
  • Сумки Tote
• Загрузки
  • Мелодия
  • 1047 * MP3 файлы *

По сути, это структура дерева категорий, хотя мы можем добавлять новые категории в будущем. В настоящее время все продукты обрабатываются одинаково как объекты класса Product, и их category_id является единственным способом различать различные типы продуктов. Интернет-магазин также является лишь одним разделом сайта. Остальная часть сайта содержит такую ​​информацию, как биографии художников и дискографии; таким образом у меня также есть модели / таблицы для: Исполнитель , Альбом , Трек .

Это хороший подход? Или я должен создавать отдельные подклассы для компакт-дисков / футболок / MP3 / ..., которые наследуются от класса Product? Я хотел бы связать каждый музыкальный компакт-диск в магазине с записью дискографии, чтобы автоматически создавать списки треков и другую информацию для описания продукта.

Если это не очень хороший путь, как бы вы это сделали? Кроме того, какие методы / свойства я должен включить в свой класс Category / Product? И я должен только перечислять продукты в листовых узлах дерева категорий?

Редактировать:
Очевидно, этот дизайн является неполным. Как указал Кирилл, поле Product.price отсутствовало, и по-прежнему нет резервов для продаж. На самом деле я все еще пытаюсь понять, как лучше спроектировать и реализовать эти аспекты магазина. Скорее всего, у меня просто будет другая модель под названием Orders , но на самом деле обработка заказов усложняется тем, что мы применяем разные тарифы на доставку в зависимости от места назначения и того, что содержится в заказе.

Answer 1

Мне больше нравится подход «конфигурация + поведение» вместо подклассов.

Это может быть немного поведения на уровне категории. В зависимости от сценария, некоторые виды поведения могут быть связаны с отдельными типами продуктов, например, что-то, что относится к определенным продуктам независимо от категорий. Для этой последней части предложение о курении также имело бы большой смысл, так как вы могли бы связать это дополнительное поведение с дополнительными категориями. Таким образом, пока вы работаете с уже закодированными поведениями, вы можете добавлять новые категории, указывающие, какие поведения он будет поддерживать.

Небольшой вариант - список поведений, связанных с категориями, а не с битами.

Дополнительные классы были бы для поведения, вместо того, чтобы смешивать все под классами продукта. Если вам необходимо связать пользовательский интерфейс для этих дополнительных вещей, вы можете связать его с поведением, независимо от типа продукта.

Answer 2

Вы все еще можете вести таблицу продуктов и создавать различные «подкатегории продуктов», если используете полиморфное поведение . Это простой способ хранить все общие данные в одном месте (цена и т. Д.).

В качестве альтернативы, вы можете использовать то же самое полиморфное поведение в таблице атрибуты и добавить что-нибудь специфичное для продукта в качестве атрибута (имя => пары значений). Все зависит от идеи в вашей голове и количества данных.

Первое решение, вероятно, лучше, если вы планируете иметь большую базу данных.

Answer 3

Вы должны пропустить столбец category_id и смоделировать отношения больше как облако тегов. Вы хотите связать каждый продукт с одной или несколькими категориями.

Вы должны пропустить столбец artist_id и смоделировать отношения больше как облако тегов. В конечном итоге вы захотите связать какой-либо продукт с несколькими исполнителями.

Категории датированы, вы ДОЛЖНЫ использовать облака тегов. Как правило, вы НИКОГДА не должны создавать таблицы с оператором ссылки; ЕСЛИ У каждого столбца в таблице нет оператора ссылки.

Answer 4

Да, вам, вероятно, следует создать отдельные подклассы для различных типов продуктов, особенно если они будут иметь специфическую функциональность типа. Как автоматическое создание списков треков, которые вы упоминаете.

Но даже без этого, используя отдельно названные классы продукта, вы сделаете код более читабельным и логичным при работе с кодом, специфичным для типа продукта.

Вы также можете создать более конкретную модель базы данных. Как

стол: продукт
prod_id
... обычные вещи ..

product_clothes
prod_id
... Одежда для конкретной вещи ...

product_music
prod_id
... музыка специфическая ...

product_merch
prod_id
... товары для конкретного товара ..

Поскольку размер музыки не измеряется в дюймах, а одежда не имеет битрейта.

Answer 5

Нет,

Вам определенно не следует создавать отдельные подклассы, если только вам не нужно какое-то волшебство mumbo-jumbo (например, логотипы на футболках и т. Д.), Которое невозможно достичь простым разделением на категории). Даже в этом случае вы можете безопасно добавить дополнительное поле флага в класс категории (например, HasLogo).

Но дизайн меня пока не впечатляет. Какой тип магазина не предусматривает продажи? А как насчет ценового поля?

Ради гибкости вы также можете поместить изображение в отдельную таблицу.

Для чего вы используете lft / rght? Вы можете использовать простое свойство Inde для хранения места категории в дереве, но помните, что вам нужно будет обновлять каждый раз, когда вы удаляете / добавляете категорию.