Интерфейсы в javascript
 

Привет.
На вашем сайте читал статью про наследование и ООП. А делал ли кто-то интерфейсы на javascript ? Причём чтобы любой класс мог наследоваться от какого-то другого класса и реализовывать n-ое количество интерфейсов ?

интерфейсов и классов в JS - нет (но велосипедов реализации до кучи), но наследование есть, такое о котором вы уже прочитали.

Мне вот хотя бы один пример велосипеда с интерфейсами посмотреть...

Если классы ещё кому-то нужны в JS, то интерфейсы точно не нужны, поэтому и велосипедов нет.

классы: http://habrahabr.ru/blogs/javascript/68004/
интерфейсы: http://knol.google.com/k/programming...r-i-mean-faked
http://files.trygve-lie.com/examples...ect_interface/
давно что-то еще читал по этой теме, но где припомнить не могу...

Интерфейс — это набор объявлений методов, который позволяет несвязанным объектам взаимодействовать друг с другом, что позволяет расширяемому классу принимать реализации других классов. Что по сути можно назвать множественным наследованием.

Как бы это отрицательно сказалось если бы в JS были интерфейсы?
По моему если есть классы, то не использовать интерфейсы не логично.
В AS они есть и это же прекрасно, почему бы в JS не реализовать?

Спасибо, капитан. Но JS позволяет объектам взаимодействовать друг с другом и без интерфейсов.

Приведите пример, показывающий, что "а вот если бы были интерфейсы, то я бы такое сделал...".

я к тому, что и классы в JS нет необходимости по этой логике реализовывать...

нет у меня пока таких идей, т.к. обсуждать нечего, но удобства интерфейсов очевидны:

interface A { 
    function foo():void; 
}

interface B { 
    function bar():void; 
}
 
class myClass implements A, B { 
    public function foo():void {} 
    public function bar():void {} 
}

причем, интерфейс может же и выступать как отдельная сущность:

public interface A {
  function fooA():void;
}

public interface B extends A {
  function fooB():void;
}

public interface C {
  function fooC():void;
}

public interface D {
  function fooD():void;
}

public interface E extends C, D {
  function fooE():void;
}

Но JS, мы тоже самое через одно место будем делать, в замен наглядности и минимального использования кода.

Kolyaj, только не стоит думать, что меня что-то в JS не устраивает или ограничивает, просто ничего плохого в реализации интерфейсов я не вижу, может по тому, что в я к ним привык в AS и PHP...

А никто их и не реализовывает, ибо невозможно. Реализуют только похожий синтаксис, семантика остаётся прототипная.

Чем это отличается в динамическом языке от

class myClass {
    public function foo():void {}
    public function bar():void {}
}

?

в первом случае класс myClass реализует интерфейсы A и B.
Во втором случае определяется класс без конструктора, что в AS принято называть реализацией абстрактных методов (хотя их там и нет формально).

Я честно не понял вашу мысль, наверно имелось ввиду это?

interface myClass  { 
    public function foo(param:int = 0):void
}

class A implements myClass { 
    public function foo(param:int = 1):void {} 
}

Ответьте для себя на вопрос: "Зачем в статических языках нужны интерфейсы?". После чего можно будет ответить на другой вопрос "Почему в динамических языках интерфейсы не нужны?".

как минимум для того, что JS сейчас используется не только в браузере, но и в другом ПО, а также считается одним из тех языков, которые портрированы в различные игровые движки и пр. трансляторы для портативных устройств. Причем по сути портрируется AS, но по каким-то причинам в документации пишут, что JS.
В любом случае найти применения интерфейсам в JS можно, но конкретно для каких проектов можно будет сказать, только тогда когда они появятся.

Какая разница, где выполняется JS? Вопрос не "Где используются интерфейсы?", а "Для чего используются интерфейсы?".

Вы так и не ответили, зачем нужны интерфейсы в JS. Приводите куски кода на AS, говоря "ну вот же", а зачем вы их приводите, не говорите.

классы в js уже есть, по сути... интерфейсы и прочие статические приколы... помимо ответа на твой вопрос, Kolyaj, неискушенный пейсатель может заметить, что это все надо для сферического уменьшения количества ошибок в ПО. Но ведь все мы знаем. Дуглас Наше все Крокфорд сказал, что эти ошибки легко и быстро обнаруживаются, а реальные проблемы создают совсем другого типа недосмотры

а читая предлагаемую спецификацию (старую), создается впечатление, что они хотят сделать javascript статическим и считают, что это круто. Если так нужен статический язык, напишите новый, для серьёзных проектов, зачем поддерживать совместимость с "морально устаревшим" javascript и втыкать в него костыли? В конце концов, объявите actionscript новым стандартом

Я уже лет 7 пишу на динамических языках, не помню ни одной ошибки, возникшей из-за несоответствия типов. Они были, это однозначно, но я их не помню, потому что это скорее опечатки, они не стоят внимания.

В данный момент я стараюсь весь код документировать JSDoc-ами, в следствие чего IDE подсвечивает несоответствие типов исходя из них.

Если не секрет в какой IDE работаете ?

процентов 90%, что NotePad++ :) 10% - PHPStorm или WebStorm
чтобы писать программы на JS, это наверное самый оптимальный вариант.

Kolyaj, не удержался))

Kolyaj, раз уж зашла тема про JSDoc, не мог бы подсказать, как научить идею генерить их для JavaScript? Что-то никак не могу найти такой плагин.

WebStorm.

Notepad++ даже не ставил себе никогда :)

IDEA/WebStorm/PhpStorm вобщем-то без плагинов генерят всё, что могут.
Имеем, например, функцию

function foo(arg1, arg2, arg3) {
    
}

Пишем перед ней /**, нажимаем enter, получаем

/**
 *
 * @param arg1
 * @param arg2
 * @param arg3
 */
function foo(arg1, arg2, arg3) {

}

Описание, типы параметров и тип возвращаемого значения придётся самому писать, тут IDE никак не догадается. Хотя в JetBrains работают чертовски умные люди, не исключаю, что когда-нибудь будет догадываться :)

:blink: Шайтан. Что ж ты раньше молчал? :)
А генерить из этого документацию можно? Я жму Generate JavaDoc - не генерит, видимо только для Java.

http://ru.wikipedia.org/wiki/JSDoc Здесь пара ссылок есть.
Я для проекта на ExtJS генерировал документацию, похожую на extjs-овскую, но там всякие расширения jsdoc-а используются.

Возвращаясь к разговору об интерфейсах в js, стоит сказать, что интерфейсы неявно представлены в языке в виде методов call и apply.

а можно развернуть мысль?

Попробую более развернуто. Допускаю, выскажу несколько весьма очевидных мыслей.

Интерфейсы суть вариант множественного наследования. Объекты, порожденные от разных классов, но реализующих один интерфейс, имеют одинаковое поведение. А это уже полиморфизм. То есть, разные объекты, наследующие одинаковый интерфейс имеют одинаковый контекст вызова. Не совсем точно, но (как мне кажется) близко по смыслу к идее вызова методов одного объекта в контексте другого. Что и выполняют эти функции.

var x = [1.2, 3.4, 5];
var y = ''.split.call(x, /\W/);

alert(x);
alert(y);

мысль более-менее понятна, но считаю натянута. Назвать контекстом вызова такую абстрактную сущность как интерфейс... Причем получается, что берем мы метод у конкретного объекта, а вызываем в контексте абстрактного интерфейса. Как-то все вверх ногами

Да и просто, интерфейсы не нужны в javascript. Обоснование. Зачем нужны интерфейсы:
1) возможность работать с разными объектами через один и тот же интерфейс (поддерживается автоматом)
2) проверка типов (бессмысленна в языке с динамической типизацией)
3) некое документирование кода (имхо, имеет смысл только в дополнение к пунктам выше)

Мои слова не следует понимать буквально. Речь идет, всего лишь, об аналогиях.

Конечно не нужны. Они не нужны в динамических языках.

Если считать, что интерфейсы - это соглашения в коде между разными частями в системе, то имхо они вполне имеют право на существование в js.
Известный факт, что в js часто взаимодействие между разными объектами оборачивается головной болью.
Т.о. в js функцией интерфейса могла бы быть просто проверка, что объект реализует заданный набор методов с указанными сигнатурами.
Примерно так были реализованы интерфейсы в microsoft ajax - http://www.cristiandarie.ro/asp-ajax/Person3.html. Хотя, в общем-то неудачный пример. Еще интерфейсы вроде есть в php.

P.S. Это конечно, если оставить в стороне тот факт, что реализация этого дела поверх js - тот еще костыль

еще раз, интерфейсы не нужны в языках с динамической типизацией. А головная боль может быть лишь у тех, кто пытается программировать на js, как будто это какой-нибудь java или что еще...

Может быть, вы тогда с такой же уверенностью скажете, зачем в языке с динамической типизацией конструкции instanceOf и typeof ?

прям в тупик загнали :) Может можете какой-нибудь реальный пример, где бы в js пригодились интерфейсы?

и очень интересует всем кроме меня известный факт про головные боли от взаимодействия объектов?

Меня не интересует. Всё зависит от архитектуры.

Мне тоже неизвестен этот факт.

Ну, я про все ту же утипизацию и что из нее вытекает. Если у нас возникла ошибка выполнения, мы идем ее и правим - вылезает другая ошибка - правим...и т.п...а тут оказывается, что первый случай опять сломался. Такие вот замечательные итерации.

Это не головные боли?

Вот отсюда и возникают идеи ввести какие-то соглашения при взаимодейстии объектов

Я уже писал

Может не в тему, но у меня есть подозрение, что код сам ломается если его долго не использовать.:blink:
Вот написал я скрипт, вроде работает.:write:
Кинул в папку к остальным исходникам. Через месяц запускаю, а он не работает:D

Магия :)

Протух.

Приведу пример с интерфейсом IDisposable (как в C#), который имеет один метод Dispose.
Пусть у меня есть система, с большим кол-ом различных js классов. Во избежание утечек памяти у меня есть некий Manager для контроля всех ссылок на созданные объекты. Когда какой-то объект мне не нужен я вызываю у него метод Dispose, а будет ли он за собой чистить свои внутренние ресурсы, это уже его проблема. Т.е. здесь возникает такое соглашение: если Manager'у отдаётся на управление какой-то объект, то он должен реализовывать интерфейс IDisposable.

Но как уже приводились ссылки в начале обсуждения, нужно просто проверить есть ли такой метод/свойство в объекте и если нету, то как вариант кидать Exception.

Ага, а вера в волшебство пропадает, когда понимаете, что вы там не один ковырялись, да?
Вы когда ручку на двери не заметите, за какое место хвататься будете, и если не знаете, в какую сторону дверь открывается? :)

Ну обычно в таких случаях делается что-то типа if(obj.method) obj.method();
Что так-то проблемы быстро локализовать ни разу не помогает

Я имел ввиду примерно такое
if (!obj.Dispose)
throw new Error("Метод или свойство не реализовано");

И делать эту проверку в момент когда, один объект отдаётся другому.
Тогда с локализацией проблем не будет.

Ну да, и так последовательно, для каждой функции?