2010-05-19 171 views
3

我试图让C#中的大型项目开启轮子。我以前的经验是在Delphi中,在默认情况下,每个表单都是在应用程序启动时创建的,并在(gasp)全局变量中形成引用。所以我试图让我的思维适应一个100%面向对象的环境,而我的脑袋正在旋转一点点。需要关于OOP哲学的建议

我的应用程序将有一个大集合的类大多数这些类只会真的需要一个实例。所以我在想:静态类。我不是很确定为什么,但是我在这里读到的大部分内容都说如果我的类将持有一个状态,我认为这个状态意味着任何属性值,那么我应该使用单例结构。好的。但是有些人因为逃避我的原因认为单身人士也是邪恶的。

这些类别都没有在本程序中的任何地方使用的危险。所以他们当然可以像普通对象一样正常工作(vs单件或静态类)

然后存在对象之间交互的问题。我很想创建一个全局类,其中包含许多引用这些类的单个实例的公共静态属性。我也考虑过让他们的属性(静态或实例,不知道哪个)MainForm。然后,我会让每个类都知道MainForm作为所有者。然后各种对象可以互相引用为所有者。 对象1,所有者。 对象2

我担心电子墨水用完了,或者至少会让任何人忍耐到足以让我忍受这么久的耐心。我希望我已经清楚地解释了我完全混淆的状态。我只是寻找一些关于我的情况的最佳实践的建议。所有的投入都欢迎和赞赏。

由于提前, 大卫·詹宁斯

+0

您可以删除德尔福形式的全局变量和实例,并根据需要释放他们。 – TrueWill 2010-05-19 02:49:18

+1

感谢所有花时间回复的人。你给了我很多想法。多么伟大的社区。当我说大部分课程只需要一个实例时,我必须承认我夸大了我。事实上,它是大约12中的3个。再次感谢我鼓励我退后一步,密切关注我的一些班级决策。这个网站将成为我最重要的C#智慧源之一,而我正在加快步伐。 – 2010-05-19 12:21:22

回答

2

你可以试试看看它是如何发展的。考虑在你身边用NUnit进行开发;如果你这样做,你会发现你的代码将保持足够的灵活性,使架构变化不会太难。

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

无论如何 - 除了谈论和思考可能会发生什么之外,我会建议继续前进,尝试一些选择并看看他们做了什么。写完后不要害怕更改软件!

+0

谢谢你。这是我开始的态度。无论我如何处理这些特定问题,我都有信心我可以让应用程序正常工作。我只想在这个过程中学习一些东西,并且让应用程序远离繁杂的垃圾。 :) – 2010-05-19 02:47:24

4

这是非常正常的程序或其他非OOP语言去思考“每个XYZ一个巨大的静态类”,这通常意味着你没有真正想过由于一个类应该代表要被操纵的对象而正在表示的对象。

所以,你需要退后一步,看看DATA和DATA代表什么。你可能会说:“嗯,它是数据!它代表着数字!”,但你必须抽象出数据代表什么。数据表示的“事物”是对象。您对数据“事物”所执行的操作将成为您的方法。

+0

这个项目实际上是我在Delphi 8年前开发的系统的改写。从那时起,我一直在维护和改进应用程序,并且我刚刚决定离开Delphi。 Delphi是一种面向对象的语言(主要是)。它只是混合了全球存储器(大多数面向对象的程序员,毫无疑问,它确实值得称道)。所以就数据/行为到类的翻译而言,我认为我设置得很好。我在哪里陷入困境,正在找出离开全球空间的最佳途径。 – 2010-05-19 02:42:51

1

单身人士通常是我们通常在设计中看到的许多问题的来源。不过,我认为创建单例和全局变量是一种将它们作为代码异味传递给应用程序的手段。

我觉得这会很好地得到SOLID的原理。还有几个关于这个话题的角度,你应该看和理解。

我推荐的另一本实用书是Kent Beck的实施模式。了解面向对象是一回事,在现实世界中实现是另一回事。

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

我想我用足够的信息轰炸了你,但放松一下,一步一个脚印。我觉得你应该在这里跟踪几条曲目,以达到你想要的位置。有一些prototypes微软提供,你可以学习,然后即兴与OOP。

0

这个可能会或可能不会有用只是一些随机的想法:

  • 先从数据不是程序结构。分析数据并找出你在概念上想要表现的东西,然后将其物化。

  • 我的经验是,在prodedural代码你在想“我现在在做什么?”但是使用面向对象的代码,你正在想“有一天我可能想要做什么?”

  • 总是会有至少一个主对象,即使它是应用程序对象本身。即使它很诱人,也不要在这个物体上放太多东西。代表数据越多,概念相关对象中的状态和行为越容易为新开发人员学习和维护。

  • 做一个原型。构建一个缩减版本的应用程序,您知道您将丢弃该应用程序,然后在您到达某个点时查看您的代码,确定哪些对象运行良好,哪些对象没有运行并重新启动。

至于整个辛格尔顿的事情 - 不想挑衅 - 忽略naysaysers。有时候Singleton设计模式非常有用,就像有时候EAV数据模型是完美的,MVC是世界上最糟糕的事情一样。如果您需要放入螺丝,请使用螺丝刀。

0

在阅读你的解释部分时,我认为如果你有很多你认为应该是静态或单身的类,你可能仍然在思考Delphi类型的范例。我不知道我是否遇到过只有大部分物体中的一个的项目。所以我的倾向是你的对象分解可能有缺陷。

真的,你应该开始考虑你在程序中代表什么。问问自己,如果你有很多只有一个实例的对象,为什么只有一个实例?是否因为你以一种奇怪的方式保存数据,就像有多个索引匹配的数组一样。

话虽这么说,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; 
     } 
    } 

} 

因此,我建议对使用单身扶着如果你坚持使用模式。单身人士,就像一切都有时间和地点,我不会编写一个大多数对象都是单身人士的应用程序。

我强烈鼓励你觉得为什么你有静态方法或单身全局状态。

2

静态类和单身共享相同的缺点:

  • 紧密耦合到许多其他类
  • 隐藏的依赖关系(很难说其他类使用它们)
  • 测试困难
  • 本质上全球数据
  • 对于单身人士,多重责任(无论他们做什么+生命周期管理)

在许多解决方案(不是全部!)的情况下是Dependency Injection(DI)的基础上,Dependency Inversion Principle(即@CodeToGlory提到SOLID原则之一)。这可以手动完成或使用DI Container framework

马克塞曼对Dependency Injection in .NET的优秀图书;我强烈建议。