用代码来说明，为什么需要面向扩展的设计

在基本的面向对象编程中，你只能直接调用一个类的方法，而这些方法是由这个类的作者定义的，这对于面向用户设计的类来说是没有问题的。此外，在 20 - 30 年前，在大型标准库和开源库被大量复用之前，大部分代码通常是跟自己的代码中的类来一起工作的 —— 也就是你自己的团队或公司维护的代码。然而，在现代代码世界中，我们经常会使用其他人编写的类。

业务逻辑通常大量使用包括字符串和集合等标准库功能、以及第三方库中的一些类，我们受到这些类提供的操作的限制。例如，当我们需要用破折号替换字符串中的空格时，我们会这样编写代码：

string.replace(' ', '-')

但是当我们需要将左边的字符串对齐到指定的长度时，我们可能没有现成的方法可用，在这些旧的语言（如 Objective-C、C++、Java 或 JS）中，你需要强制写成这种形式：

leftPad(string, ' ', length)

这个 leftPad 可能来自一个单独的库¹，也可能来自第三方的工具函数集合（比如 Apache Commons），或者在你自己的项目中自行编写。总之，它的调用看起来和字符串类上的内置方法是非常不同的。

为什么会有这样的问题呢？我引用 Java 的作者之一 Guy Steele，他在 1998 年的《成长的语言》论文²中的一段话。

在大多数语言中，用户至少可以定义一些新语法来代表另外一段代码，然后可以很方便地调用这些代码，这种方式可以让新语法看起来像原生调用一样。通过这种方式，用户可以构建一个更大的语言来满足他的需求。

Guy Steele, Growing a Language

他是在批评 APL 缺乏这样的设施，但同样的批评也适用于现代环境下的旧的面向对象语言。你被困在一个类的操作词汇表上，而这个词汇表是原始库的设计者们所设想的，它不能由你来扩展。此外，它也没法被广泛使用的库的维护者随意地扩展，再次引用同一篇论文中的内容作为原因。

编程词汇的一部分适合所有程序员使用，但其他部分仅适合少数几个人。程序员需要了解学习其所有词汇用法，这并不公平。

现代语言（如 C#、Scala、Rust、Kotlin 和 Swift）通过支持扩展方法解决了这个问题。你可以在不是你控制的类中添加特定领域的扩展方法，这样，你自己的函数可以用类似于内置方法来调用，而你的代码仍然可以像散文一样，流畅的按从左到右的顺序阅读。

string.padLeft(' ', length)

这个 padLeft 扩展可以在任何地方定义，它是一个很好的编程语言进化的故事。但是，它的意义还不止于此。

一旦一种编程语言支持扩展函数，它就改变了经典面向对象的 API 设计方法。这对于一个从 Java 这样的旧语言，切换到 Kotlin 这样的现代语言的程序员来说，是一个不小的启示，因为扩展函数通常只是作为方便的语法糖³呈现出来。我们还是先看一个带有一堆属性（或 getter 方法）的接口。

interface Obscure {val foo: Intval bar: Intval sum: Intval max: Intval min: Int
}

它和你在一个典型的商业应用程序中找到的接口或类并无大的区别 —— 有一堆属性和方法。

你能快速掌握这个接口代表了一个什么样的实体吗？它的状态空间是由哪些属性构成的？如果没有额外的文档，要弄清楚这一点并不容易。但是，让我们把这个接口重构成一个核心实体和方便的扩展函数。

interface NotObscure {val foo: Intval bar: Int
}val NotObscure.sum: Int
val NotObscure.max: Int
val NotObscure.min: Int

现在，很明显，这个接口的核心功能是由两个整数属性 foo 和 bar 组成的，而其余的 sum、max 和 min 属性只是为了方便起见而提供的，并在这些核心属性的基础上进行计算。不需要再明确地写文档描述这种区别了 —— 从代码的结构中就可以直接看出。

这种面向扩展的设计在 Kotlin 标准库和第三方库中得到了广泛的应用。它是一种强大的设计技术，使用它会有非常好的效果。

这种设计方法有一个副作用。你可能会注意到，Kotlin 代码通常会使用通配符 import，比如 import com.examplease.*。这在 Kotlin 中很方便，因为在 Kotlin 中仅导入一个类是非常少见的。所有有用的、方便的、实用的函数通常都定义在同一个包中，但在类外作为扩展函数定义。

文中链接：

https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript, Chris Williams, 2016
https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf Growing a Language, Guy Steele, 1998
https://kotlinlang.org/docs/reference/extensions.html Extensions in Kotlin Programming Language

英文原文：

https://medium.com/@elizarov/extension-oriented-design-13f4f27deaee

用代码来说明，为什么需要面向扩展的设计相关推荐

基于FPGA的CAN通信，FPGA驱动SJA1000T芯片代码，实现标准帧与扩展帧的通信驱动
基于FPGA的CAN通信,FPGA驱动SJA1000T芯片代码,实现标准帧与扩展帧的通信驱动,已上板调通品牌型号 CAN SJA1000T 与世面上的不同,代码不是SJA1000T芯片代码,而是驱动 ...
常用代码扩展点设计方式
文章目录 Java SPI 1)简介 2)代码示例 3)实现原理优缺点 dubbo SPI 1)简介 2)代码示例策略模式及改进版扩展点实现策略模式扩展点实现策略模式改进扩展点实现 Cola 扩 ...
巧用拦截器：高效的扩展点设计
最近在设计框架时,需要设计一类扩展点,发现不能简单地继承或使用事件来给使用者提供 API.最终使用拦截器模式解决了 API 的设计. 扩展点使用场景该扩展点的使用场景如下: 不能使用继承:需要在类型 ...
java rwd_面向任务的设计-不仅限于Mobile First和RWD
java rwd We already know that majority of solutions should start with a design for smartphones, we k ...
面向失败的设计之播控系统！
作者 | 阿里文娱高级开发工程师云琰浅责编 | 屠敏谈面向失败的设计 1.什么是面向失败的设计? 面向失败的设计,就是以"失败"为对象,天然为了失败而存在的设计思想,在一开始 ...
基于matlab的纸币面额面向识别方法设计
基于matlab的纸币面额面向识别方法设计摘要:本设计的主要研究内容是在获取人民币的基础上通过FPGA.CIS传感器进行纸币图像采集,并对采集到的纸币图像进行预处理,包括去噪.边缘检测和倾斜校正. ...
面向spi和面向api_面向API的设计的重要性
面向spi和面向api Many programmers (or coders, or software engineers, or computer wizards, or whatever ter ...
在面向数据流的设计方法中，一般把数据流图中的数据流划分为（16）两种。答案：C
在面向数据流的设计方法中,一般把数据流图中的数据流划分为 (16) 两种. (16)A．数据流和事务流 B．变换流和数据流 C．变换流和事务流 D．控制流和事务流数据流的类型决定映射的方法.数据流有 ...
面向数据流的设计方法
面向数据流的设计方法的目标是给出设计软件结构的一个系统化的途径. 在软件工程的需求分析阶段,信息流是一个关键考虑.通常用数据流图描绘信息在系统中加工和流动的情况.面向数据流的设计方法定义了一些不同的 ...

用代码来说明，为什么需要面向扩展的设计

用代码来说明，为什么需要面向扩展的设计相关推荐

最新文章

热门文章