问实心与避免过早抽象化

EN

以下是您可以应用于帮助您理解如何平衡系统设计的简单原则：

• 单一责任原则:固体中的S。在方法的数量或数据量方面，您可以有一个非常大的对象，并且仍然坚持这一原则。例如，Ruby String对象。这个对象有更多的方法，而不是摇动一根棍子，但它仍然只有一个责任:为应用程序保存一串文本。一旦你的目标开始承担新的责任，就开始认真考虑这个问题。维护问题是问自己：“如果以后遇到问题，我会在哪里找到这段代码？”
• 简单是很重要的:阿尔伯特·爱因斯坦说：“让一切尽可能简单，而不是简单。”你真的需要那个新方法吗？你能用现有的功能完成你需要的东西吗？如果你真的认为需要一个新的方法，你能改变一个现有的方法来满足你所有的需求吗？本质上，当你构建新的东西时，重构。

在本质上，你是在尽你所能，在维护软件的时候，不要把自己打在脚上。如果您的大型对象是合理的抽象，那么就没有什么理由将它们分开，因为有人提出了一个度量，说明类不应该超过X行/方法/属性/等等。如果有的话，这些都是指南，而不是硬而快速的规则。

我认为大多数情况下你已经回答了你自己的问题。当概念需要提升抽象级别时，关于如何重构您的代码的指导原则集是坚实的。

就像所有其他创造性的学科一样，没有绝对的东西--只有权衡。你做的越多，就越容易决定什么时候对你当前的问题域或需求足够了。

尽管如此--抽象是软件开发的核心--所以如果没有什么好的理由不去做，那么实践将使您在这方面做得更好，并且您会对权衡有一种直觉的感觉。所以，除非它变得有害，否则你应该支持它。

I want to avoid premature abstraction.In my experience drawing abstraction lines without concrete use cases... 

这部分是对的，一部分是错的。

错误

这并不是阻止人们应用面向对象原则/坚实的理由。它只会防止过早地应用它们。

这是..。

正确的

不要重构代码，直到它是可重构的；当它是需求完成。或者，当“用例”如您所说的全部存在时。

I find simple, tightly coupled procedural or God object code is sometimes easier to understand than very well-factored...

独自工作或在筒仓工作时

不做OO的问题并不是显而易见的。在编写程序的第一个版本之后：

代码是新的，在你的头脑中，代码是熟悉的，代码很容易在心理上划分，你写的代码

这些美好事物的3/4在短时间内很快就会消失。

最后，您认识到您有上帝对象(具有许多功能的对象)，因此您可以识别单个函数。封装。把它们放在文件夹里。偶尔使用接口。帮你自己做一个长期维护的忙。尤其是非重构的方法往往会无限膨胀，成为上帝的方法。

一队

不做OO的问题立刻就被注意到了。好的OO代码至少具有一定的自文档性和可读性。特别是当与良好的绿色代码相结合时。此外，由于缺乏结构，很难将任务分开和集成变得更加复杂。