Question

我正试图让车轮在C＃中开启一个大型项目。我以前的经验是在Delphi中，默认情况下，每个表单都是在应用程序启动时创建的，并且表示在（gasp）全局变量中保存的引用。因此，我正在努力使我的思维适应100％面向对象的环境，而我的头脑正在旋转一点。

我的应用程序将有大量的类集合这些类中的大多数只需要一个实例。所以我在想：静态类。我不太确定为什么，但我在这里读到的很多内容都说如果我的班级要持有一个状态，我认为这意味着任何属性值，我应该使用单例结构。好的。但是有些人出于逃避我的理由，认为单身人士也是邪恶的。

除了这个程序之外，这些类都没有被用在任何地方的危险。因此，它们当然可以作为常规对象（与单例或静态类）一起工作

然后是对象之间的交互问题。我很想创建一个充满公共静态属性的Global类，引用许多这些类的单个实例。我还考虑过制作MainForm的属性（静态或实例，不确定哪些）。然后我会让每个班级都知道MainForm作为所有者。然后各种对象可以互相引用为所有者。 Object1 ，所有者。 Object2 等

我担心我的电子墨水已经耗尽，或者至少对任何一个有这么长时间坚持不懈的人的耐心负担。我希望我已经清楚地解释了我完全混乱的状态。我只是在寻找一些关于我的最佳实践的建议。欢迎并赞赏所有意见。

提前致谢，大卫詹宁斯

Answer 1

从程序或其他非OOP语言开始并想“每个XYZ一个巨大的静态类”是很正常的，这通常意味着你没有真正考虑过被表示的OBJECTS，因为一个类应代表要操纵的物体。

因此，您需要退后一步，查看DATA以及DATA代表的内容。你可能会说，“嗯，这是数据！它代表了数字！”，但你必须抽象出数据所代表的含义。数据表示的“事物”是对象。您对“事物”所代表的数据执行的操作将成为您的方法。

Answer 2

你可以尝试一下，看看它是怎么回事。考虑使用NUnit进行开发;如果你这样做，你会发现你的代码将保持足够的灵活性，使得架构变更不会太难。

我的偏好是避免使用静态类和静态数据，但有时它只对短期问题有意义。在那，我的建议是考虑实际拥有各种形式的东西。通常情况下，人们似乎想要将主要形式作为“主要应用程序”，但实际上可能有更好的所有者。

无论如何 - 除了谈论和思考可能是什么之外，我建议你继续尝试一些选择，看看他们做了什么。写完后不要害怕更换软件！

Answer 3

静态类和单例有着相同的缺点：

与许多其他课程紧密相连
隐藏依赖关系（很难分辨其他类使用它们）
测试困难
基本上是全球数据
对于单身人士，多重责任（无论他们做什么+终身管理）

许多（并非所有！）案例中的解决方案是Dependency Injection（DI），基于Dependency Inversion Principle（@CodeToGlory提到的SOLID原则之一）。这可以手动完成，也可以使用DI Container framework完成。

Mark Seemann有一本关于Dependency Injection in .NET的优秀书籍;我强烈推荐。

Answer 4

单身人士通常是我们通常在设计中看到的许多问题的根源。但是我考虑创建单例和全局变量作为将它们作为代码气味传递给应用程序的手段。

我觉得让自己成为SOLID原则的入门书会很有用。关于这个主题，还有几个关于你应该观察和理解的视角。

我推荐的另一本实用书是肯特贝克的实施模式。理解OOP是一回事，在现实世界中实现是另一回事。

查看Windows Presentation Foundation，这是用于构建Windows客户端应用程序的下一代演示系统。

我认为我用足够的信息轰炸了你，但要放轻松，一步一步走。我觉得你应该在这里跟踪几首曲目，以达到你想要的地方。微软提供了一些prototypes，您可以通过OOP进行学习，然后进行即兴创作。

Answer 5

对此的一些随机想法可能有用也可能没用：

从数据开始而不是程序结构。分析数据并找出你在概念上试图表达的内容，然后将其客观化。
我的经验是，凭借原则代码，您在思考“我现在在做什么？”但是对于OO代码，你会想“有一天我想做什么？”
总会有至少一个主对象，即使这是Application对象本身。即使它很诱人，也不要在这个物体上放太多。您在概念上相关的对象中表示数据，状态和行为的次数越多，应用程序就越容易为新开发人员学习和维护。
做一个原型。构建您知道将丢弃的应用程序的缩小版本，然后当您到达某一点时检查您的代码，确定哪些对象运行良好，哪些对象没有，然后重新开始。

至于整个单身人士的事情 - 并且不想挑衅 - 忽视反对者。有时，Singleton设计模式非常有用，就像EAV数据模型很完美，MVC是世界上最糟糕的事情一样。如果需要拧入螺丝，请使用螺丝刀。

Answer 6

在阅读你的解释时，我认为如果你有许多你认为应该是静态或单身的课程，你可能仍在思考德尔福的范式。我不知道我是否遇到过只有大多数物体之一的项目。所以我的倾向是你的物体分解可能有缺陷。

真的，你应该开始考虑你在程序中代表什么。问问自己，如果你有很多只有一个实例的对象，为什么只有一个实例呢？是因为你以奇怪的方式持有数据，比如有多个索引匹配的数组。

据说C＃确实为单例提供了一些很好的内置语义，因为你不必在实例方法中进行空值检查

public class SingletonClass{
     private static SingletonClass _instance;

     private SingletonClass(){}

     public static Instance
     {
         get
         {
             if(_instance == null){
                _instance = new SingletonClass();
             }
         }
     }

}

在C＃中可以写成：

public class SingletonClass{
     private static SingletonClass _instance = new SingletonClass();

     private SingletonClass(){}

     public static Instance
     {
         get
         {
            return _instance;
         }
     }

}

因此，如果您坚持使用该模式，我建议您倾向于使用Singletons。单身人士，就像一切都有时间和地点一样，我不会写一个完整的应用程序，其中大多数对象是单身人士。

我强烈建议您考虑为什么您拥有静态方法或单身人士的全球状态。

需要有关OOP理念的建议

6 个答案: