我正在学习如何用JavaScript制作面向对象编程。是否有接口概念(如Java的接口)?
这样我就可以创建一个监听器。
当前回答
JavaScript接口:
虽然JavaScript没有接口类型，但经常需要它。由于JavaScript的动态特性和原型继承的使用，很难确保跨类接口的一致性——然而，这是有可能做到的;并经常被模仿。
在这一点上，有一些特殊的方法来模拟JavaScript中的接口;方法上的差异通常满足了一些需求，而其他的则没有得到解决。通常情况下，最健壮的方法过于繁琐，阻碍了实现者(开发人员)的工作。
下面是一种接口/抽象类的方法，它不是很麻烦，是显式的，使抽象中的实现最小化，并为动态或自定义方法留下足够的空间:
function resolvePrecept(interfaceName) {
var interfaceName = interfaceName;
return function curry(value) {
/* throw new Error(interfaceName + ' requires an implementation for ...'); */
console.warn('%s requires an implementation for ...', interfaceName);
return value;
};
}
var iAbstractClass = function AbstractClass() {
var defaultTo = resolvePrecept('iAbstractClass');
this.datum1 = this.datum1 || defaultTo(new Number());
this.datum2 = this.datum2 || defaultTo(new String());
this.method1 = this.method1 || defaultTo(new Function('return new Boolean();'));
this.method2 = this.method2 || defaultTo(new Function('return new Object();'));
};
var ConcreteImplementation = function ConcreteImplementation() {
this.datum1 = 1;
this.datum2 = 'str';
this.method1 = function method1() {
return true;
};
this.method2 = function method2() {
return {};
};
//Applies Interface (Implement iAbstractClass Interface)
iAbstractClass.apply(this); // .call / .apply after precept definitions
};
参与者
命令解析器
resolvePrecept函数是一个在抽象类中使用的实用工具和帮助函数。它的工作是允许对封装的戒律(数据和行为)进行定制的实现处理。它可以抛出错误或警告——并且——将默认值赋给实现者类。
iAbstractClass
iAbstractClass定义要使用的接口。它的方法需要与其实现者类达成默契。这个接口将每个戒律分配给相同的戒律名称空间——或——给戒律解析器函数返回的任何东西。但是，这个默契会分解为一个上下文——实现者的一个规定。
实现者
实现者只是“同意”一个接口(在本例中是iAbstractClass)，并通过构造器劫持来应用它:iAbstractClass.apply(this)。通过定义上面的数据和行为，然后劫持接口的构造函数——将实现者的上下文传递给接口构造函数——我们可以确保将添加实现者的重写，并且该接口将解释警告和默认值。
这是一种非常简单的方法，在不同的项目过程中，对我和我的团队都非常有用。然而，它确实有一些警告和缺点。
缺点
虽然这有助于在很大程度上实现整个软件的一致性，但它并没有实现真正的接口——而是模拟它们。尽管定义、默认值、警告或错误都被解释了，但使用的解释是由开发人员强制执行和断言的(就像大多数JavaScript开发一样)。
这似乎是“JavaScript中的接口”的最佳方法，然而，我希望看到以下问题得到解决:
返回类型的断言 签名的断言 冻结删除操作中的对象 JavaScript社区的特殊性中任何其他普遍或需要的断言
也就是说，我希望这对你有帮助，就像我和我的团队一样。
其他回答
JavaScript接口:
虽然JavaScript没有接口类型，但经常需要它。由于JavaScript的动态特性和原型继承的使用，很难确保跨类接口的一致性——然而，这是有可能做到的;并经常被模仿。
在这一点上，有一些特殊的方法来模拟JavaScript中的接口;方法上的差异通常满足了一些需求，而其他的则没有得到解决。通常情况下，最健壮的方法过于繁琐，阻碍了实现者(开发人员)的工作。
下面是一种接口/抽象类的方法，它不是很麻烦，是显式的，使抽象中的实现最小化，并为动态或自定义方法留下足够的空间:
function resolvePrecept(interfaceName) {
var interfaceName = interfaceName;
return function curry(value) {
/* throw new Error(interfaceName + ' requires an implementation for ...'); */
console.warn('%s requires an implementation for ...', interfaceName);
return value;
};
}
var iAbstractClass = function AbstractClass() {
var defaultTo = resolvePrecept('iAbstractClass');
this.datum1 = this.datum1 || defaultTo(new Number());
this.datum2 = this.datum2 || defaultTo(new String());
this.method1 = this.method1 || defaultTo(new Function('return new Boolean();'));
this.method2 = this.method2 || defaultTo(new Function('return new Object();'));
};
var ConcreteImplementation = function ConcreteImplementation() {
this.datum1 = 1;
this.datum2 = 'str';
this.method1 = function method1() {
return true;
};
this.method2 = function method2() {
return {};
};
//Applies Interface (Implement iAbstractClass Interface)
iAbstractClass.apply(this); // .call / .apply after precept definitions
};
参与者
命令解析器
resolvePrecept函数是一个在抽象类中使用的实用工具和帮助函数。它的工作是允许对封装的戒律(数据和行为)进行定制的实现处理。它可以抛出错误或警告——并且——将默认值赋给实现者类。
iAbstractClass
iAbstractClass定义要使用的接口。它的方法需要与其实现者类达成默契。这个接口将每个戒律分配给相同的戒律名称空间——或——给戒律解析器函数返回的任何东西。但是，这个默契会分解为一个上下文——实现者的一个规定。
实现者
实现者只是“同意”一个接口(在本例中是iAbstractClass)，并通过构造器劫持来应用它:iAbstractClass.apply(this)。通过定义上面的数据和行为，然后劫持接口的构造函数——将实现者的上下文传递给接口构造函数——我们可以确保将添加实现者的重写，并且该接口将解释警告和默认值。
这是一种非常简单的方法，在不同的项目过程中，对我和我的团队都非常有用。然而，它确实有一些警告和缺点。
缺点
虽然这有助于在很大程度上实现整个软件的一致性，但它并没有实现真正的接口——而是模拟它们。尽管定义、默认值、警告或错误都被解释了，但使用的解释是由开发人员强制执行和断言的(就像大多数JavaScript开发一样)。
这似乎是“JavaScript中的接口”的最佳方法，然而，我希望看到以下问题得到解决:
返回类型的断言 签名的断言 冻结删除操作中的对象 JavaScript社区的特殊性中任何其他普遍或需要的断言
也就是说，我希望这对你有帮助，就像我和我的团队一样。
JavaScript中没有本机接口， 有几种方法可以模拟接口。我已经写了一个包来做这件事
你可以看到这里的植入
这是一个老问题，但这个话题一直困扰着我。
由于这里和网络上的许多答案都专注于“强制”界面，我想提出另一种观点:
当我使用行为相似的多个类(即实现一个接口)时，我感到最缺乏接口。
例如，我有一个电子邮件生成器，期望接收电子邮件节工厂，“知道”如何生成节的内容和HTML。因此，它们都需要某种类型的getContent(id)和getHtml(content)方法。
我能想到的最接近接口的模式(尽管它仍然是一种变通方法)是使用一个将获得2个参数的类，它将定义2个接口方法。
这种模式的主要挑战是，方法要么必须是静态的，要么必须获取实例本身作为参数，以便访问其属性。然而，在有些情况下，我发现这种权衡是值得的。
class Filterable { constructor(data, { filter, toString }) { this.data = data; this.filter = filter; this.toString = toString; // You can also enforce here an Iterable interface, for example, // which feels much more natural than having an external check } } const evenNumbersList = new Filterable( [1, 2, 3, 4, 5, 6], { filter: (lst) => { const evenElements = lst.data.filter(x => x % 2 === 0); lst.data = evenElements; }, toString: lst => `< ${lst.data.toString()} >`, } ); console.log('The whole list: ', evenNumbersList.toString(evenNumbersList)); evenNumbersList.filter(evenNumbersList); console.log('The filtered list: ', evenNumbersList.toString(evenNumbersList));
这是旧的，但我实现了在ES6上使用的接口，没有转译器。
https://github.com/jkutianski/ES6-Interfaces
拿起Dustin Diaz的“JavaScript设计模式”。有几章专门介绍通过Duck Typing实现JavaScript接口。这也是一本好书。但是，没有接口的语言本机实现，你必须使用Duck Type。
// example duck typing method
var hasMethods = function(obj /*, method list as strings */){
var i = 1, methodName;
while((methodName = arguments[i++])){
if(typeof obj[methodName] != 'function') {
return false;
}
}
return true;
}
// in your code
if(hasMethods(obj, 'quak', 'flapWings','waggle')) {
// IT'S A DUCK, do your duck thang
}
