Понимание «поведения» и размещения методов

1

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

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

Изображение 174551

Действие, которое должна выполнить программа, заключается в добавлении продукта в местоположение. Например, присвоение красной звезды местоположению 10/2/3 на графике выше. Мой вопрос в том, является ли это "поведением/методом" рабочего, корзины или продукта? Когда вы думаете об исполнении, как вы решаете, какой класс? Работник может поместить продукт... продукт можно поместить... и ящик может получить. Кажется, что он может быть реализован во всех 3.

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

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

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

  • 1
    Я не понимаю, какое наследство связано с вашим вопросом. Почему вы почувствовали, что это важно? Я понимаю, почему вы вызвали поведение. Я чувствую, что вы спрашиваете, какие обязанности должен иметь каждый класс. Это правильно?
  • 0
    Это, вероятно, не стоит для этого простого проекта, но другой подход рассматривает отношения как график.
Показать ещё 5 комментариев
Теги:
methods
standards

1 ответ

3
Лучший ответ

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

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

Моя лучшая рекомендация - купить (или взять) копию книги Мартина Фаулера "Рефакторинг" и прочитать его фильм "Прокат" в первой главе (я считаю). Он показывает простой пример и то, как он реорганизует его со временем из-за меняющихся требований. (Его тривиальный пример демонстрирует некоторые из тех же проблем, которые вы выражаете. Если класс аренды, класс фильма или класс клиента обрабатывают эти требования.) Не только вы должны прочитать его пример, вы должны следовать в своей собственной среде IDE. И вы должны попытаться самостоятельно разобраться, чтобы понять, что вы придумали, учитывая те же самые изменяющиеся требования.

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

Здесь ссылка: http://refactoring.com

  • 1
    Я посмотрю на эту книгу. Спасибо за ваш ответ.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню