[编辑:]早些时候我问过这个问题可能是一个关于何时使用OOP与何时使用程序编程的错误框架问题 - 一些回复暗示我要求帮助理解OOP.相反,我经常使用OOP但想知道何时使用程序方法.从回答来看,我认为有一个相当强烈的共识,即OOP通常是一种更好的全方位方法,但如果OOP架构不能长期提供任何重用利益,则应该使用过程语言.
但是我作为Java程序员的经历却不然.我看到了一个庞大的Java程序,我用Perl大师重写了我编写的代码的1/10,看起来和我的OOP完美模型一样强大.我的架构看到了大量的重用,但更简洁的程序方法产生了一个卓越的解决方案.
所以,冒着重复自己的风险,我想知道在什么情况下我应该选择一个过程而不是面向对象的方法.您如何预先确定OOP架构可能过度杀伤并且程序方法更简洁高效的情况.
任何人都可以建议这些场景的样子吗？
什么是提前确定程序编程方法更好服务的项目的好方法？
在重复使用时,我喜欢Glass的3规则(这似乎是你感兴趣的).
1)构建可重用组件的难度是单次使用组件的3倍
2)可重用组件应在三种不同的应用程序中尝试,然后才能足够通用以接受重用库
从这个我认为你可以推断这些推论
a)如果你没有预算3倍于构建单个使用组件的时间,那么你应该推迟重用.(假设难度=时间)
b)如果您没有3个地方使用您正在构建的组件,也许您应该推迟构建可重用组件.
我仍然认为OOP对于构建单一用途组件很有用,因为你总是可以将它重构为以后真正可重用的东西.(你也可以从PP重构到OOP,但我认为OOP在组织和封装方面有足够的好处从那里开始)
可重用性(或缺乏可用性)不受任何特定编程范例的约束.根据需要使用面向对象,程序,功能或任何其他编程.组织和可重用性来自您的工作,而不是工具.
你自己给出了答案 - 大项目只需要OOP来防止过于混乱.
从我的角度来看,OOP的最大优势是代码组织.这包括DRY和封装的原则.
我建议使用最简洁,基于标准的方法,您可以找到任何给定的问题.使用Perl的同事证明,无论采用何种方法,熟悉特定工具的优秀开发人员都可以取得很好的成果.与其将Java-versus-Perl项目作为程序与OOP争论的一个很好的例子进行比较,我希望看到Perl和类似简洁的语言(如Ruby)之间的对峙,这恰好也有好处面向对象.现在,这是我想看到的东西.我的猜测是Ruby会出现在顶部,但我对这里引发语言火焰战并不感兴趣 - 我的观点只是你选择了适合这项工作的工具 - 无论何种方法都能以最有效和最强大的方式完成任务.方式可能.
那些虔诚支持OOP的人没有任何事实证明他们的支持,正如我们在这些评论中所看到的那样.他们在大学接受培训(或洗脑),只使用和赞美OOP和OOP,这就是他们如此盲目地支持它的原因.他们在PP中做过任何真正的工作吗？除了在团队环境中保护代码免受粗心程序员的影响,OOP并没有提供太多帮助.在PP和OOP中亲自工作多年,我发现PP简单,直接且效率更高,我同意以下明智的男女:
(参考:http://en.wikipedia.org/wiki/Object-oriented_programming):
一些着名的研究人员和程序员批评了OOP.这是一个不完整的清单:
Luca Cardelli写了一篇题为" 面向对象语言的糟糕工程特性 "的论文.
Richard Stallman在1995年写道,"向Emacs添加OOP并不是一个明显的改进; 我在使用Lisp Machine窗口系统时使用了OOP,我不同意通常认为它是一种优秀的编程方式."
Potok等人的一项研究.OOP和程序方法之间的生产率没有显着差异.
Christopher J. Date指出,由于缺乏对OOP的一致同意和严格的定义,OOP与其他技术的关键比较(特别是关系)很难.提出了OOP的理论基础,它使用OOP作为一种可定制的类型系统来支持RDBMS.
亚历山大·斯捷潘诺夫(Alexander Stepanov)认为,OOP提供了一种数学上有限的观点,并将其称为"几乎与人工智能一样的恶作剧"(可能指的是20世纪80年代的人工智能项目和市场营销,有时在回顾中被视为过于热心).
保罗·格雷厄姆曾提出,OOP的目的是充当"羊群机制",使普通组织中的平庸程序员不会"造成太大的伤害".这是以减慢知道如何使用更强大和更紧凑技术的高效程序员为代价的.
Erlang的主要发明者乔·阿姆斯特朗(Joe Armstrong)被引用说:"面向对象语言的问题在于他们已经拥有了所有这些隐含的环境.你想要一个香蕉,但你得到的是拿着香蕉和整个丛林的大猩猩."
理查德曼斯菲尔德,作者和COMPUTE的前编辑!"杂志"指出,"像多年来无数其他知识分子一样("相关性",共产主义,"现代主义"等等 - 历史上都充满了它们),OOP将与我们同在,直到最终现实宣称自己为止.但考虑到OOP目前遍及大学和工作场所,OOP可能被证明是一种持久的妄想.整整一代经过深思熟虑的程序员继续走出学院,一直致力于OOP,而且他们的余生只有OOP."并且还引用了一句话说"OOP是编写一个程序,机场安检的目的是飞行".
我认为DRY原则(不要重复自己)加上一点敏捷是一个很好的方法.从最简单的工作开始逐步构建程序,然后逐个添加功能,并在必要时重新考虑代码.
如果您发现自己一次又一次地编写相同的几行代码 - 可能使用不同的数据 - 是时候考虑抽象,这可以帮助将那些变化的东西与保持不变的东西分开.
为每次迭代创建彻底的单元测试,以便您可以放心地重新考虑因素.
花太多时间试图预测代码的哪些部分需要可重用是错误的.一旦系统开始增长,它很快就会变得明显.
对于具有多个并发开发团队的大型项目,您需要有一些架构计划来指导开发,但如果您自己或在小型合作团队中工作,那么如果您坚持DRY原则,架构将自然而然地出现.
这种方法的另一个优点是,无论你做什么都是基于现实世界的经验.我最喜欢的比喻 - 在你能想象建筑物是如何建造之前,你必须先玩砖块.
京公网安备 11010802040832号 | 京ICP备19059560号-6 