从 JavaScript 到 TypeScript - 接口

Posted 边城客栈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了从 JavaScript 到 TypeScript - 接口相关的知识,希望对你有一定的参考价值。

前面讲 泛型 的时候,提到了接口。和泛型一样,接口也是目前 javascript 中并不存在的语法。

由于泛型语法总是附加在类或函数语法中,所以从 TypeScript 转译成 JavaScript 之后,至少还存在类和函数(只是去掉了泛型定义,类似 Java 泛型的类型擦除)。然而,如果在某个 .ts 文件中只定义了接口,转译后的 .js 文件将是一个空文件——接口被完全“擦除”了。

那么,TypeScript 中为什么要出现接口语法?而对于没接触过强类型语法的 JSer 来说,接口到底是个什么东西?

什么是接口

现实生活中我们会遇到这么一个问题:出国旅游之前,往往需要了解目的地的电源插座的情况:

  1. 是什么形状,是三插还是双插,是平插还是圆插?

  2. 如果形状相同,电压多少,110V 还是 220V 或者 380V?

  3. 直流电还是交流电?


大家都知道,国内的电源插头常见的有两种,三平插(比如多数笔记本电脑电源插头)和双平插(比如多数手机电源插头),家用电压都是 220V。但是近年来电子产品与国际接轨,电源适配器和充电器一般都支持 100~220V 电压。

那么上面就出现了两类标准,一类是插座的标准,另一类是插头的标准。如果这两类标准一样,我们就可以提包上路,不用担心到地方后手机充不上电,电脑找不到合适电源的问题。但是,如果标准不一样,就必须去买个转换插头,甚至是带变压功能的转换插头。

这里提到的转换插头在软件开发中属于“适配器模式”,这里不深研。我们要研究的是插座和插头的标准。插座就是留在墙上的接口,它有自身的标准,而插头为了能使用这个插座,就必须符合它的标准,换句话说,得匹配接口。工业上这像插座这样的标准必须成文、审批、公布并执行,而编程上的接口也类似,需要定义接口、类型检查(编译器)、公布文档,实现接口。

所以回到 TypeScript,我们以关键字 interface,用类似于 class 声明的语法在定义接口 (还记得声明类型一文中提到的类成员声明吗)。所以一个接口看起来可能是这样的

interface INamedLogable {
    name: string;
    log(...args: any[]);
}

通过实例讲接口

假设我们的业务中有这样一部分 JavaScript 代码

function doWith(logger) {
   console.log(`[Logger] ${logger.name}`);    logger.log("begin to do");
   // ...
   logger.log("all done"); } doWith({    name: "jsLogger",    log(...args) {
       console.log(...args);    } });

翻译成 TypeScript

我们还不懂接口,所以先定义一个类,包含 name 属性和 log() 方法。有了这个类就可以在 doWith() 和其它定义中使用它来进行类型约束(检查)。

class JsLogger {
    name: string;

   constructor(name: string) {
       this.name = name;    }    log(...args: any[]) {
       console.log(...args);    } }

然后定义 doWith

function doWith(logger: JsLogger) {
   console.log(`[Logger] ${logger.name}`);    logger.log("begin to do");
   // ...
   
logger.log("all done"); }

调用示例:

const logger = new JsLogger("jsLogger");
doWith(logger);

给 log() 方法加点料

上面的示例中,输出的日志只有日志内容本身,但是我们希望能在日志信息每行前面缀上日志名称,比如像这样的输出

[jsLogger] begin to do

所以我们从 JsLogger 继承出来一个 PoweredJsLogger 来用:

class PoweredJsLogger extends JsLogger {
    log(...args: any[]) {
       console.log(`[${this.name}]`, ...args);    } }

const logger = new PoweredJsLogger("jsLogger"); doWith(logger);

换个第三方 Logger

甚至我们可以换个第三方 Logger,与 JsLogger 毫无关系,但成员定义相同

function doWith(logger: JsLogger) {
   console.log(`[Logger] ${logger.name}`);    logger.log("begin to do");
   // ...
   
logger.log("all done"); }

const logger = new AnotherLogger("oops"); doWith(logger);

你以为它会报错?没有,它转译正常,运行正常,输出

[Logger] oops
[Another(oops)] begin to do
[Another(oops)] all done

看到这个结果,Java 和 C# 程序员要抓狂了。不过 JSer 觉得这没什么啊,我们平时经常这么干。

从类 (class) 声明接口

理论上来说,接口是一个抽象概念,类是一个更具体的抽象概念——是的,类不是实体 (instance),从类产生的对象才是实体。一般情况下,我们的设计过程是从具体到抽象,但开发(编程)过程正好相反,是从抽象到具体。所以一般在开发过程中都是先定义接口,再定义实现这个接口的类。

当然有例外,我相信多数开发者会有相反的体验,尤其是一边设计一边开发的时候:先根据业务需要定义类,再从这个类抽象出接口,定义接口并声明之前的类实现这个接口。如果接口元素(比如:方法)发生变化,往往也是先在类中实现,再进行抽象补充到接口定义中。这种情况下我们多么希望能直接从类生成接口……当然有工具可以实现这个过程,但多数语言本身并不支持——别再问我原因,刚才已经讲过了。

不过 TypeScript 带来了不一样的体验,我们可以从类声明接口,比如这样

interface ILogger extends JsLogger {
   // 还可以补充其它接口元素
}

这里定义的 ILogger 和最前面定义的 INamedLogable 具有相同的接口元素,是一样的效果。

为什么 TypeScript 支持这种反向的定义……也许真的只是为了方便。但是对于大型应用开发来说,这并不见得是件好事。如果以后因为某些原因需要为 JsLogger 添加公共方法,那就悲剧了——所有实现了 ILogger 接口的类都得实现这个新加的方法。也许以后某个版本的 TypeScript 会处理这个问题,至少现在 Java 已经找到办法了,这就是 Java 8 带来的默认方法,而且 C# 马上也要实现这一特性了 。

回到上面的问题

现在回到上面的问题,为什么向 doWith() 传入 AnotherLogger 对象毫不违和,甚至连个警告都没有。

前面我们已经提到了“鸭子辨型法”,对于 doWith(logger: JsLogger) 来说,它需要的并不真的是 JsLogger,而是 interface extends JsLogger {}。只要传入的这参数符合这个接口约束,方法体内的任何语句都不会产生语法错误,语法上绝对没有问题。因此,传入 AnotherLogger 不会有问题,它所隐含的接口定义完全符合 ILogger 接口的定义。

然而,语义上也许会有些问题,这也是我作为一个十多年经验的静态语言使用者所不能完全理解的。有可能这是 TypeScript 为了适应动态的 JavaScript 所做出的让步,也有可能这是 TypeScript 特意引入的特性。我对多数动态语言和函数式语言并不了解,但我相信,这肯定不是 TypeScript 首创。

TypeScript 接口详述

上面大量的内容只是为了将大家通过 class 的定义引入到对 interface 的了解。但是接口到底该怎么定义?

常规接口

常规接口的定义和类的定义几乎没有区别,上面已经存在例子,归纳起来需要注意几点:

  • 使用 interface 关键字;

  • 接口名称一般按规范前缀 I

  • 接口中不包含实现

  • 不对成员变量赋初始值

  • 没有构造函数

  • 没有方法体

而对接口的实现可以通过 implemnets 关键字,比如

class MyLogger implements INamedLogable {
    name: string;
    log(...args: any[]) {
       console.log(...args);    } }

这是显式地实现,还有隐式的。

const myLogger: INamedLogable = {
    name: "my-loader",
    log(...args: any[]) {
       console.log(...args);    } };

另外,在所有声明接口类型的地方传值或赋值,TypeScript 会通过对接口元素一一对比来对传入的对象进行检查。

函数类型接口

曾经我们定义一个函数类型,是使用 type 关键字,以类似 Lambda 的语法来定义。比如需要定义一个参数是 number,返回值是 string 的函数类型:

// 声明类型
type NumberToStringFunc = (n: number) => string;

// 定义符合这个类型的 hex
const hex: NumberToStringFunc = n => n.toString(16);

现在可以用接口语法来定义

// tslint:disable-next-line:interface-name
interface NumberToStringFunc {    (n: number): string; }
const hex: NumberToStringFunc = n => n.toString(16);

这种定义方式和 Java 8 的函数式接口语法类似,而且由于它表示一个函数类型,所以一般不会前缀 I,而是后缀 Func(有参) 或者 Action(无参)。不过 TSLint 可不吃这一套,所以这里通过注释关闭了 TSLint 对该接口的命名检查。

这样的接口不能由类实现。上例中的 hex 是直接通过一个 Lambda 实现的。它还可以通过函数、函数表达式来实现。另外,它可以扩展为混合类型的接口。

混合类型接口

JSer 们应该经常会用到一种技巧,定义一个函数,再为这个函数赋值某些属性——这没毛病,JavaScript 的函数本身就是对象,而 JavaScript 的对象可以动态修改。最常见的例子应该就是 jQuery 和 Lodash 了。

这样的类型在 TypeScript 中就通过混合类型接口来定义,这次直接引用官方文档的示例:

interface Counter {
    (start: number): string;
    interval: number;
    reset(): void;
}

function getCounter(): Counter {
   let counter = <Counter>function (start: number) { };    counter.interval = 123;    counter.reset = function () { };    return counter; } let c = getCounter(); c(10); c.reset(); c.interval = 5.0;

接口继承

前面我们提到可以从类声明接口,其语法采用 extends 关键字,所以说成是继承也并无不可。

另外,接口还可以继承自其它接口,比如

interface INewLogger: ILogger {
    suplier: string;
}

接口还允许从多个接口继承,比如上面提到的 INamedLogable 可以拆分一下

interface INamed {
    name: string;
}

interface ILogable {    log(...args: any[]); }

interface INamedLogable extends INamed, ILogable {}

这样定义 INamedLogable 是不是更合理一些?

后记

不管什么语言,接口的主要目的是为了在供应者和消费者之前创建一个契约,其意义更倾向于设计而非程序本身,所以接口在各种设计模式中应用非常广泛。不要为了接口而接口,在设计需要的时候使用它。对复杂的应用来说,定义一套好的接口很有必要,但是对于一些小程序来说,似乎并无必要。



请从下面原文链接阅读相关内容

  • 从 JavaScript 到 TypeScript - 模块化和构建

  • 从 JavaScript 到 TypeScript - 声明类型

  • 从 JavaScript 到 TypeScript - 泛型

  • 从 JavaScript 到 TypeScript - 接口

以上是关于从 JavaScript 到 TypeScript - 接口的主要内容,如果未能解决你的问题,请参考以下文章

从 JavaScript 到 TypeScript - 接口

将 nuxt 3 从 TypeScript 迁移到 JavaScript

将 create-react-app 从 javascript 迁移到 typescript

从JavaScript到TypeScript,Flow与WebAssembly

从 React 迁移到 TypeScript:忍受了 15 年的 JavaScript 错误从此走远

第999期从 JavaScript 到 TypeScript