use*_*272 13 language-agnostic oop design-principles
在考虑性能的情况下,是否建议零件设计软件的组件或体系结构？我的意思是,设计/架构应该在性能密集型环境中使用的准备程度如何？
在设计组件时,我们应该遵循良好的OO原则,并确保组件是"可扩展的".这样我们在这里稍微调整一下设计,并在我们遇到性能问题时稍微调整一下.虽然这样,我们经常会遇到性能问题,在这些问题上调整软件可能会有所帮助.
或者,如果我们想出一个设计,虽然很复杂,但会使性能问题变得轻而易举.我们仍然需要调整软件,但调整通常非常简单,因为设计是面向性能的.
注意:在上面列出的两种情况中,我都试图在遇到性能问题之前调整软件的性能.要重新说明问题,软件的设计是否应该以性能为导向？
请不要回答我说这一切都取决于预期软件运行的环境.原因是任何工业级软件的客户似乎总是想要越来越多.您可能不会将您的软件计划为在性能密集型环境中持续运行,但如果必须,该怎么办？我们应该在感觉到时重新设计软件吗？
一个星期以来我一直困扰着这个问题,我还没有答案.你对此有什么看法？
Jaa*_*koK 26
当我写这篇文章的时候,有两个人已经回答了关于过早优化的Knuth引文.我认为这有点误导.关于这个问题背后的想法,以及关于这个主题的许多建议,在我看来,程序是算法的集合,如果它不够有效,我们可以确定哪些算法太慢并用某些东西取代它更好.
这种事情忽略了程序的相互关联性.这些算法都隐藏在一些API背后.虽然"愿景"是API背后的算法是不透明的并且可以与另一个算法互换,但它忽略了API对其调用者的约束.我已经完成了相当多的网络编程,并且通过设计无法有效工作的API很容易编写效率低下的软件,那么当你必须对全部使用的API进行基本修改时,你会怎么做？(在网络编程中,要求调用者在内存中构建完整消息的API比允许流式传输数据的API更容易设计和实现.)
因此,不要因简单而精辟的报价而堕落.你不应该为这些小东西而烦恼(特别是不要担心70年代人们所做的事情;编译器现在更加聪明)但完全忽略性能问题的态度"我们可以随时介绍和改进事情如果需要"可以引导你走向死胡同,你必须做重大的重新实现.
哦,我也建议反对"设计可扩展性".做最简单的事情,如果你后来发现你所拥有的东西的泛化会使事情变得更容易或更简单,那就去做吧.根据我的经验,进行不必要的通用设计只会导致难以使用的组件通常不是非常可扩展的,因为初始设计实际上无法预见组件在一般情况下应该做什么类型的事情如何.
您应该始终以效率而非低效率为目标，但不能以牺牲可维护性为代价。所以，是的，您应该尝试以效率为目标进行设计，但要警惕过早的优化。唐纳德·高德纳 (Donald Knuth) 最喜欢的一句话是：
“我们应该忘记小效率，大约 97% 的情况下：过早的优化是万恶之源。”