我正在和一位同事有关设计的分歧中，并希望听取人们对对象构造器设计的意见。简而言之，你更喜欢哪种对象构造方法，为什么？

    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等等...)。我目前认为这样更容易测试，隔离变化，并且不会混淆必需传递的参数。

目前，另一位程序员看不出区别，我很难找到例子或好的理由来改变设计，而仅仅依靠我的直觉，并违背我所知道的面向对象的原则，这不是一个有说服力的论点。我的设计想法错了吗？有没有人有什么支持一方或另一方的观点？