1

我遇到了与同事的设计分歧，并希望人们对对象构造函数设计提出意见。简而言之，您更喜欢哪种对象构造方法，为什么？ 

    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 类的引用。在每个类中，根据需要引用应用程序的值。例如

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

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

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

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

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

4

4 回答 4

2

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

于 2008-12-29T23:02:03.113 回答
2

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

Do.It(universe)

保持尽可能小。当事情不可避免地发生故障时，离散意味着更容易调试。

于 2008-12-29T23:05:46.803 回答
1

我认为史蒂夫·麦康奈尔说得非常简洁。他说，

“‘便利性’哲学和‘智力可管理性’哲学之间的区别归结为编写程序和阅读程序的重点不同。最大化范围确实可以使程序易于编写，但是任何例程都可以使用任何程序的程序任何时候的变量都比使用结构良好的例程的程序更难理解。在这样的程序中，您不能只理解一个例程；您必须了解与该例程共享全局数据的所有其他例程。这样的程序是难以阅读、难以调试和难以修改。” [麦康奈尔 2004]

于 2009-01-15T10:38:44.180 回答
0

我不会把 Application 对象称为“上帝”类；它真的看起来像一个实用程序类。它不是其他类可以随意使用的公共静态类（或者更好的是一组类）是否有原因？

于 2008-12-29T23:03:40.910 回答