2009-12-10 2 views
2

Я работаю над своеобразным приложением HMI и создаю объекты для определения конкретной машины. Скажем, это автомобиль ради аргумента.Насколько подробно должен быть объект?

Объект для двигателя очевиден. На двигателе имеется несколько общих датчиков, и это несколько объектов, монтирующих несколько свойств объекта двигателя. Разумеется, свойство дроссельной заслонки - это вход.

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

Теперь, следует ли открывать дверь в качестве объекта на объекте автомобиля, или было бы разумнее сохранить его в частном порядке и иметь объект автомобиля, работающий с дверью в функциях OpenDoor и RollDownWindow? Как насчет событий? Должен ли я показывать события на двигателе, например, событие LowOnOil, или я должен иметь дело с ним в объекте автомобиля, в котором, в свою очередь, может быть событие, такое как EngineIsLowOnOil?

Как вы это сделаете?

+1

Не было ни одного наилучшего ответа, я думаю, что это относится к вики сообщества. – DOK

+0

@ DOK: Согласен ... :) – rozon

+0

Там * есть один лучший ответ: John R. Strohm's. –

ответ

0

Если сомневаетесь, рассмотреть проблему с другой подход: «Как бы я проверить эти объекты? " «Как я могу проверить окно?» «Что бы облегчить тестирование?» Будучи ленивым программистом, для меня очень важный вопрос. Я хочу, чтобы тесты были грязными, но очень эффективны, доказывая, что мой код работает.

В вашем случае у вас есть автомобиль с дверями, которые могут открываться и закрываться, а в дверях есть окна, которые могут открываться и закрываться, и они могут или не могут быть электрически управляемы. Как бы вы протестировали функцию «window-down»? Является ли существование окна зависимым от двигателя? Это даже зависит от автомобиля, или он действительно зависит только от двери? У разных дверей разные окна с разными правилами или разные поездки? Используют ли разные двери одинаковые электродвигатели для привода окон, или же оконные двигатели отличаются для левого монтажа или правого монтажа?

И подумайте, что клиент может дать вам требование, согласно которому «окна работают только при работе двигателя», но это правда? В большинстве автомобилей окна работают, когда выключатель питания автомобиля повернут на «включено». Иными словами, зависит ли работа окна от вращающегося коленчатого вала в двигателе, или это действительно зависит от 12 вольт электричества? Так вам действительно нужен экземпляр двигателя в машине, чтобы проверить окно, или вам просто нужна батарея?

Как только вы начнете задавать эти вопросы, вы, вероятно, сделаете вывод о том, что окно электропитания заслуживает собственного набора тестов (вверх/вниз/частично/полноправное движение/и т. Д.), Поэтому оно становится хороший кандидат на то, чтобы быть его собственным классом. Количество разных дверей может быть сложным, поэтому вы считаете, что «завод двери» может быть подходящим классом для создания, который может управлять всеми различными видами дверей. Тестирование вещей в изоляции всегда проще: посмотрите на более сложные вопросы о настройке дроссельной заслонки двигателя для проверки функции окна? Что относительно передачи или открытия/закрытия двери? Все эти перестановки затрудняют тестирование, хотя они не влияют на работу окна или нет. Таким образом, все это заставило меня подумать, что классы окон должны быть проверены как можно более автономно. В реальном мире вам нужно всего лишь 12 вольт, чтобы проверить окно власти, установленное в двери. Таким образом, в вашем смоделированном мире вам нужен только макет или поддельный источник питания, чтобы обеспечить смоделированную мощность, а не объект двигателя или передачу. Это более простой тест.

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

Возможно, вы даже начинаете с простого, но хрупкого класса автомобилей с жестко закодированным двигателем и жестко закодированными дверями, а затем реорганизуете его, чтобы добавить тесты, подобные приведенным выше. Вероятно, вы все равно останетесь с независимыми объектами «Автомобиль», «Дверь» и «Окно» и абстрактным шаблоном фабрики, чтобы создать их все на основе модели автомобиля, который строится. Эта идея называется «эмерджентным дизайном».

8

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

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

+1

Система впрыска топлива будет объектом, содержащимся в двигателе. Должен ли объект двигателя выставлять топливную систему в качестве собственности или оставить ее закрытой? Допустим, это турбосистема, и вы хотите, чтобы давление в турбине ... Expose только то, что нужно, или вся топливная система? – rozon

+1

@rozon, общее эмпирическое правило, раскрывает только то, что вам нужно. Если вам нужно разоблачить топливную систему на более поздний срок, тогда это должно быть достаточно легко сделать. – James

+2

Невозможно сказать, не зная домена. Кажется, вы жаждете, что существует один «правильный» способ создания дизайна объекта. Это не тот случай. – 2009-12-10 12:52:23

2

Я думаю, что это очень общий вопрос, на который трудно ответить. Мой лучший ответ: «Это зависит от ваших потребностей и проблемной области, которую вы пытаетесь решить».

0

Мне нравится держать вещи просто. В вашем домене/объектах подумайте, как бы вы говорили об объекте, чтобы определить, как его моделировать, скажете ли вы, что мой автомобиль нуждается в масле, или двигатель моего автомобиля нуждается в нефти?

Это зависит от области. Домен для автозавода будет относиться к автомобилям иначе, чем к аренде автомобилей.

У меня было бы много свойств окна для каждого окна и событий, находящихся вне их, а также состояние окна и положение.

+0

@Burt 9x из 10 самых разных людей скажут: «Мой автомобиль нуждается в масле», хотя на самом деле это двигатель. Это не совсем так, поскольку по существу двигатель составляет автомобиль, поэтому вы можете просто решить эту проблему, разоблачив метод быстрого доступа, если хотите, что-то вроде автомобиля.FillOil, который внутренне вызывает Engine.FillOil. – James

2

В сценарии, который вы указали, я обычно склонен думать об этом в реальной ситуации .

Таким образом, дверь не является частной для автомобиля, то есть дверь автомобиля общедоступна. Автомобиль не открывает дверь (если это не крутая машина!) Пользователь откроет дверь. Следовательно, дверь, вероятно, должна быть государственной собственностью автомобиля.

С точки зрения раскрытия событий, это действительно зависит от того, собираетесь ли вы их передавать. Например, событие OnLowOil, вероятно, является событием, которое вы хотели бы обработать, то есть уведомить пользователя, который тогда мог бы сделать Car.Engine.FillOil

+0

В отношении двери мне трудно различаться между автомобилем и дверью. Двигатель с другой стороны; Вероятно, у него много датчиков, которые могут привести к уведомлению NeedService на панели управления. Вместо того, чтобы подключать все события к движку, не было бы лучше, если бы автомобиль разрешил им внутренне, а затем выдал пользователю лучшее (более простое) событие? – rozon

+1

Хорошо подумайте, что сама дверь должна стать его собственным объектом, поскольку она будет иметь такие свойства, как Window/State (open/close) и ее собственные методы, такие как Open/Close. Хорошим примером того, почему моя машина, как и многие другие, говорит мне, что дверь открыта или не закрыта должным образом. Итак, в этом конкретном примере, как вы узнаете, закрыта ли дверь, если у вас нет объекта Door для проверки? Что касается событий, да, там будут ситуации, когда события от двигателя лучше не подвергаться воздействию, но будут события, которые вам нужно будет выставить, это зависит от вашего собственного дизайна. – James

0

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

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

4

Эйнштейн сказал: «Сделайте это как можно проще, но не проще».

Начать с пустого объекта. По мере разработки всей модели добавьте к объекту только те атрибуты, которые НЕОБХОДИМО.

+2

И будьте готовы к рефактору, когда идете. Иногда это означает, что объекты необходимо разделить или объединить, например. –

7

Давайте немного рассмотрим ваш пример открытия двери автомобиля (скажем, спереди слева). Можно было бы взять несколько подходов (в том числе те, которые вы предлагаете):

  1. Car.OpenFrontLeftDoor
  2. Car.OpenDoor (FRONTLEFT)
  3. Car.Door (FRONTLEFT) .Open
  4. Car.Part (DOOR_FRONTLEFT) .Open
  5. Car.Part (DOOR_FRONTLEFT) .DoAction (OPEN)

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

Номер 1 является очень жестким подходом к функции. Это было бы хорошо для очень простых, фиксированных ситуаций. Но это станет неуправляемым, если ваша модель должна соответствовать вариациям.

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

Также имейте в виду, что ваш автомобильный объект может представлять внешний интерфейс, отличный от внутренней реализации. Например, вы можете использовать подход 5 внутренне, но представить интерфейс, такой как в 1, и переводить вызовы функций под капотом (каламбур не предназначен).

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

+0

+1 Хорошая разбивка. – Walter

+0

Мне понравился этот пробой. – rozon

0

Я думаю, что здесь несколько человек делают одну и ту же точку, но я попробую еще раз.

Вы задаете вопросы, как я должен или не должен раскрывать событие «Дверь открыта». На этот вопрос нет ответа, кроме как с другим: как вы собираетесь его использовать?

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

Попытка ответить на эти вопросы на основе одного что-нибудь еще (кишка чувствую?) Будет упражнение в подсчете демонов на конце иглы

Смежные вопросы