Как избежать сумасшедшего количества интерфейсов в пользовательском интерфейсе с внедрением зависимостей?

Проблема В
последнее время я много читал о том, что Singletons - это плохо, и как лучше внедрить зависимости (что я понимаю как «использование интерфейсов»). Когда я реализовал часть этого с callbacks / interfaces / DI и придерживаясь принципа разделения интерфейса, я оказался в полном беспорядке.

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

На вершине иерархии пользовательского интерфейса находился класс Application, содержащий информацию о текущем выборе и ссылку на 3d-модель, которая должна отражать изменения. Класс приложения реализовывал 8 интерфейсов, и это была только пятая часть продуктов (/ интерфейсов)!

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

Вопрос
Может ли синглтон подойти для этого проекта?
Если нет, есть ли фундаментальный недостаток в моем мышлении и / или реализации DI, который делает его таким громоздким?

Дополнительная информация о проекте
Тип: корзина для покупок с квартирами, со свистками
Размер: 2 человеко-месяца для кода и пользовательского интерфейса.
Обслуживание: обновлений нет, но может быть «версия 2.0» позже.
Среда: Использование C # в Unity, который использует Entity Компонентная система

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

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

Я думаю, что вопрос является симптомом, а не решением.

Недавно я много читал о том, что Singleton плох, и как лучше внедрить зависимости (что я понимаю как «использование интерфейсов»). Когда я реализовал часть этого с callbacks / interfaces / DI и придерживаясь принципа разделения интерфейса, я оказался в полном беспорядке.

Решение ищет проблему; это и неправильное понимание этого, вероятно, портят ваш дизайн. Вы читали этот ТАК вопрос о DI против Singleton, разные концепции или нет? Я прочитал это как простую упаковку синглтона, чтобы клиенту не приходилось иметь дело с синглтоном. It.is.just.good.old.encapsulation. Я думаю, что это место.

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

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

Если у вас есть сложные строительные проблемы, используйте шаблон фабрики или строителя. Суть в том, что сложная конструкция включена в свой класс, чтобы другие классы были аккуратными, чистыми, понятными и т. Д.

Класс приложения реализовывал 8 интерфейсов, и это была только пятая часть продуктов (/ интерфейсов)!

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

Интересно, твой дизайн "тяжелый". Похоже, мы пытаемся сделать один класс всем или чем угодно. И тот факт, что это класс пользовательского интерфейса, а не класса бизнес-домена, заставляет меня задуматься о разделении интересов.

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

... 3d модель, которая должна отражать изменения.

Многое из этого может вписаться в пользовательские классы коллекции. Это также может быть независимой структурой класса из-за глубины и сложности. Эти две вещи не являются взаимоисключающими.

Читайте о шаблоне посетителя. Это идея иметь целые куски функциональности, абстрактно связанные с различными типами.

Дизайн и DI

90% всех внедрений зависимостей, которые вы когда-либо будете делать, - это передача параметров конструктора. Так говорит тот, кто написал книгу . Хорошо спроектируйте свои классы и избегайте загрязнения этого мыслительного процесса некоторыми смутными представлениями о необходимости использования DI-контейнера. Если вам это нужно, ваш дизайн предложит вам это, так сказать.

Сосредоточьтесь на моделировании торговых домов.

Избегайте подхода Джессики Симпсон к дизайну : «Я совершенно не знаю, что это значит, но я хочу этого».

Следующее просто неправильно:

• Я должен использовать интерфейсы
• Я не должен использовать синглтон
• Мне нужен DI (что бы это ни было)
• Я должен использовать композицию, а не наследование
• Я должен избежать наследства
• Мне нужно использовать шаблоны

«Классовая иерархия» - это немного красного флага. Гипотетический: веб-страница с 5 виджетами. Страница не является предком ни одного из виджетов. Может содержать ссылку на эти виджеты. Но это не предок. Вместо класса heirarchy, рассмотрите возможность использования композиции. Каждый из 5 виджетов может быть создан самостоятельно, без ссылки на другие виджеты или верхнюю страницу. Затем создается верхняя страница с достаточным количеством информации для построения базовой страницы и разметки объектов виджетов (Коллекция), которые передаются ей. Страница отвечает за макет и т. Д., Но не за конструкцию и логику виджетов.

Как только вы используете композицию, DI становится вашим лучшим другом. DI позволяет вам менять каждый виджет на любую версию или тип виджета, который вы определяете в DI. Конструкция виджетов фиксируется в DI и отделена от верхней страницы. Возможно, даже состав Коллекции может быть определен в вашем DI. Верхняя страница выполняет макет на основе переданных ей виджетов, как и должно быть. Никаких изменений в конструкторе верхней страницы не требуется. Верхняя страница нуждается только в логике для выполнения компоновки виджетов и передачи информации в / из виджета на основе определенных интерфейсов.

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