blocks|key|1861068|text|在过去的9年左右，我一直在写面向对象的代码。除了使用消息传递之外，我很难想象还有其他方法。我看到的主要好处与CodingTheWheel所说的完全一致:模块化。OO自然而然地引导我使用具有清晰接口和清晰职责的模块化组件来构建我的应用程序(即松散耦合、高度内聚的代码，具有清晰的关注点分离)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1861069|我认为，当人们创建深度嵌套的类继承结构时，OO就崩溃了。这可能会导致复杂性。然而，将常见的限定性分解到一个基类中，然后在其他后代类中重用它是一件非常优雅的事情，IMHO！|1861070|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I have been writing OO code for the last 9 years or so. Other than using messaging, it's hard for me to imagine other approach. The main benefit I see totally in line with what CodingTheWheel said: modularisation. OO naturally leads me to construct my applications from modular components that have clean interfaces and clear responsibilities (i.e. loosely coupled, highly cohesive code with a clear separation of concerns). 

I think where OO breaks down is when people create deeply nested class heirarchies. This can lead to complexity. However, factoring out common finctionality into a base class, then reusing that in other descendant classes is a deeply elegant thing, IMHO!

blocks|key|2074944|text|-Andrew+Hinton说：“即使没有真正的信息架构，也并不意味着我们没有体验或感知它。禅宗佛教徒说没有真正的‘自我’，但他们仍然给他们的孩子起名字。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2074945|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

"Even if there is no actual [information architecture], it doesn’t mean we don’t experience or perceive it as such. Zen Buddhists say there is no actual “self” but they still name their kids."-Andrew Hinton

blocks|key|1861164|text|这是一种编程范例..旨在使我们这些凡夫俗子更容易将问题分解成更小、更可行的部分。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1861165|如果你觉得它没有用..不要使用它，不要为培训付钱，要快乐。|1861166|另一方面，我确实发现它很有用，所以我将:)|1861167|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Its a programming paradigm.. Designed to make it easier for us mere mortals to break down a problem into smaller, workable pieces..

If you dont find it useful.. Don't use it, don't pay for training and be happy.

I on the other hand do find it useful, so I will :)

blocks|key|2075020|text|OOP降低了成本，提高了效率。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2075021|当我从经典的ASP/VBScript跳到C#时，我注意到有了OOP，工作效率有了很大的提高。|2075022|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

OOP has reduced costs, and increased efficiency.

When I made the jump from classic ASP/VBScript to C# I noticed a HUGE increase in productivity thanks to OOP.

blocks|key|1861328|text|OOP不是关于创建可重用的类，它是关于创建可用的类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1861329|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

OOP isn't about creating re-usable classes, its about creating Usable classes.

blocks|key|1861372|text|也许一顶帽子、一圈或一棵树不是椅子，但它们都是ISittable。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1861373|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Maybe a bonnet, lap or a tree is not a chair but they all are ISittable.

blocks|key|2075296|text|我知道我发现OOP在语法上非常有用(封装、操作符重载、类型检查)。至于OOP的好处...我不知道。我不认为这比程序化的东西更糟糕。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2075297|在轻松的方面，我的OOP讲师说OOP很重要，因为否则“代码会有太多的循环”。嗯。有时，每篇论文要花500美元，这让人很郁闷。:(|2075298|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I know I find OOP useful pretty much solely on a syntactical sugar basis (encapsulation, operator overloading, typechecking). As to the benefits of OOP... I don't know. I don't think it's worse than procedural stuff. 

On the lighter side, my OOP lecturer said that OOP is important because otherwise the "code would have too many loops". Yeah. Sometimes it's depressing that I pay $500 per paper. :(

blocks|key|2075411|text|重用不应该是OOP的目标--或者任何其他的范例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2075412|重用是良好的设计和适当的抽象级别的副作用。代码通过做一些有用的事情来实现重用，但不会做太多事情来使其变得不灵活。代码是不是面向对象并不重要--我们会重用有效的代码，而且我们自己做起来也不是微不足道的。这就是实用主义。|2075413|将OO作为一种通过继承实现重用的新方法的想法是有根本缺陷的。正如您所注意到的，违反LSP的情况比比皆是。相反，OO被恰当地认为是一种管理问题域复杂性的方法。目标是随着时间的推移系统的可维护性。实现这一点的主要工具是将公共接口与私有实现分离。这允许我们有类似“这应该只使用...”这样的规则。由编译器强制执行，而不是代码审查。|2075414|使用它，我相信你会同意，允许我们创建和维护非常复杂的系统。这其中有很多价值，但在其他范例中不容易做到这一点。|2075415|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Reuse shouldn't be a goal of OOP - or any other paradigm for that matter.

Reuse is a side-effect of an good design and proper level of abstraction. Code achieves reuse by doing something useful, but not doing so much as to make it inflexible. It does not matter whether the code is OO or not - we reuse what works and is not trivial to do ourselves. That's pragmatism.

The thought of OO as a new way to get to reuse through inheritance is fundamentally flawed. As you note the LSP violations abound. Instead, OO is properly thought of as a method of managing the complexity of a problem domain. The goal is maintainability of a system over time. The primary tool for achieving this is the separation of public interface from a private implementation. This allows us to have rules like "This should only be modified using ..." enforced by the compiler, rather than code review.

Using this, I'm sure you will agree, allows us to create and maintain hugely complex systems. There is lots of value in that, and it is not easy to do in other paradigms.

blocks|key|1861800|text|我相信OOP最有益的特性是数据隐藏/管理。然而，有很多OOP被误用的例子，我认为这就是混淆的原因。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1861801|仅仅因为你可以将一些东西变成一个对象并不意味着你应该这样做。然而，如果这样做会让你的代码更有条理/更容易阅读，那么你绝对应该这样做。|1861802|OOP非常有用的一个很好的实际例子是我在我们网站上使用的"product“类和对象。由于每个页面都是一个产品，并且每个产品都有对其他产品的引用，因此您所拥有的数据引用哪个产品会变得非常混乱。这个"strURL“变量是指向当前页面的链接，还是指向主页的链接，还是指向统计页面的链接？当然，你可以让各种不同的变量引用相同的信息，但proCurrentPage->strURL更容易理解(对于开发人员来说)。|1861803|此外，将函数附加到这些页面要干净得多。我可以执行proCurrentPage->CleanCache()；然后是proDisplayItem->RenderPromo()；如果我只是调用这些函数并让它假定当前数据可用，谁知道会发生什么坏事。此外，如果我必须将正确的变量传递到这些函数中，我又回到了为不同产品提供各种变量的问题上。|1861804|取而代之的是，使用对象，我所有的产品数据和函数都很好，很干净，很容易理解。|1861805|然而。OOP的大问题是当有人认为一切都应该是OOP的时候。这就产生了很多问题。我的数据库中有88个表。我只有6节课，也许我应该有10节课，我绝对不需要88节课。大多数时候，直接访问这些表在我使用它的情况下是完全可以理解的，而OOP实际上会使它更难/更乏味地获得正在发生的事情的核心功能。|1861806|我认为对象的混合模型是最有效的编码方法，其中实用和过程化是最有效的方法。遗憾的是，我们有所有这些宗教战争，人们提倡使用一种方法，而不是其他方法。他们都很好，他们都有自己的位置。大多数情况下，在每个较大的项目中都会使用这两种方法(在一些较小的项目中，单个对象或几个过程可能就是您所需要的全部)。|1861807|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I believe the most beneficial quality of OOP is data hiding/managing. However, there are a LOT of examples where OOP is misused and I think this is where the confusion comes in. 

Just because you can make something into an object does not mean you should. However, if doing so will make your code more organized/easier to read then you definitely should.

A great practical example where OOP is very helpful is with a "product" class and objects that I use on our website. Since every page is a product, and every product has references to other products, it can get very confusing as to which product the data you have refers to. Is this "strURL" variable the link to the current page, or to the home page, or to the statistics page? 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.

However. 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).

blocks|key|1861915|text|是的，OOP并没有解决我们所有的问题，很抱歉。然而，我们正在致力于SOA，它将解决所有这些问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1861916|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Yes OOP did not solve all our problems, sorry about that. We are, however working on SOA which will solve all those problems.

blocks|key|2075811|text|“现实世界不是"OO"，”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2075812|真的？我的世界充满了物件。我现在正在使用一个。我认为让软件“对象”对真实的对象进行建模可能不是一件坏事。|2075813|面向概念的设计(比如Windows，不是现实世界的窗口，而是我的电脑显示器上的显示面板)经常留下很多需要改进的地方。但对于现实世界的东西，比如发票、发货订单、保险索赔等等，我认为这些现实世界的东西都是对象。我桌上有一堆东西，所以它们一定是真的。|2075814|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

"The real world isn't "OO","

Really? 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.

blocks|key|1862213|text|对我来说，OOP的价值在于缩小范围，并将状态与行为分开。作用域越小，代码就越容易理解。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1862214|它可以在大多数语言中完成，实现这一切所需的就是状态将方法调用委托给行为的方式，以及行为进一步将调用委托给父行为的方式。|1862215|至于让一组类以一种有效的方式对一个领域进行建模，没有什么神奇的方法。就像钢琴一样，我们必须练习。OOP是一个抽象的工具，它可以帮助你以一种更简单的方式构建代码，但它不能为你思考和分析你的应用程序的域。|1862216|对我来说起作用的是尽可能长时间地保持与域的关系，同时仍然避免大多数代码重复。|1862217|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

To me, the value of OOP is to reduce the scope and to separate state from behavior. With smaller scope, code is easier to understand.

It can be done in most languages, all is needed to achieve this is a way for a state to delegate a method call to a behavior, and a way for a behavior to further delegate the call to a parent behavior.

As to have a set of classes model a domain in an effective way, there is no magic method. Like a piano, we have to practice. OOP is an abstract tool, it can help you build code in a simpler way, but it can't think and analyze the domain of your app for you.

What works for me is to stay close to the domain as long as possible, while still avoiding most code duplications.

blocks|key|1862231|text|我同意InSciTek+Jeff的观点。即使您不是在最纯粹的意义上使用OO，封装理论也可以帮助降低潜在的结构复杂性：http://www.edmundkirwan.com|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1862232|@+DrPizza|1862233|如果过程化编程在同样程度上利用了封装的好处，那就好了！|1862234|entityMap|0|LINK|mutability|MUTABLE|url|http://www.edmundkirwan.com/^0|1M|R|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

I agree with InSciTek Jeff. Even if you don't use OO in its purest sense, Encapsulation Theory can help reduce potential structural complexity:
<a href="http://www.edmundkirwan.com" rel="nofollow noreferrer">http://www.edmundkirwan.com</a>

@ DrPizza

If procedureal programming uses the benefits of encapsulation to the same degree then good on it!

blocks|key|2076145|text|OOP的要点是为程序员提供另一种方法来描述和传达代码中的问题的解决方案给机器和人。其中最重要的部分是与人的沟通。OOP允许程序员通过在OO语言中强制执行的规则来声明他们在代码中的含义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2076146|与这个主题上的许多争论相反，OOP和OO概念普遍存在于所有代码中，包括C等非OOP语言中的代码。许多高级非OO程序员甚至在非OO语言中也会近似对象的特征。|2076147|将OO内置于语言中只是给程序员提供了另一种表达方式。|2076148|编写代码的最大部分不是与机器的沟通，这部分很容易，最大的部分是与人类程序员的沟通。|2076149|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

blocks|key|1862380|text|对我来说，OOP语法本身有很大的价值。使用试图表示真实事物或数据结构的对象通常比尝试使用一组不同的平面(或“浮动”)函数对相同的数据执行相同的操作要有用得多。有一个自然的“流”到好的OOP的东西，只是更有意义的读，写，和长期维护。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1862381|发票并不是真正的“对象”，它可以自己执行功能--对象实例的存在只是为了在数据上执行功能，而不必知道数据实际上是什么类型的数据。可以成功调用函数"invoice.toJson()“，而不必知道"invoice”是什么类型的数据-结果将是Json，无论它来自数据库、XML、CSV，甚至是另一个JSON对象。对于过程函数，你突然不得不更多地了解你的数据，并最终得到"xmlToJson()“、"csvToJson()”、"dbToJson()“等函数。如果你改变底层数据类型，它最终会变得完全混乱和令人头疼。|1862382|OOP的要点是通过抽象它来隐藏实际的实现。要实现该目标，您必须创建一个公共接口。为了在创建公共接口时简化工作并保持干爽，您必须使用抽象类、继承、多态性和设计模式等概念。|1862383|因此，对我来说，OOP的真正压倒一切的目标是使未来的代码维护和更改变得更容易。但即便如此，如果以过程代码永远做不到的方式正确地处理，它确实可以大大简化事情。如果它与“真实世界”不匹配也没关系--用代码编程无论如何都不会与现实世界的对象交互。OOP只是一个让我的工作变得更容易更快的工具--我随时都会去做。|1862384|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

To me, there is a lot of value in the OOP syntax itself. Using objects that attempt to represent real things or data structures is often much more useful than trying to use a bunch of different flat (or "floating") functions to do the same thing with the same data. There is a certain natural "flow" to things with good OOP that just makes more sense to read, write, and maintain long term.

It doesn't necessarily matter that an Invoice isn't really an "object" with functions that it can perform itself - the object instance can exist just to perform functions on the data without having to know what type of data is actually there. The function "invoice.toJson()" can be called successfully without having to know what kind of data "invoice" is - the result will be Json, no matter it if comes from a database, XML, CSV, or even another JSON object. With procedural functions, you all the sudden have to know more about your data, and end up with functions like "xmlToJson()", "csvToJson()", "dbToJson()", etc. It eventually becomes a complete mess and a HUGE headache if you ever change the underlying data type.

The point of OOP is to hide the actual implementation by abstracting it away. To achieve that goal, you must create a public interface. To make your job easier while creating that public interface and keep things DRY, you must use concepts like abstract classes, inheritance, polymorphism, and design patterns.

So to me, the real overriding goal of OOP is to make future code maintenance and changes easier. But even beyond that, it can really simplify things a lot when done correctly in ways that procedural code never could. It doesn't matter if it doesn't match the "real world" - programming with code is not interacting with real world objects anyways. OOP is just a tool that makes my job easier and faster - I'll go for that any day.

blocks|key|1862415|text|OOP有助于将接口与实现分离。您不需要该语言中的OOP支持即可从OO设计中获益。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1862416|OOP提供了极大帮助的一个小例子：|1862417|UNIX+Virtual+File+System+(VFS)层使用函数指针表提供了一个统一的接口(打开/读/写)+--非常类似于C%2B%2B虚拟表分派。|1862418|无论客户端是在与本地文件系统、远程网络文件系统还是(目前)假文件系统(例如/proc)对话，它们都使用相同的调用集。|1862419|请参阅Sun的原始论文:+Vnodes:+Sun+UNIX中的多个文件系统类型的体系结构|1862420|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

OOP helps separate interface from implementation. You do not need OOP support in the language to benefit from OO design.

One small example where OOP has helped tremendously:

The UNIX Virtual File System (VFS) layer presents a uniform interface (open/read/write) using tables of function pointers -- much like the C++ virtual table dispatch. 

Clients use the same set of calls regardless of whether they are talking to a local file system, a remote Network File System (NFS) or (today) fake file systems (e.g. /proc).

See the original Sun paper: Vnodes: An Architecture for Multiple File System Types in Sun UNIX

blocks|key|2076184|text|十年后，我们还会对函数式编程说同样的话吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2076185|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Will we say the same things ten years from now about functional programming?

blocks|key|2076196|text|我不喜欢重用，也不喜欢可读性。后者意味着您的代码更容易更改。在构建软件的工艺中，仅此一项就价值不菲。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2076197|OO是让你的程序具有可读性的一种非常有效的方法。重用或不重用。|2076198|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|1862475|text|OOP的问题在于它被过度吹捧了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1862476|正如Alan+Kay最初设想的那样，它是先前拥有原始数据和全全局例程的很好的替代方案。|1862477|然后，一些管理顾问类型抓住它，并将其作为软件的救世主出售，旅鼠式的学术界和工业界紧随其后。|1862478|现在，在其他好的想法被过度吹捧之后，它们就像旅鼠一样翻滚。|1862479|那么我会做什么不同的事情呢？很多，我写了一本关于这方面的书。(这本书已经绝版了--我一分钱也没买到，但你还是可以买到的。)Amazon|offset|length|1862480|我的建设性答案是，不要将编程视为现实世界中建模的一种方式，而应将其视为编码需求的一种方式。|1862481|这是非常不同的，并且基于信息论(在任何人都能理解的水平上)。它说，编程可以看作是一个定义语言的过程，而这样做的技能对于好的编程是必不可少的。|1862482|它提升了领域特定语言(DSL)的概念。它与DRY非常一致(不要重复)。它对代码生成竖起了大拇指。其结果是，与现代应用程序的典型数据结构相比，软件的数据结构要少得多。|1862483|它试图重振这样一种观点，即前进的道路在于创造性，即使是被广泛接受的想法也应该受到质疑。|1862484|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0442017405^0|0|0|0|0|1P|6|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|14|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|15|8|@]|9|@$J|16|K|17|1|18]]|A|$]]|$1|L|3|M|5|6|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1A|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1B|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1C|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10]]]]

The problem with OOP is that it was oversold.

As Alan Kay originally conceived it, it was a great alternative to the prior practice of having raw data and all-global routines.

Then some management-consultant types latched onto it and sold it as the messiah of software, and lemming-like, academia and industry tumbled along after it.

Now they are lemming-like tumbling after other good ideas being oversold, such as functional programming.

So what would I do differently? Plenty, and I wrote a book on this. (It's out of print - I don't get a cent, but you can still get copies.)<a href="https://rads.stackoverflow.com/amzn/click/com/0442017405" rel="noreferrer" rel="nofollow noreferrer">Amazon</a>

My constructive answer is to look at programming not as a way of modeling things in the real world, but as a way of encoding requirements.

That is very different, and is based on information theory (at a level that anyone can understand). It says that programming can be looked at as a process of defining languages, and skill in doing so is essential for good programming.

It elevates the concept of domain-specific-languages (DSLs). It agrees emphatically with DRY (don't repeat yourself). It gives a big thumbs-up to code generation. It results in software with massively less data structure than is typical for modern applications.

It seeks to re-invigorate the idea that the way forward lies in inventiveness, and that even well-accepted ideas should be questioned.

blocks|key|2076265|text|现实世界不是“面向对象的”。现实世界在很大程度上并不是由合理的碎片构成的。相反，它是由混乱运动的粒子构成的。地球是一团颗粒汤。人们仍然可以看到鸟，树，天空，地面，森林，池塘。OO是关于程序组件的抽象。从根本上来说，把OO看作是对程序以外的其他东西进行建模是有缺陷的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2076266|所有的金钱和时间都没有让软件变得更好，因为它没有让程序员变得更聪明，也因为它没有改变人们对软件的看法。"OOP“在你使用的意义上，它是一个时髦的词，用来从笨蛋那里拿钱。是的，那些把钱花在“面向对象”教育和工具上的人都是笨蛋。容易上当受骗的人往往是笨蛋。|2076267|"OOP“的价值在于抽象和代码在同一个程序中的重用。OOP旨在与命令式程序一起使用。|2076268|如果你从汇编例程中爬起来。组装是由标签和指令组成的对的有序序列。汇编代码类似于“粒子汤”。现在，您可以转到子例程。子例程从该标签中选择一个标签:指令-soup，并将其余标签隐藏在子例程中。随着效果代码变得更加抽象，你的命名空间也变得更加简洁。|2076269|现在，如果你认为子程序做了什么.几十年前，人们认为子例程在处理参数时处于最佳状态。这使得他们为每个对象提供了自己的协议。协议将包含标签:procedure+-pairs。现在称为选择器:方法-pairs。过程不再直接绑定到其他过程，这解释了“后期绑定”-term。除了保留协议的历史(继承)之外，这形成了smalltalk中的“面向对象”。|2076270|您已经丧失了后期绑定机制的能力，并且忘记了继承意味着什么。而你却想知道你错过了什么。“OOP的价值在哪里，为什么所有的时间和金钱都没有让软件变得更好？”-我认为你把它们塞进了你的屁股里。当你尝试结肠镜检查时，你会发现它们。|2076271|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

The real world isn't "OO". The real world is not largely structured from sensible pieces. Instead it's made from chaotically moving particles. The earth is a particle soup. Still people see birds, trees, sky, ground, forests, ponds. OO is about abstraction of program components. It's fundamentally flawed to think about OO for modelling something else than programs.

All the money and time failed to make software any better, because it failed to make programmers smarter, also because it failed to change the way how people think about software. "OOP" in the sense you use it is a buzzword used to get the money out from
idiots. Yes, people who have put money on "OOP" education and tools are idiots. People who tend to fall on hoaxes tend to be idiots.

The value of "OOP" is the abstraction and the code reuse inside the same program. OOP is meant to be used with imperative programs.

If you get up from assembly routines. Assembly is an ordered sequences of pairs composed from labels and instructions. Assembly code is similar to the 'particle soup'. Now you can move to the subroutine. Subroutine picks a label from that label:instruction -soup, and hides the rest of labels inside the subroutine. As the effect code becomes more abstract and your namespace stays cleaner.

Now, if you think what subroutines do... Few of decades ago people were thinking that subroutines are at their best when they work on the arguments. That made them to give each object it's own protocol. Protocol would contain label:procedure -pairs. Now called selector:method -pairs. Procedures weren't bound directly to the other procedures anymore, explaining the 'late binding' -term. Along with keeping the history from the protocols (inheritance), this formed the 'object orientation' in the smalltalk.

You've been incapacitated the late binding mechanism and forgotten what inheritance means. And you yet wonder what you are missing there. "Where's the value of OOP, and why has all the time and money failed to make software any better?" - I think you stuffed them into your arse. When you attempt to colonoscopy you will find them.

blocks|key|2076292|text|首先，观察结果有些草率。我没有任何关于软件生产率的数据，也没有很好的理由相信它不会上升。此外，由于有许多人滥用OO，所以即使OO是继花生酱之后最伟大的东西，好的OO也不一定会带来生产力的提高。毕竟，一个不称职的脑外科医生可能会比没有更糟糕，但一个称职的脑外科医生可能是无价的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2076293|也就是说，OO是一种不同的安排方式，将过程代码附加到数据上，而不是让过程代码对数据进行操作。这本身至少应该是一个小的胜利，因为在某些情况下，OO方法更自然。毕竟，没有什么能阻止任何人用C%2B%2B编写过程应用程序接口，因此提供对象的选择使该语言更具通用性。|2076294|此外，OO还做得很好:它允许旧代码自动调用新代码，无需更改。如果我有程序管理的代码，并且我添加了一种新的东西，它类似于以前的东西，但不是完全相同的，我必须改变过程代码。在OO系统中，我继承了功能，更改了我喜欢的功能，由于多态，新代码会自动使用。这增加了更改的局部性，这是一件好事。|2076295|缺点是好的OO不是免费的:它需要时间和努力才能正确地学习它。因为它是一个主要的流行语，所以有很多人和产品只是为了做它而做得很糟糕。设计一个好的类接口并不比设计一个好的过程性API更容易，而且存在各种容易出错的错误(比如深层的类层次结构)。|2076296|可以把它看作是一种不同的工具，通常不一定更好。比如说，除了螺丝刀，还有锤子。也许我们最终会从软件工程的实践中解脱出来，因为我们知道用哪把扳手来敲螺丝。|2076297|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

In the first place, the observations are somewhat sloppy. I don't have any figures on software productivity, and have no good reason to believe it's not going up. Further, since there are many people who abuse OO, good use of OO would not necessarily cause a productivity improvement even if OO was the greatest thing since peanut butter. After all, an incompetent brain surgeon is likely to be worse than none at all, but a competent one can be invaluable.

That being said, OO is a different way of arranging things, attaching procedural code to data rather than having procedural code operate on data. This should be at least a small win by itself, since there are cases where the OO approach is more natural. There's nothing stopping anybody from writing a procedural API in C++, after all, and so the option of providing objects instead makes the language more versatile.

Further, there's something OO does very well: it allows old code to call new code automatically, with no changes. If I have code that manages things procedurally, and I add a new sort of thing that's similar but not identical to an earlier one, I have to change the procedural code. In an OO system, I inherit the functionality, change what I like, and the new code is automatically used due to polymorphism. This increases the locality of changes, and that is a Good Thing.

The downside is that good OO isn't free: it requires time and effort to learn it properly. Since it's a major buzzword, there's lots of people and products who do it badly, just for the sake of doing it. It's not easier to design a good class interface than a good procedural API, and there's all sorts of easy-to-make errors (like deep class hierarchies).

Think of it as a different sort of tool, not necessarily generally better. A hammer in addition to a screwdriver, say. Perhaps we will eventually get out of the practice of software engineering as knowing which wrench to use to hammer the screw in.

blocks|key|1862555|text|已经有很多关于这个问题的答案了，因为这是一个老帖子，但我想我应该插话。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1862556|您提到了“类分类”，这涉及到子类型和多态。这一切都围绕着继承，在它的全盛时期被认为是OOP的银弹。如今，继承和大型类层次结构实际上是不被鼓励的，即使是在做大量OOP的商店中也是如此。这是因为OOP的其他原则，如封装、松散耦合、内聚等等，已经被发现比继承更有用。我甚至可以说，松散耦合是OO的原因，而不是代码重用。代码重用通常发生在方法/函数级别。我有时会在不同的情况下重用类，但不是很频繁。不过，松散耦合在很大程度上有助于组织系统。每个对象都有自己的作用域，对象中的数据除了由访问器方法或属性之外，不能或不应该被操作，每个对象应该做一件简单的事情，并且应该通过简单的接口与其他对象通信。这几个原则有助于代码的可读性，有助于隔离错误，并防止您必须在许多不同的地方进行许多更改才能更改一件事。当对象没有紧密地交织在一起时，可以在不影响其他对象的情况下更改一个对象。这对我来说是一个巨大的好处。继承只是偶尔有用的。|1862557|代码重用仍然很重要，如果你正在复制、粘贴或重写相同的代码，即使是在普通的过程性、结构化或函数式编程中，这也是一种糟糕的做法。这实际上增加了成本，因为重复的工作，增加的维护和更多的bug。|1862558|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

There are already a lot of answers on this as this is an old post but i thought i'd chime in.

You mention "class taxonomy" a bit which gets into subtyping and polymorphism. This all revolves around inheritance which in it heyday was considered the silver bullet of OOP. Nowadays, inheritance and large class hierarchies are actually discouraged, even among shops that do a lot of OOP. This is because the other pricinples of OOP, such as encapsulation, loose coupling, cohesion and so forth have been found to be far more useful than inheritance. I would even go so far to say that loose coupling is the reason for OO, not code reuse. Code reuse usually happens at the method/function level. I do sometimes reuse classes under different circumstances, but not that often. Loose coupling though helps organize a system quite a bit. Each object has its own scope, the data in the object isn't or should not be manipulated except by accessor methods or properties, each object should do one simple thing and should talk to other objects thru simple interfaces. This handful of principles helps code readability, helps isolate bugs and prevent you from having to make many changes in lots of different places to change one thing. When objects are not closely intertwined, you can change one without affecting others. This has been a huge benefit to me. Inheritance is useful only now and then.

Code reuse is still important and if you are copying and pasting or rewriting the same code, thats a bad practice even under plain old procedural, structured or functional programming. That actually increases costs due to duplicated effort, increased maintenance and more bugs.

blocks|key|1862570|text|从我在20世纪80年代中期开始使用C/Unix+(非OOP)，然后在1990年转向C%2B%2B+(+OOP+)，然后在1996年左右进入Java语言(+OOP+)的经历中，我发现与我之前从事的大型非OOP程序相比，OOP可以极大地提高生产力、可维护性和健壮性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1862571|我观察到的主要情况是，在非OOP应用程序中，复杂性似乎随着应用程序的复杂程度呈指数级增长，而在OOP应用程序中，复杂性似乎与应用程序的复杂程度呈更高的线性关系。|1862572|换句话说，对于设计良好的OOP应用程序，你永远不会有“天哪，这个应用程序的源代码正在失去控制”的感觉，这是你在大型非OOP应用程序中得到的感觉。|1862573|作为一名OOP开发人员，我不能没有的其他事情是，我可以编写代码，对应用程序的问题域中存在的真实实体进行建模。对象有了自己的生命--远远超出了任何结构(C)或记录(Pascal)在过去糟糕的旧=]非OOP时代所做的事情。|1862574|唯一的要求是OOP项目的首席架构师必须知道他在做什么，他通常必须投入更多的思考时间来正确地设计，而不是实际实现它，但“提前思考”的回报确实令人惊叹。重用的机会，或者非常酷的设计优化，让你在办公室里挥舞着拳头，触地得分……好吧，对于办公室里的其他人来说，这可能看起来有点奇怪，但这种热情在非面向对象的日子里从未发生过:)|1862575|我见过一些写得很糟糕的OOP代码，也许这就是你所经历的，这可能会让你问这个问题。作为90年代中期的一名承包商，我经常发现已经有人开始了'OO‘设计，这些人知道什么是类，但仅此而已。这是一个非常痛苦的经历，我经常发现我在工作的头几个月需要用非常不同的“面向对象”的思维方式来教育团队。只有在每个人的大脑都被重新连接之后，我们才能作为一个团队继续创造一些令人惊叹的东西。|1862576|许多人发现“大脑重连”的过程太难、太痛苦或太费力，所以他们的一生都在OOP上消磨时间，所以你会发现有很多讨厌OO的人，但我对此感到高兴，因为正是这些人让我这样的人看起来很好：“什么，你可以为$X做这件事，它将在2个月内准备好，你将给我们一个可维护的代码库！哇，你今天就能开始吗？”|1862577|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

From my experience which started in C/Unix (non OOP) in the mid 1980s then moving onto C++ (OOP) in 1990 and then into Java around 1996 (OOP) I have found OOP to give a massive boost to productivity, maintainability and robustness compared with the large non OOP programs I was working on earlier.

The main thing I have observed is that in non OOP applications I have worked on the complexity seemed to grow at an exponential rate with respect to the sophistication of the application whereas in the OOP applications I worked on the complexity seemed to have a much more linear relationship with repect to the sophistication of the application.

In other words - with well designed OOP applications you never get that "OMG the source code for this app is getting waaaaay out of control" feeling that you get with large non OOP applications.

The other things I can't do without as an OOP developer is the way I can write code that models the real world entities that exist in the application's problem domain. Objects take on a life of their own - way beyond what any structs (C) or Records (Pascal) did back in the bad old =] non OOP days.

The one stipulation is that the chief architect of an OOP project must know what he's doing and he has to usually put more thinking time into getting the design right than in actually implementing it but the payback for 'thinking things through up front' is truly amazing. Opportunities for reuse or awesomely cool design optimizations come to light that have you punching the air and doing touchdowns in the office... ok, that might look a bit strange to the others in the office but that kind of enthusiasm never happened in the non OOP days :)

I've seen some pretty badly written OOP code and maybe that's what you've experienced which may have lead you to ask the question. As a contractor in the mid 90s I often found that the 'OO' design had already been started by someone who knew what a class was but not much more. It was a very painful experience and I often found that my first few months in a job involved educating the team in the very different way of 'OO' thinking. It was only after everyone's brain had been rewired that we could all proceed as a team to create something awesome.

Many people find the 'brain rewiring' process too hard, painful or just too much effort and so spend their life dissin' OOP and so you'll find a lot of OO haters out there but I'm happy about that because it's those people that make people like me look good: "What, you can do it for $X and it will be ready in 2 months and you will give us a maintainable code base!!! Wow, can you start today?"

blocks|key|2076327|text|现实世界可能不是面向对象的，但人们倾向于通过类比(抽象)而不是逻辑来学习或思考。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2076328|OOP不适用于计算机，但它适用于那些不善于在没有类比的情况下理解复杂系统的程序员。我相信OOP的主要目的是使用抽象更好地组织代码，因此程序员在不了解其他部分的情况下，可以很容易地理解系统的特定部分或整个系统在她/他想要的级别上所做的事情。|2076329|为了用抽象来组织代码，您还需要在您的语言中使用封装、继承和多态性。可靠的OOP原则和设计模式可以在这个组织中做得更好。但我认为OOP的全部要点都是抽象的，因为人类以这种方式思考得更好。|2076330|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Real world may not be OO but people tend to learn or think better with analogy (abstraction) rather than logic. 

OOP is not for computer but it's for programmer who is poor at figuring out a complex system without analogy. I believe main purpose of OOP is better organization of code using abstraction so without knowledge of other parts, a programmer can easily understand what specific part of or whole system does in a level she/he want to be in. 

To organize the code with abstraction, you will need encapsulation, inheritance, and polymorphism as well in your language. And SOLID OOP principles and design patterns come in to do better job at this organization. But I think whole point of OOP is abstraction because human thinks better in that way.

blocks|key|1862585|text|OOP是关于实例化的。您希望一次又一次地重新实例化同一事物，并对其活动进行稍微不同的分类。共享活动意味着共享类。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1862586|如果你不想以这种方式思考，那就不要做OOP。在pascal之后开始考虑它，这无疑是扭曲的想法，因此被激怒了的程序员。|1862587|你详细描述你的实例化机器人的每一个不同之处，而且你不会重复自己一次。|1862588|对于每个分类差异，您只有一个标签/类(不是每个不同的东西！)，这就是OOP的力量……这就是为什么它类似于人工智能的一些超级神经网络，它永远不会用完不同事物的名称，因为它依赖于总分布来命名它。|1862589|-Magnus+W.|1862590|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

OOP is about instancing... you want to reinstance the same thing over and over again, with a slightly different classification of its activity. shared activity means a shared class.

If you dont want to think in that way, dont do OOP. it definitely twists the mind to start thinking about it after say pascal, hence the pissed off programmers.

You detail your instancing robot to the every last difference, and you dont repeat yourself once.

You only have 1 label/class for every classification difference (not every different thing!), thats the power of OOP... and thats how its similar to some super nueral network for ai, that never runs out of names for different things, because it relies apon the total distribution, to name it.

-Magnus W.

As far as I can tell, in spite of the countless millions or billions spent on OOP education, languages, and tools, OOP has not improved developer productivity or software reliability, nor has it reduced development costs. Few people use OOP in any rigorous sense (few people adhere to or understand principles such as LSP); there seems to be little uniformity or consistency to the approaches that people take to modelling problem domains. All too often, the class is used simply for its syntactic sugar; it puts the functions for a record type into their own little namespace.

I've written a large amount of code for a wide variety of applications. Although there have been places where true substitutable subtyping played a valuable role in the application, these have been pretty exceptional. In general, though much lip service is given to talk of "re-use" the reality is that unless a piece of code does exactly what you want it to do, there's very little cost-effective "re-use". It's extremely hard to design classes to be extensible in the right way, and so the cost of extension is normally so great that "re-use" simply isn't worthwhile.

In many regards, this doesn't surprise me. The real world isn't "OO", and the idea implicit in OO--that we can model things with some class taxonomy--seems to me very fundamentally flawed (I can sit on a table, a tree stump, a car bonnet, someone's lap--but not one of those is-a chair). Even if we move to more abstract domains, OO modelling is often difficult, counterintuitive, and ultimately unhelpful (consider the classic examples of circles/ellipses or squares/rectangles).

So what am I missing here? Where's the value of OOP, and why has all the time and money failed to make software any better?

What's the point of OOP?

人工智能

软件工程

数据结构

文件系统

数据库

编译器

Windows

JSON

Java

Unix

据我所知，尽管在OOP教育、语言和工具上花费了无数百万或数十亿，但OOP并没有提高开发人员的生产力或软件可靠性，也没有降低开发成本。很少有人严格意义上使用OOP (很少有人坚持或理解诸如LSP之类的原则)；人们建模问题域的方法似乎几乎没有一致性或一致性。通常，该类只是用作语法糖；它将记录类型的函数放入它们自己的小名称空...

问OOP的意义何在？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OOP的意义何在？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OOP的意义何在？
EN