面向对象和应用程序对象[关闭]

有关系吗?我们是应该尽可能地实现OO,还是接受OO原则有时会崩溃?

有时候OO理论会遇到现实世界,你应该努力让事情首先为你的客户服务。这里或那里的单例对您的客户或可维护性都没有问题。

拥有一个全球性的 theApp 对象singleton没有 必要地

还有一种情况是,很少有操作系统真正具有OO核心,这意味着应用程序加载器一开始不是面向对象的。

在任何情况下,这一点上的绝对主义都是危险的;有些编程语言(IMO)对整件事有一种过于狂热的态度,要求每个函数都是一个方法或类似的东西,即使这毫无意义。( System.Math.sin(x)

最有效的方法通常是将这两种方法混合使用,用函数代替函数,用方法代替方法;扩展一下,用单例来处理真正奇异的事物,比如应用程序对象或接口 一些 系统服务。

编辑: 在 系统.Math.sin(十) ,应该明确的是,sin(x)是一个函数,从字面上来说,它是一个词的所有意义上的函数,把它作为一个单子的方法是非常不负责任的,或者至少有点愚蠢。在注释中,可能存在另一个类希望将名称sin()用于方法的情况,但由于方法和函数在任何情况下都驻留在不同的名称空间中,因此这实际上并不相关。

我认为目标应该是设计得尽可能好。我不想有一个寻求“徽章”或批准印章的心态,所以我不感兴趣的是尽可能“OO”,而是我寻求作出简洁的权衡。我们支持诸如去耦合和单一责任这样的概念,不是因为它是面向对象的,也不是因为我们可以声称使用了设计模式,而是因为我们增加了开发的易用性、可维护性、可测试性等等。我们也喜欢简单,因为这也增加了可维护性和可测试性,“你不会需要它”的原则有时会导致我们把事情紧密地联系在一起,因为我们现在不需要灵活性。

因此,考虑一下您的例子,很可能有一个单例,即是的,只有一个(线程池或类似的),但是使用它的代码需要知道它是单例吗?只要小心一点,使用工厂或注射剂,我们就可以限制对n-gleton-ness的了解。

拥有一个“theApp”对象不会导致OO崩溃。