OOD: выявление проблемных объектов

Question

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

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

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

Должен ли сотрудник иметь учетную запись Timecard, или если Timecard ссылается на сотрудника?

Должен ли Timecard отвечать за расчет часов в течение дня и т. Д.?

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

Должен ли Timeclock делать punchIn и punchOut или Employee?

Answer 1

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

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

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

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

Answer 2

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

Должен ли сотрудник иметь учетную запись Timerard, или если Timecard ссылается на сотрудника?

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

* Если Timecard нести ответственность за расчета часов в течение дня, и т.д.? **

Должен ли он?

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

Есть ли часы, создающие экземпляр сотрудников?

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

же ...

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

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

См this answer от Steve A. Lowe

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

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

Answer 3

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

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

Сотрудник должен иметь временную карту. Если бы это была карта в реальном времени, вы ее несете. Вы не были бы в кармане карты времени.

Должен ли Timecard отвечать за расчет часов в течение дня и т. Д.?

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

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

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

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

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

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

Answer 4

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

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

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

Должно ли Timecard отвечать за расчетных часов за день и т. Д.?

Я сделал бы то, что релевантность TimeCardCalculator.

Если Timeclock ответственность для инстанцировании работников и табелей и соотнесение их?

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

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

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

Answer 5

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

Хорошо, так что довольно ясно, что у сотрудника есть Временная карта, которая является списком времени начала и остановки.

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

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

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

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

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