Я хочу прекратить использование ООП в JavaScript и использовать делегирование вместо

Question

Поработав некоторое время с javascript, я все больше убеждался, что ООП - это не правильный путь, или, по крайней мере, не очень.Хорошо иметь два или три уровня наследования, но работать с полным ООП, как это было бы в Java, просто не подходит.

Язык поддерживает компоновку и делегирование изначально.Я хочу использовать только это.Однако у меня возникают проблемы с репликацией определенных преимуществ ООП.

А именно:

1. Как мне проверить, реализует ли объект определенное поведение?Я подумал о следующих методах
   • Проверьте, есть ли у объекта определенный метод.Но это будет означать стандартизацию имен методов, и если проект большой, он может быстро стать громоздким и привести к проблеме Java (object.hasMethod ('emailRegexValidatorSimpleSuperLongNotConflictingMethodName') ... Это просто переместит проблему ООП, а не исправит ееКроме того, я не смог найти информацию о производительности поиска, если методы существуют
   • Сохраните каждый составной объект в массиве и проверьте, содержит ли объект композитор. Что-то вроде: object.hasComposite (compositorClass) ...Но это тоже не очень элегантно и опять ООП, просто не стандартным способом.
   • Пусть у каждого объекта есть свойство массива "Implements", и оставьте ответственность за объект, чтобы сказать, реализует ли онопределенное поведение, будь то с помощью композиции или изначально. Гибкий и простой, но требует помнить ряд соглашений. Это мой предпочтительный метод до сих пор, но я все еще ищу.
2. Как бы я инициализировать объект без повторноготорможение всей установки для составных объектов?Например, если у меня есть класс «textInput», который использует определенное количество валидаторов, которые должны быть инициализированы переменными, и класс «emailInput», который использует точно такие же валидаторы, повторять код неудобно.И если интерфейс валидаторов меняется, код должен меняться в каждом классе, который их использует.Как бы я мог настроить это легко?API, о котором я думаю, должно быть таким же простым, как и выполнение object.compositors ('emailValidator', 'lengthValidator', '...')
3. Есть ли потеря производительности, связанная с выполнением большинства функций, которые выполняютсяв приложении пройти через apply ()?Поскольку я собираюсь широко использовать делегирование, у базовых объектов, скорее всего, почти не будет методов.Все методы будут предоставлены скомпонованными объектами.
4. Есть ли хороший ресурс?Я прочитал бесчисленные сообщения о ООП и делегировании, а также о преимуществах делегирования и т. Д., Но я не могу найти ничего такого, что обсуждало бы «делегирование javascript сделано правильно», в рамках большой структуры.

edit

Дополнительные пояснения:

1. У меня еще нет кода, я работаю над фреймворком в чистом ООП, и я застреваю и мне нужно нескольконаследование.Таким образом, я решил полностью отказаться от занятий.Так что я сейчас просто на теоретическом уровне и пытаюсь из этого разобраться.
2. «Композиция» может быть неправильным словом;Я имею в виду составной шаблон , очень полезный для древовидных структур.Это правда, что редко есть древовидные структуры (ну, конечно, за исключением DOM), но я разрабатываю для node.js

3. Что я имею в виду под «переключением с ООП»"я собираюсь расстаться с определением классов, использованием оператора" new "и т. д .;Я намерен использовать анонимные объекты и расширять их с помощью делегаторов.Пример:

   var a = {};
   compositor.addDelegates(a,["validator", "accessManager", "databaseObject"]);
   

Таким образом, "класс" будет функцией с предопределенными делегаторами:

  function getInputObject(type, validator){
       var input = {};
       compositor.addDelegates(input,[compositor,renderable("input"+type),"ajaxed"]);
       if(validator){input.addDelegate(validator);}
       return input;
  }

Имеет ли это смысл?

Answer 1

1) Как я могу проверить, реализует ли объект определенное поведение?

Большинству людей не нужно проверять наличие методов, как это.

• Если вы хотите проверить методы для ветвления и выполнения разных задачесли он найден или нет, то вы, вероятно, делаете что-то плохое (этот тип instanceof обычно является запахом кода в ОО-коде)

• Если вы просто проверяете, реализует ли объектИнтерфейс для проверки ошибок, то это не намного лучше, чем не тестирование и выдача исключения, если метод не найден.Я не знаю никого, кто обычно делает эту проверку, но я уверен, что кто-то там делает это ...

2) Как бы я инициализировал объект, не повторяя всеустановка для составных объектов?

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

3) Есть ли потеря производительности, связанная с тем, что большинство функций, запускаемых в приложении, проходят через apply ()?

По моему опыту, я предпочитаю избегать работы с thisесли строго не нужно.this неудобно, разбивает внутренние обратные вызовы (которые я широко использую для итераций и асинхронных операций), и очень легко забыть установить его правильно.Я стараюсь использовать более традиционные подходы к композиции.Например:

1. Наличие каждого находящегося в собственности объекта должно быть полностью независимым, без необходимости смотреть на его братьев и сестер или владельца.Это позволяет мне просто вызывать его методы напрямую и позволять ему быть его собственным this.

2. Давая принадлежащим объектам ссылку на их владельца в виде свойства или в качестве параметраперешел на их методы.Это позволяет композиционным блокам получить доступ к владельцу без зависимости от правильной установки this.

3. Использование миксинов, выравнивающих отдельные композиционные блоки на одном уровне.У этого есть проблемы столкновения именитого имени, но позволяет всем видеть друг друга и разделить то же самое "это".Миксины также отделяют код от изменений в структуре композиции, поскольку различные разделы композиции будут по-прежнему сводиться к одному и тому же смешанному объекту.

4) Любые хорошие ресурсы?1050 *

Я не знаю, поэтому скажите мне, если вы найдете один:)