OOP有什么意义？
据我所知，尽pipeOOP教育，语言和工具耗费了数百万甚至数十亿，但OOP并没有提高开发人员的生产力或软件可靠性，也没有降低开发成本。 很less有人使用面向对象的方式（很less有人坚持或理解LSP的原理）; 人们对问题领域build模的方法似乎很less统一或一致。 通常，这个class级只是用于语法糖; 它将loggingtypes的函数放入自己的小名字空间中。
我为各种应用程序编写了大量的代码。 虽然有一些地方真正可替代的子types在应用程序中扮演了重要的angular色，但这些都是非常特殊的。 一般来说，虽然口头上说“重用”，但实际情况是，除非一段代码完全符合你的要求，否则几乎没有成本效益的“重用”。 将类devise为可扩展的方式是非常困难的，因此扩展的成本通常非常高，“重用”根本就是不值得的。
在很多方面，这并不令我感到意外。 现实世界不是“OO”，OO中隐含的想法 – 我们可以用某种分类法来模拟事物 – 在我看来，这在本质上是非常有缺陷的（我可以坐在桌子，树桩，汽车发动机罩上，某人的膝盖 – 但不是其中之一 – 椅子）。 即使我们转向更抽象的领域，面向对象build模往往是困难的，违反直觉的，并最终无益（考虑圆/椭圆或正方形/矩形的经典例子）。
那么我在这里错过了什么？ 面向对象的价值在哪里，为什么所有的时间和金钱都不能使软件更好？
没有经validation据表明面向对象是人们思考世界的更自然的方式。 在编程心理学领域有一些工作，表明面向对象并不比其他方法更适合。
面向对象的表示看起来并不普遍更有用或更less用。
简单地采用面向对象的方法是不够的，需要开发者使用这种方法，因为这可能会对开发人员的生产力以及开发的系统的质量产生负面影响。
ACM交stream中的“面向对象代表的可用性”是从2000年10月发表的。这篇文章主要是将面向对象与面向过程的方法进行比较。 有很多关于如何使用OO方法的人“思考”的研究（Int.J.of Human-Computer Studies 2001，issue 54，或Human-Computer Interaction 1995，第10卷，OO研究的整个主题），从我所读到的内容来看，没有任何东西可以说明面向对象方法的某种自然性，这使得它比传统的程序方法更适合。
现实世界不是“OO”，OO中隐含的观点 – 我们可以用一些分类标准来对事物进行build模 – 在我看来，这是非常根本性的缺陷
虽然这是真的，并已被其他人观察到（STL的发明者斯捷潘诺夫），其余的都是无稽之谈。 面向对象可能有缺陷，它当然不是银弹，但它使大规模的应用程序更简单，因为这是一个减less依赖的好方法。 当然，这只适用于“好”的OOPdevise。 马虎devise不会有任何优势。 但是使用OOP很好地解耦devise可以很好地build模，而且不能很好地使用其他技术。
有更好，更通用的模型（想起Haskell的types模型 ），但这些模型往往更加复杂和/或难以有效地实现。 OOP是极端之间的一个很好的折衷。
OOP不是创build可重用的类，关于创build可用类。
通常，这个class级只是用于语法糖; 它将loggingtypes的函数放入自己的小名字空间中。
是的，我觉得这个也太普遍了。 这不是面向对象编程。 这是基于对象编程和数据中心编程。 在与OO语言合作的10年中，我看到大多数人在做基于对象的编程。 OBP很快就会崩溃，恕我直言，因为你基本上得到了最差的两个词：1）程序化的编程，没有坚持已经certificate的结构化编程方法和2）没有坚持已certificate的OOP方法的OOP。
OOP做对了是件美事。 这使得很难解决的问题变得很容易，而对于那些不懂事的人来说（这里不是那么夸张），它几乎看起来像是魔法。 这就是说，OOP只是编程方法学工具箱中的一个工具。 这不是所有的最终方法。 恰好适合大型商业应用。
大多数使用OOP语言的开发人员正在利用OOP的例子，在日常使用的框架和types中正确使用OOP，但他们并没有意识到这一点。 这里有一些非常简单的例子：ADO.NET，Hibernate / NHibernate，日志框架，各种语言集合types，ASP.NET堆栈，JSP堆栈等……这些都是严重依赖OOP的代码库。
重用不应该是面向对象的目标 – 或者任何其他的范例。
重用是一个良好的devise和适当的抽象层次的副作用。 代码通过做一些有用的事情来实现重用，但是没有做太多的事情来使其变得不灵活。 代码是否是面向对象并不重要 – 我们重用了一些有用的东西，而不是微不足道的做我们自己。 这是实用主义。
面向对象作为通过inheritance获得重用的新途径的思想是根本上的缺陷。 正如你注意到LSP的违规行为比比皆是。 OO恰恰被认为是一种pipe理问题域复杂性的方法。 目标是随着时间的推移系统的可维护性。 实现这一目标的主要工具是公共接口与私有实现的分离。 这使得我们可以制定像“这只应该使用…修改”的规则，而不是代码审查。
使用这个，我相信你会同意，让我们创build和维护非常复杂的系统。 在这方面有很多价值，在其他范例中做起来并不容易。
对宗教进行审视，但我会说，你正在描绘现代OOP状态的过于严峻的画面。 我认为它实际上降低了成本，使大型软件项目可以pipe理，等等。 这并不意味着它解决了软件混乱的根本问题，并不意味着普通开发人员是OOP专家。 但是，function模块化的对象组件确实减less了世界范围内的意大利面代码的数量。
我可以想象我头顶的数十个图书馆，这些图书馆都是可重复使用的，而且节省了时间和金钱，这是永远无法计算的。
但就OOP浪费时间而言，我想说这是因为缺乏程序员培训，加上学习语言特定的OOP映射的陡峭的学习曲线。 有些人“得到”OOP和其他人永远不会。
我认为使用不透明的上下文对象（Win32中的HANDLE，C中的FILE *，命名两个众所周知的例子 – 地狱，HANDLEs居住在内核模式障碍的另一边，而且它真的不能得到在程序代码中也可以find更多的封装） 我正在努力看到这是如何是面向对象的东西。
HANDLE （和WinAPI的其余部分） 是 OOP！ C不太支持OOP，所以没有特别的语法，但并不意味着它不使用相同的概念。 WinAPI在任何意义上都是一个面向对象的框架。
看，这是每个讨论涉及面向对象技术或其他技术的麻烦：没有人清楚定义，每个人都在谈论别的事情，因此没有达成共识。 好像浪费时间在我身上。
它是一个编程范例。旨在使我们更容易让凡人把问题分解成更小，更可行的作品。
如果你不觉得有用..不要使用它，不要付出培训，并开心。
另一方面，我发现它是有用的，所以我会:)
与直接程序devise相比，OOP的第一个基本原则是信息隐藏和封装的概念。 这个想法导致了类将接口与实现分离的概念。 这些都是非常重要的概念，也是build立一个框架以不同的方式，以更好的方式思考程序devise的基础。 你不能反对这些属性 – 没有权衡取舍，它总是一个更干净的方式来模块化的东西。
包括inheritance和多态在内的面向对象的其他方面也很重要，但正如其他人所暗示的那样，这些方面通常被过度使用。 即：有时人们使用inheritance和/或多态，因为他们可以，而不是因为他们应该拥有。 他们是强大的概念和非常有用的，但需要明智地使用，并不是自动赢得面向对象的优点。
相对于重用。 我同意重新使用是为了面向对象销售。 这是定义明确的对象的一个可能的副作用，通常是更原始的/generics的类，并且是封装和信息隐藏概念的直接结果。 它可能更容易被重用，因为明确定义的类的接口只是更简单，有些自我logging。
OOP的问题是超卖。
正如艾伦·凯最初设想的那样，这是以前的原始数据和全球化程序的一个很好的select。
然后，一些pipe理顾问types被locking，并作为软件的弥赛亚出售，随之而来的就是类似于学术界和工业界。
现在，他们正在像其他好的想法被超卖，比如函数式编程，就像在</s> </s>一样。
那么，我会做什么不同呢？ 很多，我写了一本关于这个的书。 （已经绝版了 – 我没有一分钱，但是你仍然可以得到副本。） 亚马逊
我的build设性答案是将编程看作是对现实世界中的事物进行build模的一种方式，而不是把需求编码为一种方式。
这是非常不同的，是基于信息理论（任何人都可以理解的水平）。 它说编程可以看作是一个定义语言的过程，而这样做的技巧对于良好的编程是必不可less的。
它提升了域特定语言（DSL）的概念。 它强调DRY（不要重复自己）。 它给了代码生成一个大拇指。 这导致软件的数据结构大大less于现代应用的典型数据结构。
它试图重新激发前进的道路在于创造性的观点，甚至公认的观点也应该受到质疑。
手柄（和WinAPI的其余部分）是OOP！
他们是吗？ 它们不是可以inheritance的，它们当然是不可替代的，它们缺乏明确定义的类。我认为它们距“OOP”还有很长的路要走。
你有没有使用WinAPI创build窗口？ 然后你应该知道你定义了一个类（ RegisterClass ），创build它的一个实例（ CreateWindow ），调用虚拟方法（ WndProc ）和基类方法（ DefWindowProc ）等等。 WinAPI甚至采用SmallTalk OOP的命名法，调用方法“消息”（窗口消息）。
句柄可能不是可inheritance的，但是在Java中是final的。 他们不缺less一个class级，他们是class级的占位者：这就是“处理”这个词的意思。 看看像MFC或.NET WinForms这样的体系结构，立即明显的是，除了语法之外，没有什么与WinAPI不同。
是的OOP没有解决我们所有的问题，对此感到遗憾。 不过，我们正在从事SOA解决所有这些问题。
OOP非常适合编程内部计算机结构，如GUI“窗口小部件”，例如，SelectList和TextBox可能是Item的子types，具有“移动”和“resize”等常用方法。
麻烦的是，我们90％的人在业务领域工作，我们正在处理发票，员工，工作，订单等业务概念。 这些不适合面向对象，因为“对象”更加模糊，随着业务重组等原因而改变。
最糟糕的情况是面向对象数据库的热烈应用，包括对SQL数据库的令人震惊的OO“增强” – 除了数据库新手，他们认为他们一定是正确的做事方式，因为他们更新，这是正确的。
在我经历的关于项目的代码和devise的经验中，OOP的价值并没有完全实现，因为许多开发人员没有在他们的想法中正确地概念化面向对象的模型 。 因此，他们不用OOdevise编程，经常继续编写自上而下的程序代码，使得这些类很平坦的devise。 （如果你甚至可以称之为“devise”）
观察一个抽象的类或接口是多么的less有的同事知道是非常可怕的，更不用说devise一个适合业务需求的inheritance层次结构。
但是，当出现良好的面向对象devise时，阅读代码仅仅是一种乐趣，并且看到代码自然地落入直观的组件/类中。 我一直认为系统架构和devise就像devise一个公司的各个部门和员工的工作一样，都是为了在事物的macros伟计划中完成一定的工作，发挥推动组织/系统前进的协同作用。
当然，这是很不幸的。 就像世界上devise精美的devise与可怕的物理对象的比例一样，软件工程和devise也是如此。 拥有好的工具并不一定能带来好的做法和结果。
也许一个发动机罩，一圈或一棵树不是椅子，但他们都是可以的。
我认为这些现实世界的东西是对象
你做？
发票有什么方法？ 等一下。 它不能自付，不能自行发送，不能与供应商实际交付的物品相比较。 它根本没有任何方法; 它是完全惰性的，不起作用。 这是一个loggingtypes（如果你愿意，可以是一个结构体），而不是一个对象。
同样，你提到的其他事情。
仅仅因为事物是真实的，并不是OO意义上的对象。 面向对象是一种特殊的状态和行为耦合，可以自行行事。 这在现实世界中并不丰富。
过去9年来我一直在写OO代码。 除了使用消息，我很难想象其他的方法。 我看到的主要好处完全符合CodingTheWheel所说的：模块化。 OO自然而然地导致我从模块化组件构build我的应用程序，这些模块化组件具有清晰的界面和明确的职责（即松散耦合，高度一致的代码和清晰的关注点）。
我认为OO打破的是人们创造深层次的阶层。 这可能导致复杂性。 然而，把通用的function性分解成一个基类，然后在其他后代类中重用它是一件非常优雅的事情，恕我直言！
首先，这些意见有些草率。 我没有任何关于软件生产力的数据，也没有理由相信这个数字没有上升。 另外，由于有很多人滥用OO，所以即使OO是花生酱以来最大的东西，OO的良好使用也不一定会提高生产力。 毕竟，一个无能的脑外科医生可能比没有一个更糟糕，但有能力的人是非常宝贵的。
也就是说，面向对象是安排事物的一种不同方式，将过程代码附加到数据上，而不是使程序代码对数据进行操作。 这应该至less是一个小小的胜利，因为有些情况下面向对象的方法更加自然。 毕竟，没有什么能够阻止任何人用C ++编写过程化的API，所以提供对象的select使得语言更加通用。
此外，还有一些OO很好：它允许旧代码自动调用新代码，而无需更改。 如果我有程序pipe理的代码，而且我添加了一个类似但不相同的新东西，我必须更改程序代码。 在一个OO系统中，我inheritance了这个function，改变了我喜欢的东西，并且由于多态性而自动使用了新的代码。 这增加了变化的地点，这是一件好事。
缺点是好的面向对象不是免费的：它需要时间和精力来正确地学习。 因为这是一个主要的stream行语，有很多人和产品做得不好，只是为了这样做。 devise一个好的类接口并不比一个好的过程API更容易，而且还有各种容易产生的错误（如深层次的层次结构）。
把它看作是一种不同的工具，不一定总是更好。 一个锤子除了一个螺丝刀，说。 也许我们最终会摆脱软件工程的做法，就是知道用什么扳手敲击螺丝钉。
@Sean
然而，把通用的function性分解成一个基类，然后在其他后代类中重用它是一件非常优雅的事情，恕我直言！
但是“程序性”开发人员几十年来一直这样做。 语法和术语可能不同，但效果是相同的。 OOP比“在基类中重用常用function”还要多，甚至可以说这很难被描述为OOP; 从不同的代码位调用相同的函数是一种与subprocess本身一样古老的技术。
@Konrad
OOP可能有缺陷，它当然不是银弹，但它使大规模的应用程序更简单，因为这是减less依赖关系的好方法
这是教条。 我没有看到什么使得OOP在这方面比旧的程序编程更好。 每当我做一个程序调用时，我都将自己与实现的细节隔离开来。
对我来说，OOP语法本身有很多价值。 使用试图表示真实事物或数据结构的对象通常比使用一堆不同的平面（或“浮动”）函数对同样的数据做同样的事情更有用。 对于具有良好的面向对象的事物来说，存在一定的自然“stream动”，这对读取，写入和长期保持更有意义。
发票并不是一个真正的具有可以执行的function的“对象” – 对象实例可以存在只是为了对数据执行function，而不必知道实际存在的数据types。 函数“invoice.toJson（）”可以被成功调用，而不必知道“发票”是什么types的数据 – 结果将是Json，无论它来自数据库，XML，CSV还是其他JSON对象。 通过程序function，你突然间必须知道更多关于你的数据的信息，并最终得到像“xmlToJson（）”，“csvToJson（）”，“dbToJson（）”等等的函数。如果您更改了底层的数据types，那么会非常头痛。
面向对象的要点是通过抽象的方式隐藏实际的实现。 为了实现这个目标，你必须创build一个公共接口。 为了使您的工作更容易，同时创build公共接口并保持干爽，您必须使用抽象类，inheritance，多态和devise模式等概念。
所以对我来说，OOP的真正首要目标是使未来的代码维护和更改变得更容易。 但即使如此，如果程序代码永远无法正确完成，它可以真正简化很多事情。 不要紧，如果它不符合“现实世界” – 与代码编程不与真实世界的对象交互反正。 面向对象只是一个让我的工作更轻松，更快速的工具 – 我会在任何一天都去。
@CodingTheWheel
但就OOP浪费时间而言，我想说这是因为缺乏程序员培训，加上学习语言特定的OOP映射的陡峭的学习曲线。 有些人“得到”OOP和其他人永远不会。
我不知道这是否真的令人惊讶。 我认为技术上可行的方法（LSP是显而易见的） 很难使用 ，但是如果我们不使用这种方法，那么它就会使代码变得脆弱和不可扩展（因为我们不能再推理了）。 而且我认为OOP带给我们的违反直觉的结果使得人们不理解它是不足为奇的。
更重要的是，由于软件对于正常人来说已经基本上难以可靠和准确地编写，我们是否真的应该赞美一直教育得不好而且难以学习的技术呢？ 如果利益是明确的，那么尽pipe存在困难，但也许值得坚持下去，但似乎并非如此。
@Jeff
与直接程序devise相比，OOP的第一个基本原则是信息隐藏和封装的概念。 这个想法导致了类将接口与实现分离的概念。
哪个有更隐藏的实现：C ++的iostreams，还是C的FILE * s？
我认为使用不透明的上下文对象（Win32中的HANDLE，C中的FILE *，命名两个众所周知的例子 – 地狱，HANDLEs居住在内核模式障碍的另一边，而且它真的不能得到在程序代码中也可以find更多的封装） 我正在努力看到这是如何是面向对象的东西。
我想这可能是我努力看到好处的一部分：明显好的部分不是OOP特有的，而OOP特有的部分并不明显好。 （这并不是说它们肯定是坏的，而是我没有看到它们是广泛适用的，持续有益的证据）。
在我读过的唯一一个开发者博客中 ，我曾经阅读过很久以前，OO不会导致生产率提高的问题。 自动内存pipe理呢。 凉。 谁可以否认数据？
我仍然相信面向对象的非OO编程的function是将所有内联编程。
（我应该知道，因为我开始使用GWBasic。）当您重构代码以使用函数时， variable2654变为您所在方法的variable3或者，更好的是，它有一个您可以理解的名称， 如果函数是短暂的，这就是所谓的value ，这是足够的全面理解。
当没有函数的代码变成带有方法的代码时，你可以删除几英里的代码。
当你重构代码是真正的OO， b ， c ， q和Z成为this ， this ， this和this 。 因为我不相信使用this关键字，你会删除英里的代码。 其实，即使你使用this ，你也要这样做。
我不认为面向对象是自然的隐喻。
我不认为语言也是一种自然的隐喻，我也不认为福勒的“气味”比说“这个代码味道不好”更好。 也就是说，我认为面向对象不是关于自然的隐喻， 而是认为这些东西只是在你身上popup的人基本上忽略了这一点。 你定义了对象的宇宙，更好的对象宇宙导致代码更短，更容易理解，更好的工作，或所有这些（以及一些我忘记的标准）。 我认为使用客户/域的自然对象作为编程对象的人们正在失去重新定义宇宙的力量。
例如，当您执行航class预订系统时，您所称的预订可能根本不符合法定/商业预订。
一些基本概念是非常酷的工具
我认为大多数人都夸大了整个“当你有锤子的时候，他们都是钉子”的东西。 我认为硬币/镜子的另一面也是如此：当你有一个像多态性/inheritance的小工具时，你会开始寻找像手套/袜子/隐形眼镜一样适合的地方。 面向对象的工具非常强大。 我认为，单遗传是绝对必要的，不要被人遗忘，我自己的多inheritance软件不能承受。
OOP有什么意义？
我认为这是处理绝对庞大的代码库的好方法。 我认为它可以让你组织和重新组织你的代码，并为你提供一种语言（除了你正在使用的编程语言之外），并以一种非常自然和易于理解的方式模块化代码。
OOP注定会被大多数开发者误解
这是因为这是一个像生活一样的开眼界的过程：你越来越了解面向对象的经验，并开始避免某些模式，并雇用别人，因为你越来越聪明。 最好的例子之一是，你停止使用你不能控制的类的inheritance，而改为使用Facade模式。
关于你的小散文/问题
我确实想提到你是对的。 可重用性大部分是pipe道梦想。 以下是来自Anders Hejilsberg关于这个主题（辉煌）的引用：
如果你问开始的程序员写一个日历控件，他们常常会想：“哦，我要写出世界上最好的日历控件！这种日历将会是多态的，它将会有显示器，和这个，这个，还有其他的。“ 他们需要在两个月内发送一个日历应用程序。 他们把所有这些基础设施放在控制之中，然后花两天时间写一个蹩脚的日历应用程序。 他们会想，“在下一个版本的应用程序中，我会做更多。”
一旦他们开始思考他们是如何去实现所有这些抽象devise的其他具体化的话，事实certificate他们的devise是完全错误的。 现在他们已经把自己涂在了一个angular落，他们必须把所有的东西都扔掉。 我一遍又一遍地看到。 我是一个极简主义的坚定信徒。 除非你真的要解决一般问题，否则不要试图解决具体问题的框架，因为你不知道框架应该是什么样的。
你有没有使用WinAPI创build窗口？
比我还记得更多的时间。
然后你应该知道你定义了一个类（RegisterClass），创build它的一个实例（CreateWindow），调用虚拟方法（WndProc）和基类方法（DefWindowProc）等等。 WinAPI甚至采用SmallTalk OOP的命名法，调用方法“消息”（窗口消息）。
那么你也会知道它没有自己的消息发送，这是一个很大的缺陷。 它也有蹩脚的子类。
句柄可能不是可inheritance的，但是在Java中是最后的。 他们不缺less一个class级，他们是class级的占位者：这就是“处理”这个词的意思。 看看像MFC或.NET WinForms这样的体系结构，立即明显的是，除了语法之外，没有什么与WinAPI不同的了。
它们在接口或实现中都不是可inheritance的，可以最小程度地替代，而且它们与程序编码器自永远以来一直在做的事情没有实质性的区别。
这是真的吗？ OOP的最佳位是…传统的程序代码？ 这是大交易？
我完全同意InSciTek Jeff的回答，我只是添加下面的改进：
- 信息隐藏和封装：对于任何可维护的代码都很重要。 可以通过小心使用任何编程语言来完成，不需要面向对象的function，但这样做会使你的代码略微OO。
- inheritance：有一个重要的应用程序域，所有这些OO 都是一种types，并且包含着一个关系，它们是完美的匹配：graphics用户界面。 如果您尝试在没有OO语言支持的情况下构buildGUI，那么最终您将最终构build类似于OO的function，而且在没有语言支持的情况下更难，更容易出错。 例如Glade（最近）和X11 Xt（历史上）。
使用面向对象的特性（尤其是深度嵌套的抽象层次结构），当没有意义的时候，是毫无意义的。 但是对于一些应用领域来说，确实有一点意义。
我相信OOP的最有利的质量是数据隐藏/pipe理。 但是，有很多例子，OOP被滥用，我认为这是混淆的地方。
只是因为你可以把东西变成一个物体并不意味着你应该。 但是，如果这样做会使你的代码更有组织性/更容易阅读，那么你绝对应该这样做。
OOP非常有用的一个很好的实例是在我们的网站上使用“产品”类和对象。 由于每个页面都是一个产品，而且每个产品都有对其他产品的引用，所以您可能会对引用的数据产品感到困惑。 这个“strURL”variables是指向当前页面，主页还是统计页面的链接？ Sure you could make all kinds of different variable that refer to the same information, but proCurrentPage->strURL, is much easier to understand (for a developer).
In addition, attaching functions to those pages is much cleaner. I can do proCurrentPage->CleanCache(); Followed by proDisplayItem->RenderPromo(); If I just called those functions and had it assume the current data was available, who knows what kind of evil would occur. Also, if I had to pass the correct variables into those functions, I am back to the problem of having all kinds of variables for the different products laying around.
Instead, using objects, all my product data and functions are nice and clean and easy to understand.
然而。 The big problem with OOP is when somebody believes that EVERYTHING should be OOP. This creates a lot of problems. I have 88 tables in my database. I only have about 6 classes, and maybe I should have about 10. I definitely don't need 88 classes. Most of the time directly accessing those tables is perfectly understandable in the circumstances I use it, and OOP would actually make it more difficult/tedious to get to the core functionality of what is occurring.
I believe a hybrid model of objects where useful and procedural where practical is the most effective method of coding. It's a shame we have all these religious wars where people advocate using one method at the expense of the others. They are both good, and they both have their place. Most of the time, there are uses for both methods in every larger project (In some smaller projects, a single object, or a few procedures may be all that you need).
I don't care for reuse as much as I do for readability. The latter means your code is easier to change. That alone is worth in gold in the craft of building software.
And OO is a pretty damn effective way to make your programs readable. Reuse or no reuse.
"The real world isn't "OO","
真？ My world is full of objects. I'm using one now. I think that having software "objects" model the real objects might not be such a bad thing.
OO designs for conceptual things (like Windows, not real world windows, but the display panels on my computer monitor) often leave a lot to be desired. But for real world things like invoices, shipping orders, insurance claims and what-not, I think those real world things are objects. I have a stack on my desk, so they must be real.
The point of OOP is to give the programmer another means for describing and communicating a solution to a problem in code to machines and people. The most important part of that is the communication to people. OOP allows the programmer to declare what they mean in the code through rules that are enforced in the OO language.
Contrary to many arguments on this topic, OOP and OO concepts are pervasive throughout all code including code in non-OOP languages such as C. Many advanced non-OO programmers will approximate the features of objects even in non-OO languages.
Having OO built into the language merely gives the programmer another means of expression.
The biggest part to writing code is not communication with the machine, that part is easy, the biggest part is communication with human programmers.
