问题： (The Problem:)

Polymorphism is important in any language and while it is very easy to write polymorphic code in JavaScript, it is relatively hard to manage that code. Without explicit types you must either assume the structure of an object, or explicitly test its structure before using any functionality. Explicitly testing slows down your code, while making unsound assumptions usually results in bugs. This might sound like a trade off, but it’s just another problem for which fast and safe solutions exist.

多态性在任何语言中都很重要，尽管用JavaScript编写多态代码非常容易，但是管理该代码却相对困难。 如果没有显式类型，则必须假定对象的结构，或者在使用任何功能之前显式测试其结构。 显式测试会减慢您的代码速度，而做出不合理的假设通常会导致错误。 这听起来似乎是个折衷方案，但这只是存在快速安全的解决方案的另一个问题。

A great solution is type annotations. You probably know about TypeScript and Flow already, so I’ll just be mentioning pieces that relate to what I want to discuss.

一个很好的解决方案是类型注释。 您可能已经了解TypeScript和Flow，所以我将只提及与我要讨论的内容有关的部分。

Flow and TypeScript don’t solve naming conflicts. If you were trying to implement two interfaces that both required a method named

.foo()

but with different behavior then chances are that you’ll need multiple objects and switch between them. This is probably a very rare case depending on your coding style and the libraries you interact with. Even so, naming conflicts can cause bugs and hinder innovation. #smooshgate is an example of the worst case. A best case is Fantasy Land, which uses method names like

fantasy-land/equals

and

fantasy-land/empty

which have a low chance of colliding.

Flow和TypeScript不能解决命名冲突。 如果您试图实现两个都需要一个名为

.foo()

但具有不同行为的方法的接口，则可能需要多个对象并在它们之间切换。 根据您的编码风格和与之交互的库，这可能是非常罕见的情况。 即使这样，命名冲突仍可能导致错误并阻碍创新。 #smooshgate是最坏情况的一个示例。 最好的情况是“幻想土地”，它使用诸如“

fantasy-land/equals

和“

fantasy-land/empty

类的方法名称，它们发生冲突的可能性很小。

Web standard designers can’t have any collisions and they want to innovate quickly. What can they do? They can use symbols — well-known symbols, to be specific.

Web标准设计人员不可能有任何冲突，他们希望快速进行创新。 他们能做什么？ 他们可以使用符号-具体来说就是众所周知的符号。

更改语言行为： (Changing Language Behavior:)

By using well-known symbols we can do all kinds of things. Most of them don’t seem useful — like

Symbol.toStringTag

which lets you minutely change the output of

.toString

— while others are very useful — like

Symbol.iterator

which lets you create objects that work with for-of loops, the spread operator, and elsewhere. Whether powerful or not, the existence of well-known symbols increases the consistency and introspective ability of JavaScript. Later, we’ll use some well-known symbols to build a custom trait class, but first let’s use

Symbol.iterator

(usually abbreviated

@@iterator

) to build an object that iterates over the Fibonacci sequence to understand how they work.

通过使用众所周知的符号，我们可以做各种事情。 它们中的大多数似乎都不有用-例如

Symbol.toStringTag

，它允许您细微地更改

.toString

的输出-而另一些则非常有用-例如

Symbol.iterator

，它使您可以创建与for-of循环配合使用的对象，即扩散算子，以及其他地方。 无论功能强大与否，众所周知的符号的存在都会提高JavaScript的一致性和自省能力。 稍后，我们将使用一些著名的符号来构建自定义特征类，但首先让我们使用

Symbol.iterator

(通常缩写为

@@iterator

)来构建一个对象，该对象遍历斐波那契序列以了解其工作原理。

斐波那契迭代器： (Fibonacci Iterator:)

In the real world, it would be better to use a generator instead of the following class and I’m confident that you could build a more concise version than this example. Anyway, here’s the code:

在现实世界中，最好使用生成器而不是以下类，并且我相信您可以构建一个比此示例更简洁的版本。 无论如何，这是代码：

When you try to iterate over an object with a for-of loop, the runtime checks if the object has a

@@iterator

method. If it does it calls it which should return an object that follows the iterator protocol. The iterator protocol requires having a

.next()

method that returns objects with

value

and

done

properties. In our case, we’ve implemented

next

on the class itself and so our

@@iterator

method just returns

this

. If there had been a conflict, then we could have returned a different object — one that probably would have some access to the root object. Here’s an example of that:

当您尝试使用for-of循环

@@iterator

对象时，运行时将检查该对象是否具有

@@iterator

方法。 如果这样做，它将调用该方法，该方法应返回遵循迭代器协议的对象。 迭代器协议要求具有

.next()

方法，该方法返回具有

value

和

done

属性的对象。 在我们的例子中，我们在类本身上实现了

next

，因此我们的

@@iterator

方法仅返回

this

。 如果发生冲突，那么我们可以返回一个不同的对象-一个可能可以访问根对象的对象。 这是一个例子：

We can thus always get around naming conflicts, because we can return any object from our

@@iterator

function. If you weren’t using symbols you would probably still have two objects, but might not have a clear way of providing the right one in the right places.

因此，我们总是可以避免命名冲突，因为我们可以从

@@iterator

函数返回任何对象。 如果您不使用符号，则可能仍然会有两个对象，但可能没有明确的方法在正确的位置提供正确的对象。

运行时和静态分析： (Runtime and Static Analysis:)

This is a runtime solution which means it has runtime overhead. In TypeScript, we could have just called

.next()

on an instance of our Fib class because TypeScript’s extra information tells us that Fib has a nextmethod and that its signature matches what we want. With well-known symbols, we have a level of indirection. Not just a pointer de-reference indirection, but a function run indirection — not something to be ignored performance wise. Indirection is usually a requirement for polymorphism unless you have monomorphization. [Also, technically it’s two levels of indirection because we already have one level due to only having references to objects in JavaScript, but let’s move on.]

这是一个运行时解决方案，这意味着它具有运行时开销。 在TypeScript中，我们可以在Fib类的实例上调用

.next()

，因为TypeScript的额外信息告诉我们Fib具有下一个方法，并且其签名与我们想要的匹配。 使用众所周知的符号，我们有一定程度的间接性。 不仅是指针取消引用间接访问，而且函数运行间接访问-在性能方面也不应该被忽略。 除非您具有单态性，否则通常需要多态来进行间接寻址。 [此外，从技术上讲，它是间接的两个级别，因为我们已经有了一个级别，因为仅在JavaScript中引用了对象，所以让我们继续。

You may be wondering how using a symbol is any better than just testing if the instance has a nextmethod. If we did that (called duck-typing) we would need to test a lot of stuff. We would need to check if there was a nextfunction, then see if calling nextreturned an object (if it didn’t, then hopefully we didn’t trigger any side effects), and then check if that object has value and done properties, and that the done property is a boolean, etc. We have to do all these checks because we aren’t certain that the object having a nextmethod that resembles our iterator protocol isn’t just a coincidence. Someone could accidentally implement the iterator protocol when they never intended it to be iterated. Unlikely but possible.

您可能想知道使用符号比仅测试实例是否具有下一个方法有什么好处。 如果我们这样做(称为鸭式打字)，我们将需要测试很多东西。 我们将需要检查是否存在下一个函数，然后查看调用next是否返回了一个对象(如果没有，则希望我们没有触发任何副作用)，然后检查该对象是否具有值和完成的属性，并且done属性是一个布尔值，等等。我们必须进行所有这些检查，因为我们不确定具有下一个类似于迭代器协议的方法的对象并不是巧合。 当某人从未打算对其进行迭代时，可能会意外地实现迭代器协议。 不太可能但可能。

With symbols we can be certain that the author intended to implement the iterator protocol. They must have acquired our symbol from

Symbol.iterator

— a unique symbol that cannot be acquired any other way (for the most part). Even if you have methods with the right names and even the right signatures, you must also have the

@@iterator

method for it to be iterable.

使用符号，我们可以确定作者打算实现迭代器协议。 他们必须已经从

Symbol.iterator

获得了我们的符号-这是一个唯一的符号(大多数情况下无法通过其他方式获得)。 即使您具有名称正确甚至签名正确的方法，也必须具有

@@iterator

方法才能使其迭代。

Since we know that the implementer intentionally made the object iterable, we don’t have to check if the returned object has a nextmethod because it must (or else it’s a bug). We may still do the duck-typing checks, but perhaps only in a debug build and we could remove them in release. Additionally, if you’re using TypeScript, it will help make sure that a manual iterator implementation has a nextmethod with a valid signature.

因为我们知道实现者有意使对象可迭代，所以我们不必检查返回的对象是否具有下一个方法，因为它必须(或它是一个错误)。 我们可能仍会进行鸭子类型检查，但也许仅是在调试版本中进行，我们可以在发行版中将其删除。 另外，如果您使用的是TypeScript，它将有助于确保手动迭代器实现具有下一个带有有效签名的方法。

Lastly, the iterator protocol plays nicely with others. Anything iterable can be iterated either with a for-of loop, spread,

Array.from()

, or manually calling

.next()

no mater what library it comes from. Similarly, if we create our own symbols — well-known in that they are only obtainable by importing an es6 module — with a clear protocol, then all code using it should be interoperable.

最后，迭代器协议可以与其他协议很好地协作。 任何可迭代的对象都可以使用for-of循环，spread，

Array.from()

进行迭代，也可以手动调用

.next()

，

Array.from()

来自哪个库。 同样，如果我们使用清晰的协议创建自己的符号(众所周知，它们只能通过导入es6模块获得)，那么使用该符号的所有代码都应可互操作。

模式：模仿和扩展知名的符号 (The Pattern: Imitate and Extend Well-Known Symbols)

To begin exploring what having our own well-known symbols (which I will now also call traits) is like, let’s first introduce a helper that will make working with them easier. It’s a simple class that takes advantage of a few well-known symbols to adjust JS behavior.

要开始探索具有我们自己熟知的符号(现在也称为特质)的外观，让我们首先介绍一个使它们使用起来更容易的助手。 这是一个简单的类，它利用一些著名的符号来调整JS行为。

We use

@@toPrimitive

so that it turns into the underlying symbol when we use it in a method / property name expression and we use

@@hasInstance

to override the instanceofbehavior. It looks like this when it is used:

我们使用

@@toPrimitive

以便在方法/属性名称表达式中使用它时，它会变成基础符号，并且使用

@@hasInstance

覆盖instanceof行为。 使用时看起来像这样：

This illustrates how easy it is to test if something implements a trait and that the protocol a trait represents can be anything (functions, objects, just a property, etc.) except undefined.

这说明了测试某物是否实现了特征以及特征所代表的协议可以是除未定义之外的任何内容(函数，对象，仅仅是属性等)是多么容易。

特质协议和实施中的状态： (State in Trait Protocols and Implementations:)

Something to note is that the protocol for Drivable is different from the iterator protocol. In the iterator protocol, the object returned from

@@iterator

can have state which is why when you use a for-of loop to iterate over an array and then later use another for-of loop on that array, the second iteration will start from the beginning not where you last stopped — the iterations are independent. This happens even if you break out of the first loop before reading to the end of the array. In our Drivable trait, we get the object that implements Drivable for our Car, but we don’t store it before calling

.steer()

. This means if we needed to call

.steer()

again, we would have to fetch the Drivable implementation again. In the case of Horse, the returned implementation would be a brand new object instead of the one previously returned, but it would function identically to the first value it returned because it has no state / applies all changes to the Horse directly.

需要注意的是，Drivable的协议与迭代器协议不同。 在迭代器协议中，从

@@iterator

返回的对象可以具有状态，这就是为什么当您使用for-of循环对数组进行迭代，然后在该数组上使用另一个for-of循环时，第二个迭代将从开始不是您上次停止的地方-迭代是独立的。 即使您在读取数组末尾之前退出第一个循环，也会发生这种情况。 在Drivable特性中，我们获得了为Car实现Drivable的对象，但是在调用

.steer()

之前不存储它。 这意味着，如果我们需要再次调用

.steer()

，我们将不得不再次获取Drivable实现。 在Horse的情况下，返回的实现将是一个全新的对象，而不是先前返回的对象 ，但它的功能与返回的第一个值相同 ，因为它没有状态/直接将所有更改应用于Horse。

For many traits, it makes sense for the protocol to require statelessness in the implementation. If you had an array of objects, and your protocol wasn’t stateless, you might need a second array to hold the trait implementation objects doubling the memory used. Here’s an example of that happening:

对于许多特性而言，协议在实现中要求无状态是有意义的。 如果您有一个对象数组，并且协议不是无状态的，则可能需要第二个数组来保存特征实现对象，从而使使用的内存增加一倍。 这是发生这种情况的一个示例：

See, because we needed repeated access to the trait implementation, but it was stateful, and lastly because getting the trait implementation for car returned a new implementation every time, we needed two arrays. This problem only comes up when these three things come together. I’ve done it accidentally before so I wanted to mention it. A weak-map would probably work better in this case (either instead of the second array or to return the same implementation every time), but it still illustrates the pitfall.

看到了，因为我们需要重复访问trait实现，但是它是有状态的，最后，因为每次获得car的trait实现都会返回一个新的实现，所以我们需要两个数组。 仅当这三件事结合在一起时才会出现此问题。 我之前是不小心做的，所以我想提一提。 在这种情况下，弱映射可能会更好地工作(代替第二个数组或每次都返回相同的实现)，但它仍然说明了陷阱。

Looking back at the iterator protocol, iteration is usually short-lived reducing the likelihood that you’d need to hold a reference to the implementation object. Iterating doesn’t affect the container — unlike a filter or sort for example. These two properties make storing state in the implementation object a good choice for iterator. Choosing whether to couple or decouple state in a trait implementation is a technical decision and being familiar with other implementations / protocols similar to your own can help. There are many places to learn about good protocols. Look at the life-cycle in React or other frameworks. Look at async iterators. My favorite source is the Rust standard library which has many traits and good documentation.

回顾迭代器协议，迭代通常是短暂的，从而减少了需要保存对实现对象的引用的可能性。 迭代不会影响容器-例如，不同于过滤器或排序。 这两个属性使状态存储在实现对象中成为迭代器的不错选择。 选择是将特征实现中的状态耦合还是解耦是一项技术决定，熟悉其他类似于您自己的实现/协议可能会有所帮助。 有很多地方可以学习好的协议。 查看React或其他框架的生命周期。 查看异步迭代器。 我最喜欢的资源是Rust标准库，它具有许多特征和良好的文档。

Iteration can be made to affect the container as we did in our Fibonacci example. It wasn’t very useful for Fibonacci, but it is very useful if you are building something like a queue where every item needs to be seen once even though there might be pauses between iteration. Building a consuming iterator is a good way to transform events / callbacks into an async “stream” — something I’ve done a lot of.

可以像在斐波那契示例中那样进行迭代来影响容器。 对于斐波那契来说，它并不是很有用，但是如果您要构建一个类似队列的东西，则即使迭代之间可能会有暂停，每个项目都需要被查看一次，这对您很有用。 构建消耗型迭代器是将事件/回调转换为异步“流”的好方法，这是我做过的很多事情。

通用实现： (Generic Implementations:)

Well-known symbols help avoid / work around collisions. They give us confidence that our protocol was intentionally implemented (or at least attempted to be implemented). That alone isn’t enough to want to use this pattern, though. It becomes more attractive when you see that you can write functions to implement traits for a class based on other traits it implements — generic implementations.

众所周知的符号有助于避免碰撞/避免碰撞。 他们使我们相信我们的协议是有意实施的(或者至少是试图实施的)。 但是，仅凭这一点还不足以使用此模式。 当您看到可以编写基于类实现的其他特性(通用实现)的功能来实现该特性时，它会变得更具吸引力。

Here’s an example where the AI of an entity is derived from whether the entity is Undead or not:

这是一个示例，其中实体的AI取决于该实体是否为亡灵：

This puts all of the AI logic in one place and keeps the prototype chains short. Any changes to the AI need only be made in one place and will be visible across all the entities. This is the power of derivation.

这将所有AI逻辑放在一个地方，并使原型链简短。 对AI的任何更改都只需要在一个地方进行，并且在所有实体中都是可见的。 这就是推导的力量。

It’s a little inconvenient to have to call

implement_ai()

on each class, but once we get decorators this kind of thing will be easier and more common.

在每个类上都必须调用

implement_ai()

有点不方便，但是一旦获得装饰器，这种事情将变得更加简单和普遍。

与TypeScript的交互： (Interaction with TypeScript:)

The last thing I want to mention is that this pattern is hard to work with in TypeScript. I’ve briefly tried to add types for some code that used it heavily and it didn’t work. If you know how to do it, I’m eager to learn how.

我要提到的最后一件事是，在TypeScript中很难使用此模式。 我曾短暂地尝试为一些使用它的代码添加类型，但是它没有用。 如果您知道该怎么做，我很想学习如何做。

The problem is mostly because we’re adding a method / property with a dynamic name. The Trait class is a constant expression that evaluates to the symbol, but TypeScript can’t see it — not without partial evaluation perhaps. If I’m not mistaken, even the standardized well-known symbols require special support within TypeScript — which can’t be extended to our symbols.

问题主要是因为我们要添加带有动态名称的方法/属性。 Trait类是一个常量表达式，其计算结果为符号，但是TypeScript无法看到它-可能没有部分求值。 如果我没记错的话，即使标准的知名符号也需要TypeScript的特殊支持-不能扩展到我们的符号。

Something I haven’t tried is using a symbol registered with a string using

Symbol.for()

. This is an alternative to having it be in an es6 module and importing that module into all the code that implements that trait. Personally, I don’t like the registering approach because it gets back to using strings to avoid collisions. It’s like using

fantasy-land/empty

as the function name — unlikely to collide, but possible.

我还没有尝试过使用

Symbol.for()

在字符串中注册的符号。 这是将其置于es6模块中并将该模块导入实现该特性的所有代码中的一种替代方法。 就个人而言，我不喜欢注册方法，因为它回到了使用字符串来避免冲突的位置。 就像使用

fantasy-land/empty

作为函数名称一样-不太可能发生冲突，但有可能发生。

结论： (Conclusion:)

I hope you learned something. Maybe you hadn’t overridden default behavior using well-known symbols before. Maybe you have an idea for a better

instanceof

than the one I’ve shown you. Maybe you take issue with everything I’ve said. That’s fair and I’d love to talk with you about what you think.

我希望你学到了一些东西。 也许以前您没有使用知名符号来覆盖默认行为。 也许您有一个比我向您展示的

instanceof

更好的想法。 也许您对我所说的一切都不满意。 那很公平，我很想和您谈谈您的想法。

I think this pattern has precedence in the standard and is therefore worthwhile exploring. We may see more well-known symbols in the future and working with them should be natural. There’s a lot that goes into designing traits and building good protocols — some of which we can learn from watching JavaScript be developed. Sadly, this pattern doesn’t seem typed-super-set friendly.

我认为这种模式在标准中具有优先地位，因此值得探讨。 我们可能会在将来看到更多知名的符号，并且与它们合作应该是很自然的。 在设计特征和建立良好的协议方面有很多工作-其中一些我们可以从观看JavaScript开发中中学到。 可悲的是，这种模式似乎不是类型超级集友好的。

Thanks for reading. Have a good day, and happy coding.

谢谢阅读。 祝您有美好的一天，并祝您编程愉快。

翻译自: https://medium.com/@Evan_Brass/built-in-and-custom-traits-in-javascript-5e532de069f2