c# - 使用配置类或参数实例化对象

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...)。目前我觉得这使它更易于测试、隔离更改并且不会混淆要传递的必要参数。

目前，另一位程序员看不出其中的区别，我很难找到示例或更改设计的充分理由，并且说这是我的直觉并且违背了我所知道的 OO 原则并不是一个令人信服的论据。我的设计思想是否偏离了基础？有没有人有任何观点可以支持其中之一？

Answer 1

见鬼，为什么不创建一个名为“Do”的巨大类和一个名为“It”的方法，然后将整个宇宙传递给 It 方法？

Do.It(universe)

让事情尽可能的小。离散意味着当事情不可避免地崩溃时更容易调试。