匿名方法/函数：基本特征还是违反了 OO 原则？
Perl 和 C# 等主流语言最近向匿名方法/函数的发展是重要的事情，还是违反 OO 原则的奇怪功能？
最近的库（例如 Intel 的 Thread Building Blocks 的最新版本以及 Microsoft 的 PPL 和 Linq）依赖于这些东西是好事还是坏事？
目前拒绝匿名方法/函数的语言（例如 Java）是否做出了坚持纯 OO 模型的明智选择，或者它们是否因缺乏基本的编程功能而落后了？
Is the recent movement towards anonymous methods/functions by mainstream languages like perl and C# something important, or a weird feature that violates OO principles?
Are recent libraries like the most recent version of Intel's Thread Building Blocks and Microsofts PPL and Linq that depend on such things a good thing, or not?
Are languages that currently reject anonymous methods/functions, like Java, making wise choices in sticking with a purely OO model, or are they falling behind by lacking a fundamental programming feature?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
lambda 表达式与 LINQ 等流畅 API 相结合的表达能力远远超过任何明显违反纯 OO 原则的行为。
The expressive power of lambda expressions combined with fluent APIs like LINQ far outweigh any perceived violation of pure OO principles.
面向对象是一种设计哲学，而不是一套刻在石碑上的戒律。
由于 lambda 函数使语言的能力/表达能力成倍增加，仅仅因为“它违反了纯粹的面向对象模型”而拒绝它们是相当弄巧成拙的：总体目标是设计好的软件，而不是设计面向对象的代码。
另外，我不太确定正确编写的 lambda 函数本身是否“违反了 OO 模型”。更像是在模型之外。
Object Orientation is a design philosophy, not a set of commandments on stone tablets.
Since lambda functions increase the power/expressiveness of the language many-fold, refusing them merely on "it violates pure OO model" is rather self-defeating: the overall goal is to design good software, NOT to design OO code.
Plus, I'm not quite certain that correctly written lambda functions "violate OO model" per se. More like are outside of the model.
无论如何，没有固有地违反 OO 原则.. 我不认为...
封装、继承和多态性是规范列表，AM 与这三个中的任何一个都不不一致...它们是一种方法，而不是类型...因此，就像方法委托的完整 .Net 1.1 表示一样，它们可以编写为使用或滥用三个 OO 原则中的任何一个。
No inherent violation of OO pronciples anyway.. Not that I can see...
Encapsulation, Inheritence and Polymorphism being the canonical list, AM are not inconsistent with any of the three... They are a method, not a Type... So just like a full .Net 1.1 representation of a Method Delegate, they can be written to use or abuse any of the three OO principles.
C# 一直都有委托；它总是有事件处理。 CLR 2.0（和 C# 2.0）引入了匿名委托的概念，以满足任何 OO 技术中的设计模式都可以解决的各种需求。他们刚刚正式宣布函数是这些技术中的“一流对象”。
我敢说，像 C# 这样的技术中函数功能和对象功能的混合已经变得非常有用，以至于很难想象在没有两者优点的情况下编写应用程序。
C# has always had delegates; its always had event handling. The CLR 2.0 (and C# 2.0) introduced the concept of anonymous delegates to meet a variety of needs that could probably have been solved with design patterns in any OO technology. They've just made it official that functions are "first-class objects" in these technologies.
I dare say that the mixture of functional and object features in a technology like C# has become so useful that its hard to imagine writing applications without the benefits of both worlds.
Java 并没有“坚持纯粹的 OO 模型”，而是出于原则。 Java 社区对于该语言的功能添加应该是什么样子或者它们是否值得增加语法的复杂性无法达成一致。根据詹姆斯·高斯林的说法：
（摘自“了解闭包争论” ，这是对去年夏天 Java 社区中函数式编程争论现状的一个很好的概述，目前看来大家都在押注它。）
Java's not "sticking with a purely OO model" out of principle; the Java community just can't agree on what functional additions to the language should look like or whether they're worth the additional complexity in the syntax. According to James Gosling:
(From "Understanding the closures debate", which is a pretty good overview of the state of the functional programming debate in the Java community as of last summer. The consensus seems to have been to punt on it for now.)
Python 一直都有它们。
函数是一类具有非常狭窄的接口且属性不多的对象。
Python 函数对象有许多内置属性，如果需要，您可以随时添加更多属性。
Python has always had them.
A function is a class of objects with a really narrow interface and not many attributes.
Python function objects have a number of built-in attributes, and you can always add more if you want.
回调是面向对象的基本部分。对单方法回调对象的常见情况提供良好的语法支持是很有意义的。具体如何实施则是另一回事。
Callbacks are a fundamental part of OO. It rather makes sense to have good syntactical support for the common case of a single-method callback object. Exactly how that is implemented is another matter.
它如何违反面向对象原则？
它并不违反封装性：类仍然完全控制哪些函数可以访问其私有成员。
它也不干扰继承或多态性。
只有当你是一名 Java 程序员并将“OO 原则”定义为“可以在 Java 中实现”时，它才会违反 OO 原则
。幸运的是，Java 世界之外没有人使用过这样的 OOP 定义。
可以说它违反了Java 的哲学，我认为这是一件好事，因为 Java 的哲学本质上是“从 OOP 的破碎和损坏的版本开始，并留在那里，而不用任何方式添加或发展它。”有意义的方式”。这不是一个值得保持完整的哲学。
但它并不违反 OOP 的原则。
How would it violate OO principles?
It doesn't violate encapsulation: A class is still in full control of which functions get access to its private members.
It doesn't interfere with inheritance or polymorphism either.
It only violates OO principles if you're a Java programmer and define "OO principles as "can be implemented in Java"
Luckily, no one outside the world of Java, have ever used such a definition of OOP.
It may be said to violate Java's philosophy, which I'd say is a good thing, because Java's philosophy is essentially "start with a broken and mangled version of OOP, and stay there, without ever adding to it or evolving it in any meaningful way". That's not a philosophy that deserves to stay unbroken.
But it doesn't violate the principles of OOP.