Можете ли вы объяснить (себе), почему класс зависит от 10 других классов? Существуют ли переменные-члены, которые вы используете для связывания подмножества этих классов? Если это так, это означает, что этот класс должен быть разбит так, чтобы извлеченный класс зависел от подмножества, а переменные, связывающие такое состояние, попадали в извлеченный класс. С 10 зависимостями, возможно, этот класс просто стал слишком большим и ему все равно нужно разбить его внутренние компоненты.
Примечание относительно вашего последнего предложения: такая зависимость от порядка также может быть запахом кода, поэтому, вероятно, лучше не показывать его в вашем интерфейсе. Фактически, подумайте, являются ли требования к порядку тем, что операции должны выполняться в определенном порядке (это сложность алгоритма или протокола) или потому, что вы разработали свои классы так, чтобы они были взаимозависимыми. Если сложность связана с вашим дизайном, выполните рефакторинг для устранения упорядоченной зависимости, где это возможно.
Если вы не можете выполнить рефакторинг (все сложности очень важны, и у вас просто ужасная проблема с координацией в ваших руках), вы можете абстрагироваться от уродства и держать пользователей этого класса защищенными (строитель, фабрика, инжектор и т. Д.).
Редактировать: Теперь, когда я подумал об этом, я не уверен, что существенные сложности вашего алгоритма или протокола не могут быть абстрагированы (хотя это может иметь место). В зависимости от конкретной проблемы, сходства в манипуляциях с этими зависимыми классами могут быть лучше решены с помощью шаблона «Стратегия» или шаблона «Наблюдатель» (прослушиватели событий). Возможно, вам придется обернуть эти классы в классы, которые адаптируют их к интерфейсам, немного отличным от того, что они в настоящее время предоставляют. Вы должны оценить компромисс между тем, чтобы код в этом классе монстров стал более читабельным (yay) за счет еще до 10 классов в вашем проекте (boo).
Я также хотел бы сделать дополнение к абстракции конструкции этого класса. Представляется важным, чтобы любой класс, который зависит от этого класса, также использовал шаблон внедрения зависимостей. Таким образом, если вы используете конструктор, фабрику, инжектор и т. Д., Вы случайно не лишаете себя некоторых преимуществ использования шаблона DI (наиболее важным, на мой взгляд, является возможность замены фиктивных объектов для тестирования). .
Редактировать 2 (на основании вашего редактирования):
Моя первая мысль: "Что, нет зависимости от журналирования?" :)
Даже зная, каковы зависимости, сложно дать полезный совет.
Во-первых: каковы обязанности каждого? Почему этот класс зависит от кода контроллера (бизнес-логики) и от кода модели (два разных класса доступа к базе данных с классами DAO)?
В зависимости как от DAO, так и от классов доступа к БД, запах кода. Какова цель DAO? Какова цель классов БД? Вы пытаетесь работать на нескольких уровнях абстракции?
Один из принципов ОО состоит в том, что данные и поведение объединяются в мелочи, называемые классами. Вы нарушили это, когда создали этот класс бизнес-логики, отличный от объектов, которыми он манипулирует, отличных от DAO, отличного от этого класса? Связанный: Сделайте краткий переход на SOLID .
Второй: класс для загрузки конфигураций. Плохо пахнет. Внедрение зависимостей помогает вам определить зависимости и поменять их местами. Ваш класс монстров, который зависит от определенных параметров. Эти параметры сгруппированы в этот класс конфигурации, потому что ...? Как называется этот класс конфигурации? Это DBparameters? если это так, он принадлежит объекту (ам) БД, а не этому классу. Является ли это универсальным, как конфигурации? Если это так, то у вас есть мини-инжектор зависимостей (да, возможно, он вводит только строковые или целочисленные значения вместо составных данных, таких как классы, но почему?). Неудобно.
В-третьих: Самый важный урок, который я извлек из рефакторинга, заключался в том, что мой код высосан. Мало того, что мой код был отстой, но не было ни одного преобразования, чтобы остановить его. Лучшее, на что я мог надеяться, это заставить его сосать меньше. Как только я это сделаю, я смогу снова меньше сосать. И опять. Некоторые шаблоны проектирования плохие, но они существуют для того, чтобы позволить вашему отстойному коду перейти на менее отстойный. Таким образом, вы берете свои глобалы и делаете их одиночными. Тогда вы устраняете свои одиночки. Не расстраивайтесь, потому что вы просто изменили рефакторинг и обнаружили, что ваш код по-прежнему отстой. Это отстой меньше. Таким образом, ваш объект загрузки конфигурации может пахнуть, но вы можете решить, что это не самая неприятная часть вашего кода. На самом деле, вы можете обнаружить, что усилия по «исправлению» этого не стоят.