刚刚在“你使用什么JS lib”民意调查中看到了这个评论
“@ Xanti - 是的,是的,编程中的模块化和抽象是一种可怕的做法。调用其他函数的函数?浪费。”
这让我很好奇,因为我正在使用Kohana框架为PHP和Jquery库提供javascript。
为什么有些人会考虑抽象和模块化的不良做法?是不是为简化和加快开发而制定了框架和库?
这是民意调查的link
答案 0 :(得分:11)
我发现过多的抽象可能会对您的工作效率造成危害:
选择不当的抽象可能会更糟,然后根本就没有抽象。
如果您需要阅读四个或五个不同的模块以了解简单算法的工作原理,那么抽象障碍可能不在正确的位置。也许有一种很好的方法来重构代码,或者只是为了消除障碍会更容易。
如果抽象不符合相对熟悉的想法,新团队成员可能难以学习。
抽象不是“无意识的好”;它的存在是为了特定目的。其中最常见的目的是
保护数据结构的不变量
封装可能会改变的设计决策
我在抽象方面遇到的最大经验是我们的C--研究编译器。与学生习惯在编译器类中看到的相比,有更多的抽象:
这些抽象中的每一个都为我们的研究提供了重要的目的,但总体效果是新生学习编译器很难非常。因此,即使原始评论是开玩笑的,也是抽象可能导致问题的地方。
答案 1 :(得分:3)
在处理有限的资源时,很容易增加开销。
当然,编译器会优化一些东西,但是如果你用四个整齐的.c文件创建四个整齐的对象,将它们编译成四个整齐的.so文件,然后将它们与一个哑的链接器链接起来,交叉模块函数调用可以很容易内联仍然使用完全状态转储,可以完全优化的部分仍然执行,等等。
我向您保证,如果您使用面向对象语言的最佳实践开始编程具有4K RAM和16K闪存的8位PIC单片机,使用高级设计模式并创建多个抽象层,您的程序将永远无法运行。 “过早的优化是所有邪恶的根源”是一个从未为具有128字节RAM的平台编程的人所说的。
答案 2 :(得分:1)
我们可以假设评论者并不认真。
我无法想象任何声称模块化和抽象的人都是不好的做法并且实际上意味着它。
答案 3 :(得分:1)
抽象和模块化通常是好的和必要的。那里可能存在糟糕的抽象,例如:不再支持或昂贵或者不可用的框架,或者大的,或过时的,或者第二选择等等。图书馆“市场”总的来说是巨大的。您发现自己使用哪种图书馆取决于环境和个人偏好。
为什么有些人会考虑抽象和模块化的不良做法?不是框架和 图书馆是为了减轻和加快发展而制定的?
变革和学习有时很难 - 所以人们会反对。如果你想学习这种类型,你可以开始研究:http://thedailywtf.com/ :-)我会忽略它们并使用库和框架,因为它们为你服务并让你的程序员生活更美好。
答案 4 :(得分:1)
当开发人员能够或要求与所述抽象或模块化进行交互并且无法理解其目的或设计时,开发人员会声称抽象或模块化是一种不好的做法。
答案 5 :(得分:0)
当每个函数(和辅助函数)都在自己的模块中时?
答案 6 :(得分:0)
前段时间它很安静,但是fortran编译器的手册建议选择标识符作为相同长度的字符串和随机选择的字母。
解释?它允许在内部编译器哈希表中均匀分布名称,因为这样可以加快编译速度。
我认为您引用的文字属于此建议的旁边
答案 7 :(得分:0)
在软件中的2个或更多位置引用了良好的抽象。
示例:
在2个或更多位置引用的抽象有助于减少代码大小,通过分解常见的东西,这是一件好事。
但是如果你有很多抽象只被引用一次,那么那里 抽象是不必要的很好的机会。
出现不必要的抽象的一些例子:
一些非常好的抽象的例子:
所以要务实地回答你的问题:从少于2个地方引用时抽象是不好的。
关于模块化,它的主观性:你可以随意组织你的代码。如果你的图书馆的源代码在一个源文件中,它就不会比你把数百个文件分解它更糟糕。
在评估您的抽象是好还是坏时,请始终考虑大局:整个项目,整个产品线等。