有可能超过OO吗?

是否可以对代码进行超对象定向

是的

如果您认为更多的对象更面向对象,那么是的。

当进行面向对象的设计时,有两种力量需要平衡。大多数OO设计都是关于降低和处理复杂性。所以如果你得到非常复杂的解决方案,你不会做太多的OO,但你做的不对。

如果您发现在您的项目中完全实现OO所需的时间不必要地导致错过最后期限,那么是的。

必须在发布软件和完全OO保真度之间进行权衡。如何决定取决于运行项目的人员、团队、项目和组织。

是的,当然有:-)面向对象技术是一种工具…如果你在一个特定的工作中使用了错误的工具,你会把事情复杂化(当你只需要一把刀的时候,想想勺子)。

对我来说,我根据项目的规模和范围来判断“多少”。如果是一个小项目,有时会增加太多的复杂性。如果项目很大,那么您仍将承担这种复杂性,但是它将在易维护性、可扩展性等方面为自己付出代价。

我的建议是不要想得太多。这通常会导致做过多或不足的事情(如果不是OO)。我通常使用的经验法则是:如果它使问题更容易绕着我的头,我就使用一个物体。如果另一个范例比我使用一个物体更容易把我的头包起来,我就用它。

这一策略还没有使我失望。

是的,这是绝对可能的——也很常见。我曾经和一个人合作,他创建了一个数据结构来绑定到下拉列表,这样他就可以允许用户选择性别。是的,如果可能的性别列表要改变的话,那是很有用的,但是他们还没有改变(我们不住在加利福尼亚州)。

是的,就像可以过度规范化数据库设计一样。

这似乎是一场永远不会结束的纯粹主义与务实主义的辩论。lt;s

很多人试图设计他们的代码以获得最大的灵活性,而不考虑重用的可能性。相反,根据你正在编写的程序来分解你的课程。如果您只有一个特定对象的实例,那么可以考虑将其合并到包含对象中。

我认为你的问题应该是:“你能把你的应用程序的体系结构做得过火吗?”

当然答案是。OO只是一种设计方法。如果你花时间把不必要的复杂性构建到一个系统中去,因为“多态性是岩石!”是的,也许你喝多了。

XP的答案是 无论您喜欢什么方法(OO、过程等),设计都应该像明显必要的那样复杂。 .

是的,你可以。例如,如果您发现自己在为接口或抽象类创建两个子类型之前创建了接口或抽象类,那么您就已经完成了。我经常在开发人员预先设计时看到这种想法。我使用测试驱动的开发和重构技术来避免这种行为。

是否可以对代码进行超对象定向?

不,但代码可能过于复杂。例如,您可以使用设计模式来使用设计模式。但是您不能过度地确定代码的对象方向。您的代码要么是面向对象的,要么不是面向对象的。正如您的代码要么设计得很好,要么不是。

我想这是可能的,但很难用抽象的术语来回答(没有双关语)。举一个关于OO的例子。

对。参见“的概念 golden hammer antipattern “

我认为有时OO设计可以走到极端,即使是在非常大的项目中,也会使代码的可读性和可维护性降低。例如,在跑鞋的基础类、儿童类、运动鞋、正装鞋等中都可以使用。但我已经阅读/审查了人们的代码,他们似乎将在这些代码下为耐克运动鞋和锐步运动鞋创建课程。当然,这两者之间存在差异,但是为了拥有可读、可维护的代码,我相信有时扩展类以适应差异,而不是创建新的子类来处理差异是很重要的。

是的,很简单。代码并不是因为它是面向对象的而变得更好,而不仅仅是因为它是模块化的、功能性的、通用的、可生成的、基于数据流的、面向方面的或其他的。

好代码是好代码,因为它在编程范式中设计得很好。

好的设计需要小心。

小心需要时间。

你的例子是:我看到了一些可怕的Java名字。 在“面向对象”的概念中,每个类都实现了一些接口,即使没有其他类可以实现。 曾经 实现这个接口。有时这是一个黑客,但在其他人,它确实是免费的。

无论您编写的是什么样的范例或习语,如果编写的代码太过繁琐,或者参与了太多的好事,都会使代码比问题更复杂。有些人会说,当达到这一点时,代码甚至不再是面向对象的了。

为了更简单、更直接或更容易理解和消化合理独立的部分,应该对面向对象的代码进行更好的组织。使用与此目标相对应的面向对象编码机制 不 导致面向对象 设计 .

我认为明确的答案是肯定的,但根据你所指的领域,它可能真的是肯定的,或者更少,所以是肯定的。如果您正在构建高级.NET或Java应用程序,那么我认为这是后者,因为OO基本上是内置于语言中的。另一方面,如果你正在开发嵌入式应用程序,那么你的过度使用的危险性和可能性是很高的。没有什么比看到一个真正的高层次的人进入一个嵌入的项目,并且过度复杂的事情,他们认为是丑陋的,但最简单和快速的方式做事情更糟糕的了。

我认为任何事情都可能“过度”。几乎每一个我能想到的最佳实践都是如此。我看到继承链如此复杂,代码实际上无法管理。