Создание объектов с помощью класса конфигурации или с параметрами

Question

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

    public class myClass
    {
        Application m_App;

        public myClass(ApplicationObject app) 
        { 
             m_App = app;
        }  
        public method DoSomething 
       { 
         m_App.Method1();
         m_App.Object.Method();
       }
    }

Или

    public class myClass
    {
        Object m_someObject;
        Object2 m_someOtherObject;

        public myClass(Object instance, Object2 instance2) 
        { 
             m_someObject = instance; 
             m_someOtherObject = instance2;
        }  
        public method DoSomething 
       { 
         m_someObject.Method();
         m_someOtherObject.Method();
       }
    }

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

public Object(Application)

Многие классы содержат ссылку на этот класс приложения по отдельности. Внутри каждого класса на значения приложения ссылаются по мере необходимости. Э.Г.

Application.ConfigurationStrings.String1 or Application.ConfigSettings.EventLog.Destination

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

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

Я хотел изменить конструктор объектов так, чтобы он принимал только те аргументы, которые ему нужны, чтобы public object(Application) изменился на public object(classmember1, classmember2 etc...). Сейчас я чувствую, что это делает его более тестируемым, изолирует изменения и не скрывает необходимые параметры для передачи.

В настоящее время другой программист не видит разницы, и у меня возникают проблемы с поиском примеров или веских причин для изменения дизайна, и я говорю, что это мой инстинкт и просто идет вразрез с принципами ОО, которые, я знаю, не являются убедительным аргументом. Я не в своем уме? У кого-нибудь есть какие-либо пункты, чтобы добавить в пользу одного или другого?

Answer 1

Черт, почему бы просто не создать один гигантский класс с именем "Do" и один метод с именем "It" и передать всю вселенную в метод It?

Do.It(universe)

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

Answer 2

Я считаю, что вы даете классу наименьший набор «вещей», необходимых ему для выполнения своей работы. Метод «Application» проще на начальном этапе, но, как вы уже видели, он приведет к проблемам с поддержкой.

Answer 3

Мне кажется, Стив МакКоннел очень кратко выразил это. Он заявляет,

"Разница между философия «удобства» и «интеллектуальная управляемость» философия сводится к разнице в центре внимания между написанием программ и читать их. Максимизация объема может действительно сделать программы легко напиши, но прогу в какую нибудь рутина может использовать любую переменную в любом время труднее понять, чем программа, которая использует хорошо продуманный Подпрограммы. В такой программе вы не можете понимать только одну рутину; у тебя есть чтобы понять все другие процедуры с которой эта рутина разделяет глобальный данные. Такие программы трудно читать, трудно отладить и сложно изменить. "[McConnell 2004]

Answer 4

Я бы не пошел так далеко, чтобы называть объект Application классом "бога"; это действительно похоже на служебный класс. Есть ли причина, по которой это не публичный статический класс (или, что еще лучше, набор классов), который другие классы могут использовать по желанию?