OO＆amp;应用对象

Question

在OO应用程序中，通常会有一个Application类来保存您的顶级经理或其他任何东西。这使得很难避免使用theApp全局对象，或使用Singleton或其他东西。

重要吗？我们是否应该尽可能地将其作为OO，或者接受OO原则有时会破坏？

Answer 1

  

重要吗？我们是否应该尽可能地将其作为OO，或者接受OO原则有时会破坏？

有时OO理论符合现实世界，您应该努力使事情首先为您的客户服务。单身者在这里或那里对您的客户或可维护性没有问题。

OOP主要是为了使代码更易于维护，重用和理解。只要达到这些目标，就没有必要仅仅因纯度原因而重构。

Answer 2

拥有全局theApp对象单例不会必然违反OO原则，只要绑定到它的数据被正确封装等等。

还有一种情况是，很少有OS实际上有OO核心，这意味着Application Loader不是以面向对象的方式开始的。

无论如何，在这一点上绝对主义是危险的;一些编程语言对整个事物采用（IMO）过度热心的方法，规定每个函数都是一种方法或者类似的东西，即使这样做也没有任何意义。 （System.Math.sin(x)，有人吗？）

最有效的方法通常是混合两种方法，使用函数函数和方法方法;并且通过扩展，将单身人士用于真正独特的事物;例如应用程序对象或某些系统服务的接口。

编辑：在System.Math.sin(x)上，应该明确指出sin（x）在字面上的每个意义上都是一个函数，并将其作为一个方法放在单身人士身上是非常不负责任的，或者至少有点傻。在注释中可能存在一个案例，其中另一个类想要使用名称sin（）作为方法，但由于方法和函数在任何情况下都驻留在不同的命名空间中，这实际上是无关紧要的。

Answer 3

我认为目标应该是尽可能地设计。我不想有寻求“徽章”或批准印章的心态，所以我对“OO尽可能”感兴趣，而是寻求进行有意义的交易。我们支持去耦和单一责任等概念，不是因为它是OO，或者因为我们可以声称使用设计模式，而是因为我们增加了开发，可维护性，可测试性等的易用性。我们也赞成简单，因为它也增加了主要可用性和可测试性 - “你不需要它”原则导致我们有时会把事情紧紧地联系在一起，因为我们现在不需要灵活性。

所以，考虑你的例子，在某种意义上可能只有一个单例，只有一个东西（一个线程池或一些这样的东西），但使用它的代码是否需要知道它是一个单例？通过一些小心，使用工厂或注射，我们可以限制对n-gleton-ness的了解。

Answer 4

通过拥有“theApp”对象，没有OO细分。