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

Question

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

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

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

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

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

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

Answer 1

Настоящий ответ «это зависит». Я думаю, что многие разработчики борются с этим на ранней стадии.

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

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

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

Вот ссылка: http://refactoring.com