OOD: проблема идентификации объектов

Question

Это должно быть просто.

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

Итак, у меня есть Сотрудник. У меня есть Timecard, который имеет несколько EventRecords. У меня есть Timeclock, который, конечно, поддерживает время, но также является своего рода интерфейсом для всей модели (возможно).

Должен ли сотрудник иметь временную карту или она должна указывать на сотрудника?

Должна ли Таймкарта отвечать за подсчет часов за день и т. Д.?

Должен ли Тайм-чек отвечать за создание экземпляров «Сотрудники» и «Таймкарты» и их связь?

Должен ли Timeclock выполнять punchIn и punchOut или Сотрудник?

Answer 1

Я думаю, что вы слишком зациклены на физических объектах здесь. Сотрудник, вероятно, хорошо иметь как объект, так как у него есть идентификация, и он является игроком в сценарии, но я не вижу ни Timecard, ни Timeclock, как каких-либо хороших кандидатов в качестве объектов. Timecard - это просто список EventRecords, принадлежащих сотруднику, так что вы также можете хранить их в объекте Employee или в общем списке. Timeclock вообще ничего не делает, но раздает DateTime.Now ...

EventRecord хорош, или, возможно, это может быть объект WorkTime; время пары или punch-in и punch-out. Если в последней записи нет времени на вылет, сотрудник получает удар.

Хранение записей времени в объекте Employee или хранение их в отдельном списке со ссылкой на каждого сотрудника - дело вкуса.

Ну, так как я удалил объекты Timecard и Timeclock, большинство ваших вопросов падают ...;)

Answer 2

Да, такие вещи довольно классические. Самое простое - применить другое правило. мой любимый закон Парнаса: каждый объект «скрывает» что-то, что может измениться в требованиях к его интерфейсу.

Хорошо, ясно, что у Сотрудника есть TimeCard, который представляет собой упорядоченный по времени список времени начала и окончания.

Когда вы "входите" в домен , все, что вы делаете, - это запись "начала времени". Такие звуки, как «вход и выход» могут быть методами TimeCard, и если мы подумаем об этом, это также скрывает возможные изменения требований (например, является ли это записью в базе данных, строкой в ​​плоском файле и Вы храните местное время, время по Гринвичу или UNIX?)

Сотрудник является представителем сотрудника и содержит всю эту информацию, относящуюся к сотруднику; имя, адрес и т. д.

Пока что нет очевидной необходимости в TimeClock, кроме как «реализация» включения и выключения во внешнем мире.

Теперь, когда вы создаете приложение, но должны собираться из домена, и теперь вам понадобится какой-то пользовательский интерфейс, способ аутентификации (установления, какого сотрудника вы хотите) и оттуда получите TimeCard сотрудника - - который предлагает метод для сотрудника. Тогда вам нужно место для «входа» и «отключения» в пользовательском интерфейсе. Это звучит так, как будто ваш timeClock вполне может быть объектом View в реализации. Требуется пара кнопок и какой бы ни был ваш протокол входа в систему.

Еще одна часть здесь - это «бизнес-процесс» или «сначала войдите в систему, затем войдите в систему. Позже выйдите из системы, затем выйдите из системы» или что-то подобное. Там есть контроллер; то, как вы это разделите, зависит от того, как вы работаете с пользовательским интерфейсом.

Answer 3

Это хороший пример того, когда ваша OO-модель должна отражать реальный мир.

Должен ли сотрудник иметь временную карту или она ссылается на сотрудника?

У работника должна быть временная карточка. Если бы это была карта в реальном времени, вы бы понесли ее. Вы не были бы в кармане тайм-карты.

Должна ли Таймкарта отвечать за подсчет часов за день и т. Д.?

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

Должен ли Тайм-чек отвечать за создание экземпляров «Служащие» и «Таймкарты» и связывать их?

Возможно. Что именно является «Timeclock»? Когда я думаю о создании сотрудников и связываю их с расписаниями, я думаю больше о «Офисе». Я не уверен, какова полная область применения вашей модели.

Должен ли Timeclock выполнять punchIn и punchOut или Сотрудник?

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

Редактировать: Как указал TheTXI, сотрудник будет вызывать методы punchIn и punchOut на временной карте. Но сама Таймкарта не несет ответственности за то, чтобы знать, когда начинать или снимать.

Answer 4

Примечание: как и в большинстве моделей, не всегда есть единственный способ сделать это.

Если у сотрудника есть Timecard, или если Таймкарта ссылается на Сотрудник?

Домен предполагает, что у Сотрудника есть Таймкарта (и, как указано, больше, чем Таймкарт с течением времени).

Должна ли Таймкарта отвечать за Подсчет часов за день и т. д.

Я бы сделал так, что ResCouncability TimeCardCalculator.

Должен ли быть ответственен таймер для создания экземпляров сотрудников и Расписания и связанные с ними?

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

Должен ли Timeclock делать punchIn и punchOut, или Сотрудник должен?

TimeClock. Сотрудник вызывает PunchIn / PunchOut в TimeClock.

Answer 5

Просто ответьте себе на эти вопросы с точки зрения конечного пользователя , а не с точки зрения программиста.

Должен ли сотрудник иметь временную карту или она ссылается на сотрудника?

Кому принадлежит таймкарта?

* Должна ли Таймкарта отвечать за подсчет часов за день и т. Д. **

Должно ли это?

Должен ли Тайм-чек отвечать за создание экземпляров «Сотрудники» и «Таймкарты» и их связь?

Инстанцируют ли часы время сотрудников?

Должен ли Timeclock выполнять punchIn и punchOut или Сотрудник?

же ...

Сначала вам нужно проанализировать проблему. Затем разработайте решение и только после этого закодируйте его.

Итак, вы должны отделить каждый процесс от другого. Здесь, кажется, вы анализируете с точки зрения реализации, а затем проектируете и т. Д.

См. этот ответ от Стива А. Лоу

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

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