c# - 匿名方法/功能：基本特征还是违反 OO 原则？

Question

最近 perl 和 C# 等主流语言对匿名方法/函数的发展是重要的，还是违反 OO 原则的奇怪特性？

最近的库，比如英特尔的线程构建模块的最新版本以及微软的 PPL 和 Linq 依赖于这些东西是一件好事，还是不是？

当前拒绝匿名方法/函数的语言，如 Java，是在坚持纯粹的 OO 模型方面做出明智的选择，还是因为缺乏基本的编程特性而落后？

score 18 · Accepted Answer

lambda 表达式与 LINQ 等流畅的 API 相结合的表达能力远远超过任何明显违反纯 OO 原则的行为。

score 13 · Accepted Answer

面向对象是一种设计理念，而不是石碑上的一套戒律。

由于 lambda 函数成倍地增加了语言的能力/表现力，仅仅因为“它违反了纯 OO 模型”而拒绝它们是相当自欺欺人的：总体目标是设计好的软件，而不是设计 OO 代码。

另外，我不太确定正确编写的 lambda 函数本身“违反了 OO 模型”。更像是在模型之外。

score 3 · Accepted Answer

无论如何都没有违反面向对象的原则。我看不到...

封装、继承和多态是规范列表，AM 与这三者中的任何一个都不矛盾......它们是方法，而不是类型......所以就像方法委托的完整 .Net 1.1 表示一样，它们可以是编写为使用或滥用三个 OO 原则中的任何一个。

score 1 · Accepted Answer

C# 一直都有委托；它总是有事件处理。CLR 2.0（和 C# 2.0）引入了匿名委托的概念，以满足各种需求，这些需求可能已经通过任何 OO 技术中的设计模式来解决。他们刚刚正式宣布函数是这些技术中的“一流对象”。

我敢说，像 C# 这样的技术中功能和对象特性的混合已经变得如此有用，以至于很难想象编写应用程序时没有这两个世界的好处。

score 1 · Accepted Answer

Java 并没有“坚持纯粹的 OO 模型”。Java 社区只是无法就该语言的功能添加应该是什么样子或者它们是否值得语法中的额外复杂性达成一致。根据詹姆斯·高斯林的说法：

闭包最初被排除在 Java 之外更多是因为时间压力。在 Java 的早期，缺少闭包非常痛苦，因此内部类诞生了：这是一种令人不安的折衷方案，它试图避免一些棘手的问题。但在许多设计问题中很正常，简化并没有真正解决任何问题，他们只是移动了它们。

（来自“理解闭包辩论”，这是对截至去年夏天 Java 社区中函数式编程辩论状态的一个很好的概述。目前的共识似乎是对它进行抨击。）

score 0 · Accepted Answer

Python 一直都有它们。

函数是一类具有非常窄的接口且属性不多的对象。

Python 函数对象具有许多内置属性，如果需要，您可以随时添加更多属性。

score 0 · Accepted Answer

回调是 OO 的基本组成部分。为单方法回调对象的常见情况提供良好的语法支持是很有意义的。具体如何实施是另一回事。

score 0 · Accepted Answer

它将如何违反 OO 原则？

它不违反封装：一个类仍然可以完全控制哪些函数可以访问它的私有成员。

它也不干扰继承或多态性。

仅当您是 Java 程序员并将“OO 原则定义为“可以用 Java 实现”时才违反 OO 原则

幸运的是，Java 世界之外没有人使用过这样的 OOP 定义。

可以说它违反了 Java 的哲学，我会说这是一件好事，因为 Java 的哲学本质上是“从 OOP 的一个损坏和损坏的版本开始，然后一直呆在那里，没有添加它或以任何有意义的方式发展它方式”。这不是一个应该保持不变的哲学。

但这并不违反 OOP 的原则。

8 回答 8