据我所知,尽管花费了数百万或数十亿美元用于OOP教育,语言和工具,但OOP并未提高开发人员的工作效率或软件可靠性,也没有降低开发成本。 很少有人在任何严格意义上使用OOP(很少有人坚持或理解LSP等原则); 人们对问题域建模所采用的方法几乎没有统一性或一致性。 这个课程常常仅用于语法糖; 它将记录类型的函数放入它们自己的小命名空间中。

我为各种各样的应用程序编写了大量代码。 虽然有些地方真正可替代的子类型在应用程序中发挥了重要作用,但这些都非常特殊。 总的来说,虽然谈到“重复使用”的口号很多,但实际情况是,除非一段代码完全符合您的要求,否则几乎没有成本效益的“重复使用”。 设计类以正确的方式扩展是非常困难的,因此扩展的成本通常很高,以至于“重用”根本就不值得。

在许多方面,这并不让我感到惊讶。 现实世界不是“OO”,OO隐含的想法 - 我们可以通过某种类别分类来模拟事物 - 在我看来非常根本性的缺陷(我可以坐在桌子上,树桩上,汽车引擎盖上)某人的膝盖 - 但不是其中一个 - 一把椅子)。 即使我们转向更抽象的领域,OO建模通常也很困难,违反直觉,最终无益(考虑圆/椭圆或正方形/矩形的经典例子)。

那我在这里错过了什么? OOP的价值在哪里,为什么所有的时间和金钱都无法使软件变得更好?

===============>>#1 票数:119

现实世界不是“OO”,OO隐含的想法 - 我们可以用一些类别分类法来模拟事物 - 在我看来基本上是有缺陷的

虽然这是事实并且已被其他人观察到(采用STL的发明者Stepanov),其余的都是无稽之谈。 OOP可能存在缺陷,它肯定不是银弹,但它使大规模应用程序变得更加简单,因为它是减少依赖性的好方法。 当然,这只适用于“好”的OOP设计。 邋design的设计不会带来任何好处。 但好的,解耦设计可以使用OOP很好地建模,而不是很好地使用其他技术。

有更好的,更通用的模型( Haskell的类型模型浮现在脑海中),但这些模型通常也更复杂和/或难以有效实施。 OOP是极端之间的良好平衡。

===============>>#2 票数:45

OOP不是关于创建可重用的类,而是关于创建可用类。

===============>>#3 票数:42

这个课程常常仅用于语法糖; 它将记录类型的函数放入它们自己的小命名空间中。

是的,我发现这也太普遍了。 这不是面向对象的编程。 它是基于对象的编程和以数据为中心的编程。 在与OO Languages合作的10年中,我看到人们大多数都在进行基于对象的编程。 OBP很快就崩溃了,因为你基本上得到了两个词中最糟糕的一个:1)程序编程没有遵循经过验证的结构化编程方法和2)OOP而不遵守经过验证的OOP方法。

完成OOP是一件美好的事情。 这使得很容易解决的问题非常困难,而且对于那些没有经验的人(不要试图在那里听起来很夸张),它几乎看起来像魔术。 话虽这么说,OOP只是编程方法工具箱中的一个工具。 它不是所有方法的全部。 它恰好适合大型商业应用程序。

大多数使用OOP语言的开发人员都在使用他们日常使用的框架和类型中完成的OOP示例,但他们并没有意识到这一点。 以下是一些非常简单的示例:ADO.NET,Hibernate / NHibernate,Logging Frameworks,各种语言集合类型,ASP.NET堆栈,JSP堆栈等......这些都是在其代码库中严重依赖OOP的所有东西。

===============>>#4 票数:32

重用不应该是OOP的目标 - 或者任何其他范例。

重用是良好设计和适当抽象级别的副作用。 代码通过做一些有用的事情来实现重用,但却没有做到使其变得不灵活。 代码是否为OO并不重要 - 我们重用可行的方法,而不是自己做的微不足道。 这是实用主义。

OO作为一种通过继承来重用的新方法的思想从根本上是有缺陷的。 正如您所注意到的那样,LSP违规很多。 相反,OO被恰当地认为是管理问题域复杂性的一种方法。 目标是随着时间的推移系统的可维护性。 实现这一目标的主要工具是将公共接口与私有实现分离。 这允许我们使用编译器强制执行的规则,例如“只应使用...修改”,而不是代码审查。

使用它,我相信你会同意,允许我们创建和维护非常复杂的系统。 这有很多价值,在其他范例中并不容易。

===============>>#5 票数:28

关于宗教信仰,但我会说你正在描绘现代OOP状态的过于严峻的画面。 我认为,它实际上已经降低了成本,制作大型软件项目管理,等等。 这并不意味着它解决了软件混乱的根本问题,并不意味着普通开发人员是OOP专家。 但是将功能模块化为对象组件肯定减少了世界上意大利面条代码的数量。

我可以想到几十个图书馆,它们可以重复使用,节省了永远无法计算的时间和金钱。

但是,就OOP浪费时间而言,我认为这是因为缺乏程序员培训,而且学习语言特定OOP映射的学习曲线陡峭。 有些人“得到”OOP而其他人永远不会。

===============>>#6 票数:24 已采纳

没有经验证据表明,面向对象是人们思考世界的一种更自然的方式。 在编程心理学领域有一些工作表明OO在某种程度上不比其他方法更合适。

面向对象的表示似乎没有普遍的可用性或更少的可用性。

仅仅采用OO方法并要求开发人员使用这些方法是不够的,因为这可能会对开发人员的工作效率以及开发的系统质量产生负面影响。

这是来自2000年10月ACM通讯的“关于OO表示的可用性”。这些文章主要将OO与面向过程的方法进行比较。 有很多关于如何使用OO方法“思考”的人的研究(Int.J. of Human-Computer Studies 2001,issue 54,或Human-Computer Interaction 1995,vol.10,OO研究的整个主题),从我读到的内容来看,没有任何迹象表明OO方法具有某种自然性,这使得它比传统的程序方法更适合。

===============>>#7 票数:21

我认为使用不透明的上下文对象(在Win32中的HANDLEs,在C中的FILE *,用来命名两个着名的例子 - 地狱,HANDLEs生活在内核模式障碍的另一边,它真的没有得到在程序代码中也可以找到比封装更多的封装; 我很难看到这对OOP来说是多么特别。

HANDLE (以及WinAPI的其余部分) OOP! C不能很好地支持OOP,因此没有特殊的语法,但这并不意味着它不使用相同的概念。 从各个方面来说,WinAPI都是面向对象的框架。

看,这是涉及OOP或替代技术的每一次讨论的问题:没有人清楚定义,每个人都在谈论其他事情,因此无法达成共识。 对我来说似乎浪费时间。

===============>>#8 票数:14

它是一种编程范例。旨在让我们的凡人更容易将问题分解成更小,更可行的部分..

如果你没有发现它有用..不要使用它,不要支付培训费用并且要开心。

另一方面,我发现它很有用,所以我会:)

===============>>#9 票数:14

相对于直接的程序编程,OOP的第一个基本原则是信息隐藏和封装的概念。 这个想法导致的概念将接口与实现分开。 这些是非常重要的概念,也是建立框架的基础,以不同的方式和更好的(我认为)方式思考程序设计。 你不能真正反对这些属性 - 没有做出权衡,它总是一种更简洁的方式来模块化。

OOP的其他方面包括继承和多态也很重要,但正如其他人所提到的那样,这些方面通常被过度使用。 即:有时人们使用继承和/或多态,因为他们可以,而不是因为他们应该。 它们是强大的概念,非常有用,但需要明智地使用,而不是OOP的自动获胜优势。

相对于重复使用。 我同意重复使用已超过OOP。 这是明确定义的对象的可能的副作用,通常是更原始的/通用的类,并且是封装和信息隐藏概念的直接结果。 它可能更容易被重用,因为定义良好的类的接口只是更简单,有点自我记录。

===============>>#10 票数:12

OOP的问题在于它是超卖的。

正如Alan Kay最初设想的那样,它是原始数据和全球惯例的先前实践的一个很好的替代品。

然后一些管理顾问类型锁定它并将其作为软件的救世主出售,并且类似于旅鼠,学术界和工业界随之而来。

现在,在其他好的想法被超卖之后,他们正在像在功能性编程中那样翻滚。

那么我会做些什么呢? 很多,我写了一本关于此的书。 (它已经绝版 - 我没有得到一分钱,但你仍然可以获得副本。) 亚马逊

我的建设性答案是将编程看作是在现实世界中对事物进行建模的一种方式,而是作为编码需求的一种方式。

这是非常不同的,并且基于信息理论(在任何人都能理解的水平上)。 它说编程可以看作是定义语言的过程,这样做的技巧对于良好的编程至关重要。

它提升了领域特定语言(DSL)的概念。 它强烈赞同DRY(不要重复自己)。 它给代码生成带来了很大的好感。 它导致软件的数据结构比现代应用程序的数据结构大得多。

它旨在重新激发前进的道路在于创造性的想法,并且应该质疑即使是被广泛接受的想法。

===============>>#11 票数:11

HANDLEs(以及WinAPI的其余部分)是OOP!

不过他们呢? 它们不是可继承的,它们当然不是可替代的,它们缺乏定义明确的类......我认为它们远远没有“OOP”。

你有没有用WinAPI创建一个窗口? 然后你应该知道你定义了一个类( RegisterClass ),创建它的一个实例( CreateWindow ),调用虚方法( WndProc )和基类方法( DefWindowProc )等等。 WinAPI甚至采用SmallTalk OOP的命名法,调用方法“消息”(Window Messages)。

句柄可能不是可继承的,但是,Java中有final 他们不缺课,他们班级的占位符:这就是“句柄”这个词的含义。 看看像MFC或.NET WinForms这样的架构,很明显,除了语法之外,与WinAPI没什么不同。

===============>>#12 票数:11

是的,OOP并没有解决我们所有的问题,对此感到抱歉。 然而,我们正致力于解决所有这些问题的SOA。

===============>>#13 票数:10

OOP非常适合编程内部计算机结构,如GUI“小部件”,其中例如SelectList和TextBox可以是Item的子类型,其具有诸如“move”和“resize”的常用方法。

麻烦的是,我们90%的人在业务领域工作,我们正在处理发票,员工,工作,订单等业务概念。 这些适合OOP,因为“对象”更加模糊,可能会根据业务重新设计等因素而变化。

最糟糕的情况是OO热情地应用于数据库,包括对SQL数据库的恶劣OO“增强” - 除非数据库新手认为他们必须是正确的做事方式,因为它们是较新的,否则它们被正确忽略。

===============>>#14 票数:10

根据我审查代码和设计项目的经验,OOP的价值还没有完全实现,因为很多开发人员没有在他们的脑海中正确地概念化面向对象的模型 因此,他们不使用OO设计编程,经常继续编写自上而下的程序代码,使类成为一个非常扁平的设计。 (如果你甚至可以称之为“设计”)

观察同事们对抽象类或接口是什么的了解是非常可怕的,更不用说正确设计继承层次结构以满足业务需求。

然而,当存在良好的OO设计时,阅读代码并看到代码自然地落入直观的组件/类中只是纯粹的快乐。 我一直认为系统架构和设计就像设计公司中的各个部门和员工一样 - 所有这些都是为了完成宏观方案中的某项工作,从而发挥推动组织/系统前进所需的协同作用。

那当然,是相当罕见的不幸。 就像世界上设计精美的设计与可怕设计的物理对象的比例一样,软件工程和设计也是如此。 拥有良好的工具并不一定能带来良好的实践和结果。

===============>>#15 票数:9

也许帽子,膝盖或树不是椅子,但它们都是ISittable。

===============>>#16 票数:8

我认为那些现实世界的东西都是物体

你做?

发票有哪些方法? 等一下。 它不能自己付费,它不能自己发送,它无法与供应商实际交付的项目进行比较。 它根本没有任何方法; 它是完全惰性和无功能的。 它是一种记录类型(结构,如果您愿意),而不是对象。

同样你提到的其他事情。

仅仅因为某些东西是真实的并不能使它成为OO意义上的一个对象。 OO对象是状态和行为的特殊耦合,可以自行行动。 这不是现实世界中丰富的东西。

===============>>#17 票数:7

我在过去的9年左右一直在编写OO代码。 除了使用消息传递之外,我很难想象其他方法。 我看到的主要好处完全符合CodingTheWheel所说的:模块化。 OO自然地引导我从模块化组件构建我的应用程序,这些组件具有干净的界面和明确的职责(即松散耦合,高度内聚的代码以及明确的关注点分离)。

我认为OO崩溃的地方是人们创建深层嵌套的类heirarchies。 这可能导致复杂性。 然而,将共同的功能分解为基类,然后在其他后代类中重用它是一个非常优雅的事情,恕我直言!

===============>>#18 票数:7

首先,观察结果有点草率。 我没有关于软件生产力的数据,也没有充分的理由相信它没有上升。 此外,由于有许多人滥用OO,即使OO是花生酱以来最好的东西,使用OO也不一定能提高生产率。 毕竟,一个不称职的脑外科医生可能会比没有人更糟糕,但一个称职的脑外科医生可能是非常宝贵的。

话虽这么说,OO是一种不同的排列方式,将过程代码附加到数据上,而不是让程序代码对数据进行操作。 这应该至少是一个小胜利,因为有些情况下OO方法更自然。 毕竟,没有什么可以阻止任何人在C ++中编写程序性API,因此提供对象的选项使得语言更加通用。

此外,OO做得非常好:它允许旧代码自动调用新代码,无需更改。 如果我有程序性地管理事物的代码,并且我添加了一个与之前的类似但不相同的新类型的东西,我必须更改过程代码。 在OO系统中,我继承了功能,改变了我喜欢的内容,并且由于多态性而自动使用新代码。 这增加了变化的局部性,这是一件好事。

缺点是良好的OO不是免费的:需要时间和精力才能正确学习它。 由于它是一个重要的流行词,因此有很多人和产品做得很差,只是为了做到这一点。 设计一个好的类接口而不是一个好的过程API并不容易,而且还有各种容易出错的错误(比如深层次的层次结构)。

将其视为一种不同的工具,通常不一定更好。 比如锤子和螺丝刀。 也许我们最终会从软件工程的实践中走出来,因为他知道使用哪种扳手敲击螺钉。

===============>>#19 票数:6

@Sean

然而,将共同的功能分解为基类,然后在其他后代类中重用它是一个非常优雅的事情,恕我直言!

但无论如何,“程序化”开发人员已经这样做了几十年。 语法和术语可能不同,但效果相同。 OOP比“在基类中重复使用常用功能”还要多,我甚至可能会说很难将其描述为OOP; 从不同的代码位调用相同的函数是一种与子过程本身一样古老的技术。

===============>>#20 票数:6

@Konrad

OOP可能存在缺陷,它肯定不是银弹,但它使大规模应用程序变得更加简单,因为它是减少依赖性的好方法

这就是教条。 在这方面,我没有看到OOP明显优于旧程序编程的原因。 每当我进行程序调用时,我都会将自己从实现的细节中分离出来。

===============>>#21 票数:6

对我来说,OOP语法本身有很多价值。 使用试图表示真实事物或数据结构的对象通常比尝试使用一堆不同的扁平(或“浮动”)函数对相同数据执行相同操作更有用。 对具有良好OOP的事物有一定的自然“流动”,这对于长期阅读,编写和维护更有意义。

Invoice实际上并不一定是具有可以自己执行的函数的“对象” - 对象实例只是为了对数据执行函数而不必知道实际存在哪种类型的数据。 可以成功调用函数“invoice.toJson()”,而无需知道“发票”是什么类型的数据 - 结果将是Json,无论它来自数据库,XML,CSV甚至是另一个JSON对象。 使用过程函数,你突然间必须更多地了解你的数据,并最终得到像“xmlToJson()”,“csvToJson()”,“dbToJson()”等函数。它最终变成一个完整的混乱和一个如果你改变了基础数据类型,那就太头痛了。

OOP的要点是通过抽象来隐藏实际的实现。 要实现该目标,您必须创建一个公共接口。 为了使您的工作更容易创建公共接口并保持干净,您必须使用抽象类,继承,多态和设计模式等概念。

所以对我来说,OOP真正的首要目标是使未来的代码维护和更改变得更容易。 但即使超越这一点,当以程序代码永远无法完成的方式正确完成时,它可以真正简化很多事情。 如果它与“真实世界”不匹配并不重要 - 无论如何,用代码编程都不会与现实世界的对象交互。 OOP只是一个让我的工作更轻松,更快的工具 - 我会在任何一天都去做。

===============>>#22 票数:5

@CodingTheWheel

但是,就OOP浪费时间而言,我认为这是因为缺乏程序员培训,而且学习语言特定OOP映射的学习曲线陡峭。 有些人“得到”OOP而其他人永远不会。

不过,如果这真的令人惊讶,我不知道。 我认为,技术上正确的措施(LSP是显而易见的事)作出艰难使用 ,但如果我们不使用这种方法它使代码脆弱和不可延伸反正(因为我们可以了解它不再理由)。 而且我认为OOP引导我们采取违反直觉的结果会让人们不会惊讶于人们不会捡到它。

更重要的是,由于软件对于普通人来说已经基本上难以可靠和准确地编写,我们是否真的应该赞美一种一贯教导并且难以学习的技术? 如果利益是明确的,那么尽管存在困难,它仍然值得坚持,但似乎并非如此。

===============>>#23 票数:5

@Jeff

相对于直接的程序编程,OOP的第一个基本原则是信息隐藏和封装的概念。 这个想法导致类的概念将接口与实现分开。

哪个有更隐蔽的实现:C ++的iostreams,或C的FILE * s?

我认为使用不透明的上下文对象(在Win32中的HANDLEs,在C中的FILE *,用来命名两个着名的例子 - 地狱,HANDLEs生活在内核模式障碍的另一边,它真的没有得到在程序代码中也可以找到比封装更多的封装; 我很难看到这对OOP来说是多么特别。

我想这可能是我努力看到好处的原因之一:明显好的部分并不是OOP特有的,而OOP特有的部分显然不是很好! (这并不是说它们一定是坏的,而是我没有看到它们广泛适用且始终有益的证据)。

===============>>#24 票数:5

在我读过的唯一一个开发博客中,我是那个Joel-On-Software-based创始人,我读过很久以前OO并没有提高生产力。 自动内存管理。 凉。 谁可以拒绝这些数据?

我仍然相信OO是非OO的功能编程是内联编程。

(我应该知道,当我开始使用GWBasic时。)当您重构代码以使用函数时, variable2654变为您所使用的方法的variable3或者,更好的是,它有一个您可以理解的名称, 如果函数很短,它被称为value ,这足以让人完全理解。

当没有函数的代码成为带方法的代码时,您可以删除数英里的代码。

当您将代码重构为真正的OO时, bcqZ成为thisthisthisthis 由于我不相信使用this关键字,因此您可以删除数英里的代码。 实际上,即使你使用this ,你也可以做到这this



我不认为OO是天生的比喻。

我不认为语言也是一种自然的比喻,我也不认为福勒的“气味”比说“这段代码味道不好”更好。 也就是说,我认为面向对象并不是关于自然隐喻,而那些认为对象刚出现在你身上的人基本上忽略了这一点。 您定义了对象Universe,更好的对象Universe导致代码更短,更容易理解,更好地工作,或者所有这些(以及我忘记的一些标准)。 我认为使用客户/域的自然对象作为编程对象的人缺乏重新定义宇宙的能力。

例如,当您使用机票预订系统时,您所谓的预订可能根本不符合法律/商业预订。



一些基本概念是非常酷的工具

我认为大多数人都夸大了整体“当你有一把锤子,他们都是钉子”的东西。 我认为硬币/镜子的另一面也是如此:当你有一个像多态/继承这样的小工具时,你就会开始找到适合手套/袜子/隐形眼镜的用途。 OO的工具非常强大。 我认为,单继承对于不被人带走的人来说是绝对必要的,我自己的多继承软件是不能承受的。



OOP有什么意义?

我认为这是处理绝对庞大代码库的好方法。 我认为它可以让你组织和重新组织你的代码,并为你提供一种语言(超出你正在使用的编程语言),并以一种非常自然和易于理解的方式模块化代码。

OOP注定会被大多数开发人员误解

这是因为它是一个令人大开眼界的过程,就像生活一样:你越来越了解OO的经验,并开始避免使用某些模式,并在你变得更聪明时使用其他模式。 pattern instead. 最好的示例之一是您停止对您无法控制的类使用继承,而是更喜欢模式。



关于你的小论文/问题

我确实想提一下你是对的。 在大多数情况下,可重用性是一个梦想。 下面是安德斯Hejilsberg关于该主题的报价(辉煌) 从这里

如果你要求初级程序员编写一个日历控件,他们常常会自己想:“哦,我将编写世界上最好的日历控件!它将在日历类型方面具有多态性。它将有显示器,和mungers,以及这个,那个和另一个。“ 他们需要在两个月内发送日历应用程序。 他们将所有这些基础设施放在控件中,然后花两天时间在其上面编写一个糟糕的日历应用程序。 他们会想,“在下一个版本的应用程序中,我将会做更多的事情。”

一旦他们开始思考他们实际上是如何实现他们的抽象设计的所有其他具体化,然而事实证明他们的设计是完全错误的。 现在他们把自己画成了一个角落,他们不得不抛弃整个事物。 我一遍又一遍地看到了。 我坚信极简主义。 除非您确实要解决一般问题,否则不要尝试使用框架来解决特定问题,因为您不知道该框架应该是什么样子。

===============>>#25 票数:4

你有没有用WinAPI创建一个窗口?

比我记得的次数多。

然后你应该知道你定义了一个类(RegisterClass),创建它的一个实例(CreateWindow),调用虚方法(WndProc)和基类方法(DefWindowProc)等等。 WinAPI甚至采用SmallTalk OOP的命名法,调用方法“消息”(Window Messages)。

然后你也会知道它没有自己的消息发送,这是一个很大的空洞。 它也有蹩脚的子类。

句柄可能不是可继承的,但是,Java中有最终版本。 他们不缺课,他们是班级的占位符:这就是“句柄”这个词的含义。 看看像MFC或.NET WinForms这样的架构,很明显,除了语法之外,与WinAPI没什么不同。

它们在接口或实现中都是不可继承的,最小可替代的,并且它们与程序编码器一直在做的事情没有太大的不同。

这真的吗? OOP的最佳位置只是......传统的程序代码? 那是大事吗?

===============>>#26 票数:4

我完全同意InSciTek Jeff的回答,我将添加以下改进:

  • 信息隐藏和封装:对于任何可维护代码都至关重要。 可以通过在任何编程语言中小心,不需要OO功能来完成,但这样做会使您的代码略微类似于OO。
  • 继承:有一个重要的应用程序域,所有这些OO 是一种类型包含 -关系是完美契合:图形用户界面。 如果您尝试在没有OO语言支持的情况下构建GUI,那么无论如何您最终都会构建类似OO的功能,并且在没有语言支持的情况下更难以且更容易出错。 例如,Glade(最近)和X11 Xt(历史上)。

使用OO功能(特别是深层嵌套的抽象层次结构),当没有意义时,是没有意义的。 但对于某些应用领域,确实有一点。

===============>>#27 票数:4

我相信最有利的OOP质量是数据隐藏/管理。 然而,有很多例子中OOP被滥用,我认为这是混乱的地方。

仅仅因为你可以把东西变成对象并不意味着你应该。 但是,如果这样做会使您的代码更有条理/更容易阅读,那么您绝对应该这样做。

OOP非常有用的一个很好的实际例子是我在我们网站上使用的“产品”类和对象。 由于每个页面都是一个产品,并且每个产品都引用了其他产品,因此您所引用的数据所引用的产品会非常混乱。 这个“strURL”变量是指向当前页面,主页或统计页面的链接吗? 当然,您可以制作引用相同信息的各种不同变量,但proCurrentPage-> strURL更容易理解(对于开发人员而言)。

此外,将功能附加到这些页面更加清晰。 我可以做proCurrentPage-> CleanCache(); 其次是proDisplayItem-> RenderPromo(); 如果我只是调用这些函数并假设当前数据可用,谁知道会发生什么样的恶。 此外,如果我必须将正确的变量传递给这些函数,我回到了为不同产品提供各种变量的问题。

相反,使用对象,我的所有产品数据和功能都很干净,易于理解。

然而。 OOP的一个大问题是当有人认为一切都应该是OOP时。 这会产生很多问题。 我的数据库中有88个表。 我只有大约6个班级,也许我应该有大约10个班级。我绝对不需要88个班级。 在我使用它的情况下,大多数时间直接访问这些表是完全可以理解的,而OOP实际上会使得更难以/乏味地了解正在发生的事情的核心功能。

我相信一个混合的对象模型,其中实用的有用和程序是最有效的编码方法。 遗憾的是,我们拥有所有这些宗教战争,人们主张以牺牲其他方法为代价来使用一种方法。 他们都很好,他们都有自己的位置。 大多数情况下,在每个较大的项目中都有两种方法的用途(在一些较小的项目中,单个对象或几个程序可能就是您需要的所有内容)。

===============>>#28 票数:3

我不像在可读性方面那样关心重用。 后者意味着您的代码更容易更改。 仅凭这一点在构建软件的过程中是值得的。

OO是一种非常有效的方法,可以使您的程序可读。 重用或不重用。

===============>>#29 票数:2

“现实世界不是”OO“,”

真? 我的世界充满了物体。 我现在正在使用一个。 我认为让软件“对象”模拟真实对象可能不是一件坏事。

面向概念性事物的OO设计(如Windows,而不是真实世界的窗口,但我的计算机显示器上的显示面板)通常会留下很多不足之处。 但对于现实世界的事情,如发票,运输订单,保险索赔和什么不是,我认为那些现实世界的东西都是对象。 我的桌子上有一堆,所以它们必须是真实的。

===============>>#30 票数:2

OOP的目的是为程序员提供另一种方法,用于描述和向机​​器和人员传递代码问题的解决方案。 其中最重要的部分是与人们的沟通。 OOP允许程序员通过在OO语言中强制执行的规则来声明它们在代码中的含义。

与关于该主题的许多论点相反,OOP和OO概念在所有代码中都是普遍存在的,包括非OOP语言中的代码,例如C.许多高级非OO程序员即使在非OO语言中也将近似于对象的特征。

将OO内置到语言中只会给程序员另一种表达方式。

编写代码最大的部分不是与机器的通信,这部分很容易,最大的部分是与人类程序员的沟通。

  ask by community wiki translate from so

未解决问题?本站智能推荐:

20回复

OOP:什么时候是对象?

我试图理解面向对象。 我当然理解它,但有时候我并不是100%清楚。 你如何决定什么应该变成一个对象(另一个大整个对象的小对象部分)或者什么不值得成为一个对象,或者它应该只是那个大整个对象的属性? 对于一扇门,我猜门把手应该是一个独立的物体,但是你插入钥匙的中间部分应该是一个独立的物体还
1回复

没有OOP的封装是否可能?

在一次采访中有人问我一个问题:如果没有OOP,例如在程序语言中,封装是否可行?
3回复

OOP:何处停止抽象

你在哪里绘制线来停止抽象并开始编写合理的代码? 有很多“企业代码”的例子,比如十几个文件“FizzBu​​zz”程序......即使像RTS游戏那样简单的东西也可以有: 等...它可以变成一场噩梦。 这可以被绘制到它的逻辑极端,就像函数式编程可以被绘制到极端,你可以创建只有变量,函数
14回复

OOP中的主要概念

我曾在接受采访时被问及“OOP的3个主要概念是什么?”。 我回答说,我认为有4个如下: 遗产 封装 抽象化 多态性 我是对的吗?
3回复

多态性是OOP独有的吗?

我是学生,所以我不知道我的问题是否有错。 我知道多态性通常是通过方法重写,函数重载等在OOP中实现的。 但这是OOP语言专有的概念吗? 如果不是,您能否提供一些示例,说明如何使用非OOP语言(包括C,但非C语言除外)来实现它? (到目前为止,我已有一些Java,C ++,C,Javasc
5回复

OOP:良好的班级设计

我的问题与此相关: Python工具,它为类的方法构建依赖关系图 。 在找不到任何工具后我自己写了一个快速黑客:我已经使用了编译器模块,我已经将源代码解析为抽象源代码树,并且我已经用它来收集类方法之间的依赖关系。 我的脚本生成了graphviz的输入文件,用于生成看起来像这样的依赖图。
3回复

OOP闭包有哪些用途?

PHP和.Net有闭包; 我一直想知道在OOP和设计模式中使用闭包的一些例子,以及它们相对于纯OOP编程有什么优势。 作为澄清,这不是OOP与函数编程,而是如何在OOP设计中最好地使用闭包。 闭包如何适用于工厂或观察者模式? 例如,您可以采用哪些技巧来澄清设计并导致更松散的耦合。
16回复

在大学中滥用OOP吗? [关闭]

已关闭 。 这个问题是基于观点的 。 它当前不接受答案。 想改善这个问题吗?
1回复

什么是OOP中的数组字典?

在OOP的上下文中,由数组字典构成的数据结构的名称(或类名称)是什么? (一个字典,其中每个键都映射到值的集合) 如果找不到代表该数据结构的类,那么该对象的专有名称是什么? 我来自http://en.wikipedia.org/wiki/List_of_data_structure
9回复

程序式编程与OOP的开发成本?

我来自一个相当强大的OO背景,OOD和OOP的好处对我来说是第二天性,但最近我发现自己处于一个与程序编程习惯相关的开发工作室。 实现语言具有一些OOP功能,它们不以最佳方式使用。 更新:每个人似乎对此主题都有意见,我也是如此,但问题是: 是否有任何良好的比较研究对比使用过程编程语言