Нормально ли это иметь длинный список аргументов в конструкторе класса Presenter?

Question

Предупреждение о перегрузке аббревиатуры приближается !!! Я делаю TDD и DDD с моделью пассивного просмотра MVP и DI. Я обнаруживаю, что добавляю зависимость за зависимостью в конструктор моего класса докладчика, когда пишу каждый новый тест. Большинство из них являются объектами домена. Я использую фабрики для внедрения зависимостей, хотя, вероятно, со временем я перейду к контейнеру IoC.

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

Я думал о том, чтобы обернуть все доменные объекты в один класс "Домен", который бы действовал как посредник, но у меня такое внутреннее чувство, что я бы только перемещал проблему, а не исправлял ее.

Я что-то упустил или это неизбежно?

Answer 1

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

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

Answer 2

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

Вопрос: Почему вы передаете объекты модели домена конструктору?

Существует такая вещь, как слишком много абстракции. Если есть один надежный слой кода, которому вы должны доверять, это ваша модель домена . Вам не нужно ссылаться на 3 объекта IEntity, когда вы имеете дело с классами Customer, Vendor и Product, если они являются частью вашей базовой доменной модели и вам необязательно нужен полиморфизм.

Мой совет: перейдите в приложение и домен Службы . Доверьтесь своей доменной модели.

EDIT:

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

Я также понимаю, что, возможно, вам нужно ссылаться на объекты Model в коде приложения вне Presenter. Возможно, вы выполняете некоторую начальную настройку объектов Model, прежде чем передать их в Presenter. Если это так, то ваша идея «класса домена» может быть лучшей. Если есть некоторые начальные настройки, при переходе на IoC вы захотите посмотреть что-то вроде Factory Support в Castle Windsor. (Другие контейнеры IoC имеют аналогичные концепции.)

Answer 3

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

Я рекомендую всегда следовать Закону Деметры и не следовать мифу о том, что все должно быть в конструкторе. Миско Хевери (Agile Coach в Google) хорошо описывает это в своем блоге http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/