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类构造对象，Application类包含应用程序的所有当前设置（事件日志目标，数据库字符串等）。因此，每个对象的构造函数如下所示：

public Object(Application)

许多类单独保存对此Application类的引用。在每个类中，根据需要引用应用程序的值。 E.g。

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

最初我认为你可以使用这两种方法。问题是在调用堆栈的底部你调用参数化的构造函数，然后在堆栈的上方，当新对象期望对应用程序对象的引用时，我们遇到了很多空引用错误并看到了设计缺陷。

我使用应用程序对象设置每个类的感觉是它打破了每个对象的封装，并允许Application类成为保存所有内容信息的神类。在考虑这种方法的缺点时，我遇到了问题。

我想更改对象构造函数以仅接受它需要的参数，以便public object(Application)更改为public object(classmember1, classmember2 etc...)。我觉得目前这使得它更容易测试，隔离变化，并且不会混淆必要的参数来传递。

目前，另一位程序员没有看到差异，我无法找到改变设计的例子或充分的理由，并说这是我的直觉，只是违背OO原则，我知道这不是一个引人注目的论点。我是不是偏离了我的设计思想？有没有人有任何意见可以添加一个或另一个？

Answer 1

我的观点是，你给这个班级做它工作所需的最小“东西”。 “应用程序”方法更容易提前，但正如您已经看到的那样，它将导致维护问题。

Answer 2

天啊，为什么不只要制作一个名为“Do”的巨型类，并将其中的一个方法称为“It”并将整个宇宙传递给It方法？

Do.It(universe)

保持尽可能小的东西。当事情不可避免地破裂时，离散意味着更容易调试。

Answer 3

我认为史蒂夫麦康纳非常娴熟。他说，

“之间的区别 '便利'的理念和 '智能可管理性' 哲学归结为差异强调写作程序并阅读它们。最大化范围可能确实使程序容易写，但任何一个程序例程可以使用任何变量时间比a更难理解使用良好因素的程序例程。在这样的程序中你不能只了解一个例程;你有了解所有其他例程该例程与全球共享数据。这些节目难以阅读，难以调试，难以修改。“[McConnell 2004]

Answer 4

我不会把Application对象称为“上帝”类;它看起来像是一个实用类。有没有理由它不是公共静态类（或者更好的是，一组类），其他类可以随意使用？

使用Configuration类或使用Parameters实例化对象

4 个答案: