Programming in the 1960s had a big problem: computers weren’t that powerful yet, and somehow they needed to split the capacities between data structures and procedures.

1960年代的编程存在一个大问题：计算机还没有那么强大，并且它们需要以某种方式在数据结构和过程之间分配容量。

This meant that if you had a large set of data, you couldn’t do that much with it without pushing a computer to its limits. On the other hand, if you needed to do a lot of things, you couldn’t use too much data or the computer would take forever.

这意味着，如果您拥有大量数据，那么在不将计算机推向极限的情况下，您将无法进行大量处理。 另一方面，如果您需要做很多事情，则不能使用过多的数据，否则计算机将永远占用时间。

Then Alan Kay came around in 1966 or 1967 and theorized that one could use encapsulated mini-computers that didn’t share their data, but rather communicated through messaging. This way, compute resources could be used much more economically.

然后，艾伦·凯(Alan Kay)在1966年或1967年出现，并得出理论认为可以使用封装的微型计算机，这些微型计算机不共享数据，而是通过消息传递进行通信。 这样，可以更加经济地使用计算资源。

Despite the ingenuity of the idea, it would take until 1981 until object-oriented programming hit the mainstream. Since then, however, it hasn’t stopped attracting new and seasoned software developers alike. The market for object-oriented programmers is as busy as ever.

尽管这个想法很巧妙，但直到1981年，面向对象编程才成为主流。 从那时起，它就一直没有停止吸引新的和经验丰富的软件开发人员。 面向对象的程序员市场一如既往的繁忙。

But in recent years, the decade-old paradigm has received more and more criticism. Could it be that, four decades after object-oriented programming hit the masses, technology is outgrowing this paradigm?

但是，近年来，这个有着十年历史的范式受到越来越多的批评。 难道是在面向对象程序设计大行其道40年之后，技术已经超越了这种范式？

函数与愚蠢的数据耦合吗？ (Is coupling functions with data that stupid?)

The main idea behind object-oriented programming is as simple as can be: you try to break a program in parts that are as powerful as the whole. It follows that you couple pieces of data and those functions that only get used on the data in question.

面向对象编程的主要思想非常简单：尝试将程序分解为功能强大的整体。 随之而来的是，您将数据片段和仅在有关数据上使用的那些功能耦合在一起。

Note that this only covers the notion of encapsulation, that is, data and functions that sit inside an object are invisible to the outside. One can only interact with the contents of an object through messages, typically called getter and setter functions.

请注意，这仅涵盖封装的概念，也就是说，位于对象内部的数据和功能对于外部是不可见的。 一个人只能通过消息(通常称为getter和setter函数)与对象的内容进行交互。

What is not contained in the initial idea, but is considered essential to object-oriented programming today, are inheritance and polymorphism. Inheritance basically means that developers can define subclasses that have all the properties that their parent class has. This wasn’t introduced to object-oriented programming until 1976, a decade after its conception.

继承和多态性并没有包含在最初的想法中，但是对于当今的面向对象编程而言，这是必需的。 继承基本上意味着开发人员可以定义具有其父类具有的所有属性的子类。 直到1976年，即面向对象程序设计的十年之后，才将其引入。

Polymorphism came to object-oriented programming another decade later. In basic terms, it means that a method or an object can serve as a template for others. In a sense it’s a generalization of inheritance, because not all properties of the original method or object need to be transmitted to the new entity; instead, you can choose to override properties.

十年后，多态性进入了面向对象的程序设计。 从根本上讲，这意味着方法或对象可以用作其他方法的模板。 从某种意义上讲，这是继承的概括，因为并非原始方法或对象的所有属性都需要传输到新实体。 相反，您可以选择覆盖属性。

What’s special about polymorphism is that even if two entities depend on each other in the source code, a called entity works more like a plugin. This makes life easier for developers because they don’t have to worry about dependencies at runtime.

多态性的特殊之处在于，即使两个实体在源代码中相互依赖，被调用实体的工作方式也更像插件。 这使开发人员的生活更加轻松，因为他们不必担心运行时的依赖关系。

It’s worth mentioning that inheritance and polymorphism aren’t exclusive to object-oriented programming. The real differentiator is encapsulating pieces of data and the methods that belong to them. In a time where compute resources were a lot scarcer than today, this was a genius idea.

值得一提的是，继承和多态性并不是面向对象编程所独有的。 真正的区别在于封装数据及其所属的方法。 在计算资源比今天稀缺得多的时代，这是一个天才的想法。

面向对象编程中的五个大问题(The five big problems in object-oriented programming)

Once object-oriented programming hit the masses, it transformed the way developers see code. What prevailed before the 1980s, procedural programming, was very machine-oriented. Developers needed to know quite a bit about how computers work to write good code.

面向对象程序设计一经问世，便改变了开发人员查看代码的方式。 在1980年代以前，过程编程非常面向机器。 开发人员需要非常了解计算机如何工作才能编写好的代码。

By encapsulating data and methods, object-oriented programming made software development more human-centered. It matches human intuition that the method drive() belongs to the data group car, but not to the group teddybear.

通过封装数据和方法，面向对象的编程使软件开发更加以人为中心。 符合人类的直觉，方法drive()属于数据组car ，但不属于teddybear组。

When inheritance came around, that was intuitive, too. It makes perfect sense that Hyundai is a subgroup of car and shares the same properties, but PooTheBear does not.

当继承产生时，这也很直观。 它的意义是Hyundai是的子群car ，并分享相同的属性，但PooTheBear没有。

This sounds like a powerful machinery. The problem, however, is that programmers who only know object-oriented code will force this way of thinking on everything they do. It’s like when people see nails everywhere because all they have is a hammer. As we will see below, when your toolbox contains only a hammer, that can lead to fatal problems.

这听起来像是一台强大的机器。 但是，问题在于，只知道面向对象代码的程序员将迫使这种方式思考他们所做的一切。 就像人们到处看到钉子一样，因为他们只有锤子。 正如我们将在下面看到的那样，当您的工具箱中仅包含锤子时，这可能会导致致命的问题。

香蕉大猩猩丛林问题 (The banana gorilla jungle problem)

Imagine you’re setting up a new program, and you’re thinking about designing a new class. Then you think back to a neat little class that you’ve created for another project, and you realize that it would be perfect for what you’re currently trying to do.

想象一下，您正在设置一个新程序，并且正在考虑设计一个新类。 然后，您回想起为另一个项目创建的简洁的小类，您意识到这对您当前正在尝试的工作是完美的。

No problem! You can reuse the class from the old project for your new one.

没问题！ 您可以将旧项目中的类重用于新项目。

Except for the fact that this class may actually be a subclass of another class, so now you need to include the parent class too. Then you realize that the parent class depends on other classes as well, and you end up including heaps of code.

除了该类实际上可能是另一个类的子类之外，因此现在您还需要包括父类。 然后您意识到父类也依赖于其他类，并且最终包含了代码堆。

The creator of Erlang, Joe Armstrong, famously proclaimed:

Erlang的创建者Joe Armstrong著名地宣称：

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

面向对象语言的问题在于，它们具有随身携带的所有隐式环境。 您想要香蕉，但是得到的是一只大猩猩，拿着香蕉和整个丛林。

That pretty much says it all. It’s fine to reuse classes; in fact, it can be a major virtue of object-oriented programming.

这几乎说明了一切。 可以重用类。 实际上，这可能是面向对象编程的主要优点。

But don’t take it to the extreme. Sometimes you’re better off writing a new class instead of including masses of dependencies for the sake of DRY (don’t repeat yourself).

但是不要把它极端化。 有时您最好编写一个新类，而不是为了DRY而添加大量依赖项(不要重复自己)。

脆弱的基层问题(The fragile base class problem)

Imagine you’ve successfully reused a class from another project for your new code. What happens if the base class changes?

想象一下，您已经成功地将另一个项目中的类重用于新代码。 如果基类发生变化会怎样？

It can corrupt your entire code. You might not even have touched it. But one day your project works like a charm, the next day it doesn’t because somebody changed a minor detail in the base class that ends up being crucial for your project.

它可能会破坏您的整个代码。 您甚至可能都没有碰过它。 但是有一天，您的项目就像一个魅力，而第二天却不是，因为有人更改了基类中的一个细微细节，最终对您的项目至关重要。

The more you use inheritance, the more maintenance you potentially have to do. So even though reusing code seems very efficient in the short term, it can get costly in the long run.

使用继承的次数越多，潜在的维护工作就越多。 因此，即使在短期内重用代码似乎非常有效，但从长远来看，它可能会变得昂贵。

钻石问题 (The diamond problem)

Inheritance is this cute little thing where we can take properties of one class and transfer it to others. But what if you want to mix the properties of two different classes?

继承是一件可爱的小事，我们可以在其中继承一类的属性并将其转移给其他类。 但是，如果要混合两个不同类的属性怎么办？

Well, you can’t do it. At least not in an elegant way. Consider for example the class Copier. (I borrowed this example, as well as some info about the problems presented here, from Charles Scalfani’s viral story Goodbye, Object Oriented Programming.) A copier scans the content of a document and prints it on an empty sheet. So should it be the subclass of Scanner, or of Printer?

好吧，你做不到。 至少不是优雅的方式。 例如考虑类Copier 。 (我从Charles Scalfani的病毒故事《再见，面向对象的编程》中借用了这个示例以及有关此处出现的问题的一些信息。)复印机扫描文档的内容并将其打印在空白纸上。 那么它应该是Scanner还是Printer的子类？

There simply is no good answer. And even though this problem isn’t going to break your code, it comes up often enough to be frustrating.

根本没有好的答案。 即使这个问题不会破坏您的代码，但它经常会令人沮丧。

等级问题 (The hierarchy problem)

In the diamond problem, the question was which class Copier is a subclass of. But I lied to you — there is a neat solution. Let Copier be the parent class, and Scanner and Printer be subclasses that only inherit a subset of the properties. Problem fixed!

在钻石问题中，问题是Copier属于哪个类别。 但我对您撒谎-有一个灵巧的解决方案。 假设Copier为父类，而Scanner和Printer为仅继承属性子集的子类。 问题已解决！

That’s neat. But what if your Copier is only black-and-white, and your Printer can handle color, too? Isn’t Printer in that sense a generalization of Copier? What if Printer is connected to WiFi, but Copier is not?

那很整齐。 但是，如果您的Copier只是黑白的，并且Printer也可以处理彩色怎么办？ 从这个意义上说， Printer不是Copier的概括吗？ 如果Printer连接到WiFi但Copier没有连接怎么办？

The more properties you heap on a class, the more difficult it becomes to establish proper hierarchies. Really, you’re dealing with clusters of properties, where Copier shares some, but not all properties of Printer, and vice versa. And if you try to stick that into hierarchies, and you have a big complex project, this might lead you to a messy disaster.

您在类上堆积的属性越多，建立适当的层次结构就越困难。 确实，您正在处理属性集群，其中Copier共享了Printer一些但不是全部属性，反之亦然。 而且，如果您尝试将其置于层次结构中，并且您有一个大型复杂项目，则可能会导致混乱。

参考问题(The reference problem)

You might say, alright, then we’ll just do object-oriented programming without hierarchies. Instead, we could use clusters of properties, and inherit, extend, or override properties as needed. Sure, that would be a bit messy, but it would be an accurate representation of the problem at hand.

您可能会说，好吧，那么我们将进行没有层次结构的面向对象编程。 相反，我们可以使用属性集群，并根据需要继承，扩展或覆盖属性。 当然，这有点混乱，但这将是对当前问题的准确表示。

There’s just one problem. The whole point of encapsulation is to keep pieces of data safe from one another and thus make computing more efficient. This doesn’t work without strict hierarchies.

只有一个问题。 封装的全部目的是使数据片段彼此之间保持安全，从而使计算效率更高。 没有严格的层次结构，这是行不通的。

Consider what happens if an object A overrides the hierarchy by interacting with another object B. It doesn’t matter what relationship A has with B, except that B is not the direct parent class. Then A must contain a private reference to B, because otherwise, it couldn’t interact.

考虑如果对象A通过与另一个对象B交互来覆盖层次结构，会发生什么情况。 A与B之间的关系并不重要，只是B不是直接的父类。 然后， A必须包含对B的私有引用，因为否则，它将无法交互。

But if A contains the information that the children of B also have, then that information can be modified in multiple places. Therefore, the information about B isn’t safe anymore, and encapsulation is broken.

但是，如果A包含B的子代也具有的信息，则可以在多个位置修改该信息。 因此，有关B的信息不再安全，并且封装被破坏。

Although many object-oriented programmers build programs with this kind of architecture, this isn’t object-oriented programming. It’s just a mess.

尽管许多面向对象的程序员都使用这种架构来构建程序，但这并不是面向对象的编程。 只是一团糟。

单一范式的危险 (The danger of the single paradigm)

What these five problems have in common is that they implement inheritance where it’s not the best solution. Since inheritance wasn’t even included in the original form of object-oriented programming, I wouldn’t call these problems inherent to object orientation. They’re just examples of a dogma taken too far.

这五个问题的共同点是它们在不是最佳解决方案的地方实现了继承。 由于继承甚至没有包含在面向对象编程的原始形式中，因此我不会将这些问题称为面向对象固有的问题。 它们只是教条太过远的例子。

Not only object-oriented programming can be overdone, though. In pure functional programming, it’s extremely difficult to process user input or print messages on a screen. Object-oriented or procedural programming is much better for these purposes.

但是，不仅面向对象的编程可能会被夸大。 在纯函数式编程中，处理用户输入或在屏幕上打印消息非常困难。 出于这些目的，面向对象或过程编程要好得多。

Still, there are developers who try to implement these things as pure functions and blow their code up to dozens of lines that nobody can understand. Using another paradigm, they could have easily reduced their code to a couple of readable lines.

仍然有一些开发人员尝试将这些东西实现为纯函数，并将其代码分解为数十行，没人能理解。 使用另一个范例，他们可以轻松地将代码简化为几行可读的代码。

Paradigms are a bit like religions. They’re good in moderation — arguably, Jesus, Mohamed and Buddha said some pretty cool stuff. But if you follow them to the last little detail, you might end up making the lives of yourself and of people around you quite miserable.

范式有点像宗教。 他们的节制性很好-可以说耶稣，穆罕默德和佛陀说了一些很酷的话。 但是，如果您遵循它们的最后一个细节，您可能最终会使自己和周围人的生活变得十分痛苦。

The same goes for programming paradigms. There’s no doubt that functional programming is gaining traction, whereas object-oriented programming has attracted some harsh criticism in the last few years.

编程范例也是如此。 毫无疑问，函数式编程正获得越来越多的关注，而在过去的几年中，面向对象的编程引起了一些严厉的批评。

It makes sense to get informed about new programming paradigms and use them when appropriate. If object-oriented programming is the hammer that makes developers see nails wherever they go, is that a reason to throw the hammer out the window? No. You add a screwdriver to your toolbox, and maybe a knife or a pair of scissors, and you choose your tool based on the problem at hand.

了解新的编程范例并在适当的时候使用它们是有意义的。 如果面向对象编程是使开发人员无论走到哪里都能看到钉子的锤子，那是把锤子扔出窗户的原因吗？ 否。您在工具箱中添加了一把螺丝刀，也许是一把刀或一把剪刀，然后根据当前问题选择了工具。

Functional and object-oriented programmers alike, stop treating your paradigms like a religion. They’re tools, and they all have their use somewhere. What you use should only depend on what problems you are solving.

功能和面向对象的程序员都不要像对待宗教那样对待您的范例。 它们是工具，它们都可以在某个地方使用。 您使用的内容仅取决于您要解决的问题。

一个大问题：我们正处于一场新革命的风口浪尖上吗？ (The big question: are we on the cusp of a new revolution?)

At the end of the day, the — admittedly rather heated — debate of functional versus object-oriented programming boils down to this: could we be reaching the end of the era of object-oriented programming?

归根结底，关于功能性编程和面向对象编程的争论(公认地相当激烈)可以归结为这一点：我们是否可以迈入面向对象编程时代的尽头？

More and more problems are coming up where functional programming is often the more efficient option. Think data analysis, machine learning, and parallel programming. The more you get into those fields, the more you’ll love functional programming.

功能编程通常是更有效的选择，越来越多的问题出现。 考虑数据分析，机器学习和并行编程。 您对这些领域的投入越多，您就会越喜欢函数式编程。

But if you look at the status quo, there are a dozen offers for object-oriented programmers to one offer for functional coders. That doesn’t mean you won’t get a job if you prefer the latter; functional developers are still pretty scarce these days.

但是，如果您看一下现状，那么有十二种面向对象程序员的报价，另一种是针对功能编码员的报价。 这并不意味着如果您喜欢这份工作就不会找到工作。 如今，功能开发人员仍然非常稀缺。

The most likely scenario is that object-oriented programming will stay around for another decade or so. Sure, the avant-garde is functional, but that doesn’t mean you should ditch object-oriented yet. It’s still incredibly good to have in your repertoire.

最有可能的情况是，面向对象的编程将继续存在十年左右。 当然，前卫是实用的，但这并不意味着您应该放弃面向对象。 拥有所有曲目仍然非常好。

So don’t throw object-oriented programming out of your toolbox in the next few years. But make sure that it’s not the only tool you have.

因此，在接下来的几年中，不要将面向对象的编程丢到工具箱之外。 但是请确保它不是您拥有的唯一工具。