2009-02-28 4 views
5

Предположим, мне нужно смоделировать блюда закусочной.Как смоделировать сложные отношения роли, в которых могут участвовать только определенные группы сущностей?

Обед может состоять из нескольких «компонентов»:

  1. (Fries или риса или клиньев)
  2. И (один из шести различных напитков)
  3. И (один или два из семи различных соусы или вообще)

Другая еда может состоять из:

  1. (салат или рис)
  2. И (чеснок или нет чеснок)

Дальнейшие блюда могут состоять из:

  1. Just мальков

  2. Просто напиток

  3. Просто ...

Как смоделировать это? (UML, сущность-связь, код, ... все, что вы можете объяснить лучше)

Возможно, это помогает, если вы знаете, некоторые задачи, которые я хочу выполнить, так:

  • Предоставление клиенту выбрать еду сначала и отобразите все оставшиеся «надстройки».
  • Обнаружение еды из списка компонентов. Например, если заказчик заказал картофель фри, соус и напиток, можно было бы определить прием пищи из первого примера.

Я думал о разделении всех компонентов на статьи, а затем добавил какое-то ролевое отображение, чтобы отметить «фри» в качестве дополнения к «чизбургер», «шницель», «...», но потом я подумал: как я могу моделировать несколько дополнений, необязательные дополнения, п-из-м дополнений ...

Я надеюсь, что вы можете помочь мне ...

ответ

1

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

Было бы гораздо лучше иметь класс элементов пищи и класс напиток со свойством имя или некоторые такие ..

Представьте себе, чтобы восстановить всю вашу заявку только потому, что теперь новый специальный или пищевой пункт ... не круто ;).

Я думаю, что отсутствие других ответов - это идея группы. Каждый пищевой продукт может принадлежать группе вместе с другими предметами или сам по себе.

Скажите, что картофель фри, рис и клины принадлежат группе A. Напитки принадлежат группе B. Тогда вы можете смоделировать комбо в виде списка групп - т.е. 1 группа A и 1 группа B, или две группы A и элемент группы B.

Вы также можете сделать продукты питания способными принадлежать нескольким группам одновременно ... чтобы сделать варианты более гибкими.

Модель db может быть сложной, определяя все отношения, но я думаю, что это необходимо.

Возможно, что-то вроде этого:

group(id, name, desc) - группа, как предметы - блюд, закусок, напитков ... или что-нибудь

foodItem(id, name, desc) - представляет один элемент - картофель, рис и т.д.

foodItem_group(foodIgem_Id, group_Id) - карты продуктов питания в своей группе - многие ко многим

combo(id, name, desc) - описывает комбо

combo_group(combo_Id, group_Id) - карты группы в комбо - многие ко многому

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

+0

Я склонен согласиться.(И это не домашнее задание :)) –

+0

добавил немного больше .. надеюсь, полезно. – markt

0

Я предполагаю, что это будет в конечном итоге получить в базе данных. Я предлагаю создать две таблицы:

  1. бы хранить компоненты (картофель фри, салат, чеснок и т.д.)
  2. Бы: ID1, ID2, отношения. Отношения являются:
    • принадлежит
    • идет с

На основе «принадлежит» отношения, вы могли бы найти, если все компоненты принадлежат к определенной еде.Может быть, тогда идите и выберите все компоненты, которые принадлежат этой еде, и предложите еду, если выбранные компоненты составляют 50% или больше еды.

Основываясь на отношениях «идет с», вы можете предлагать дополнения к еде или к выбранным компонентам.

+0

Как определить, например, что по крайней мере на трех компонентах необходимо пойти с едой? –

1
  1. Похоже, что заказ может состоять либо из пищи, компонентов или смеси обоих, так что я бы сказал, есть Order класс, который имеет список Component с и Meal с. Meal должен либо подкласс Component, либо они должны реализовывать один и тот же интерфейс.
  2. A Meal состоит из нескольких слотов, которые могут быть заполнены набором Component. Meal s должен знать, сколько слотов у них есть и что Component s может их заполнить.
  3. «Обнаружение Meal из списка Component s» вопрос сложный. В верхней части моей головы лучший способ, который я могу придумать, - дать каждому Meal метод, который принимает список Component s и возвращает true, если из них можно сделать Meal (или, может быть, подмножество Component s, которое будет составлять это Meal). Order будет проходить через список Meal, о котором он знает, и посмотреть, можно ли их сделать из Component s в текущем Order. Однако может быть лучший способ сделать это.

Надеюсь, это поможет!

+0

Спасибо за ваш ответ, но насколько я понимаю (2.), вы, кажется, просто перефразировали мое первоначальное требование :) Возможно, вы можете уточнить. –

+0

Есть ли какая-то конкретная деталь, которую вы смутили, что я могу объяснить лучше? –

+0

Я думаю, что Аманда на правильном пути. Другие вещи, которые следует учитывать: используя интерфейс iMeal, а затем конкретные «типы» блюд, например. Обед реализует iMeal, но позволяет только две стороны, Ужин реализует iMeal и позволяет использовать три стороны. –

1

Компонент класс и подсловы (или объекты) для всех возможных типов компонентов.

Создать аннотация Питание класс и подклассы для всех возможных видов блюд. Питание может проверить, соответствует ли определенный список компонентов (для обнаружения еды из списка компонентов). И еда может представить клиенту все варианты компонентов для этой еды.

Я согласен с Амандой в том, что питание должно быть построено из «слотов». Каждый слот представляет собой один из вариантов выбора компонента для питания, например. Жареный рис или рис. Слот также может моделировать опцию m-outof-n.

хлебный Класс:

class Meal 
{ 
    class MealSlot 
    { 
     Add(Component); 
     bool DoesItMatch(vector<Component> ComponentsVector) 
     { 
      //Check if this Slot is filled by some element(s) 
      // of ComponentsVector 
     } 
     PrintSlotOptions(); 
     vector<Component> Options; 

     // for m-of-n option, if multiple items can be chosen in this slot 
     int HowManyNeededToFillIt; 
    }; 

    bool DoesItMatch(vector<Component> ComponentsVector) 
    { 
     //Check if all Slots are filled by ComponentsVector elements, 
     //using Slot::DoesItMatch function 
    } 
    void PresentChoices() 
    { 
     for(i=0; i < Slots.size(); i++) 
      Slots[i].PrintSlotOptions; 
    } 
    vector<Slot> Slots; 
}; 

Один из бетона Питания: (салат или рис) и (чеснок или нет чеснока)

class MealType2 : public Meal 
{ 
    MealType2() 
    { 
     Slots[0].Add(Salad); 
     Slots[0].Add(Rice); 
     Slots[1].Add(Garlic); 
     Slots[1].Add(NOTHING); 
    }  
}; 

Создания заказа класса, который будет содержать Meal имя и список компонентов. Если заказана еда, вызовите Meal.PresentChoices(). И если список компонентов указан, перейдите все блюда и вызовите Meal.DoesItMatch.

+0

Как бы я смоделировал «m-out-of-n components»? –

+0

обновленный ответ, см. Внутри –

0

кажется, что вы можете быть почти любой коллекцией продуктов питания, поэтому начните с одного абстрактного базового класса (или интерфейса) для питания. сделайте много конкретных подклассов, по одному на каждую пищу: кокс, чай, стейк, курица, картофель, рис, макароны, суп, салат и т. д.

сделать ваши компоненты интерфейсами: закуска, ужин, белок, крахмал, десерт, пить и т.д.

реорганизуйте свои конкретные классы в любую иерархию, в которую они, похоже, захотят войти, когда вы пишете код и тесты.

посыпьте в интерфейсах компонентов, где они имеют смысл.