Недавно мне показали несколько плагинов JavaScript, написанных для разработчика мобильных приложений OBIEE, а также несколько пользовательских библиотек для различных проектов.
Исходя из опыта ООП, я немного запутался в структуре этих проектов. Я вижу файлы длиной в тысячи строк. Я привык разбивать вещи на файлы и классы, но я понимаю, что это другая структура - например, размер файла - это проблема, но должен быть лучший способ сделать все это?
Длина сценариев влияет не только на удобочитаемость и удобство обслуживания, но и на общее понимание человеком того, как работает программа.
Как структурированы большие приложения? Какие-нибудь общие модели ООП для этого?
Ответы:
Если вы не знакомы с шаблонами JavaScript, я могу вам сказать, что многие крупные приложения и библиотеки используют шаблон модуля Revealing , но есть много других шаблонов, которые вы можете использовать в зависимости от ваших потребностей.
Шаблон раскроя модуля, тем не менее, должен дать вам хороший способ разбить большие файлы и логически организовать их; Однако, когда вы работаете с любыми шаблонами проектирования в JavaScript, имейте в виду, что это может привести к путанице. Попробуйте использовать это , новый , прототип ,
.call()и с.apply()умом.Работая над большими проектами, они также могут быть полезны:
источник
Я разработчик C ++ и начал заниматься веб-разработкой в последнее время. Я портирую большое настольное приложение на веб-среду. Я структурирую свой код JavaScript точно так же, как структурировал код C ++, используя те же шаблоны. У меня всего около 25-30 файлов, но я со временем уменьшу их до 3-5, забивая по мере необходимости и минимизируя их все.
Для меня это просто язык, который изменился, к лучшему или к худшему, но не парадигма. JavaScript, со всеми его недостатками и разочарованиями, представляет собой хорошее сочетание функциональности и стиля ООП. Пока все хорошо работает.
Наконец, одна вещь, которую я осознал на раннем этапе, состояла в том, что JavaScript позволяет писать намного более лаконичный код, чем C ++, поэтому иногда наличие большого количества LOC, происходящих из не-JS-языка, может быть связано с тем, что он придерживается старого способа работы. Как только эта вещь решена, я не вижу ничего, что действительно должно быть другим. Дизайн и алгоритмы, в конце концов, не зависят от языка.
источник
Конечно, он сильно варьируется от проекта к проекту, но общепринятая практика заключается в том, что вещи, предназначенные для функционирования в качестве библиотек или модулей, помещают их в один большой файл и используют инкапсуляцию для предотвращения его внутреннего («частного») ) интерфейс от утечки наружу. Это также полезно для разработчиков, желающих использовать библиотеку / модуль - один файл для добавления в конфигурацию приложения или фрагмент заголовка вместо целой иерархии папок и файлов для копирования и вставки. Это также отражает тот факт, что при минимизации и группировании на рабочем сайте все это, скорее всего, будет объединено в один файл для уменьшения количества HTTP-запросов.
Ваш собственный код приложения не должен следовать этой практике, и, вероятно, не должен. Поскольку ваше приложение является единственным, использующим его, вам нужно всего лишь добавить файлы один раз, и, вероятно, вы можете рассчитывать на платформу, чтобы справиться с минимизацией и комплектацией.
источник
При работе над кодом различные компоненты обычно разделяются на модули, каждый из которых, как правило, реализует отдельный класс, и каждый из них находится в отдельном файле. В процессе производства эти файлы затем объединяются в один файл (отсюда тысячи строк кода, который вы видите), используя что-то вроде Browserify ( http://browserify.org/ ) или RequireJS, чтобы уменьшить количество HTTP-запросов, но и для того, чтобы зависимости загружались в правильном порядке
Что касается того, как реализованы классы для этих модулей, это немного отличается от ООП в базовой механике, но не так уж и отличается на первый взгляд. ES6 даже ввел
classключевое слово, поэтому оно должно выглядеть довольно знакомым. Эта статья о MDN полезна для начала: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chainисточник
Я использую (Petri) Net Elements и Annotations для организации или «структурирования» программного обеспечения для моих приложений в форме PDF - программ JavaScript, которые используют Acrobat / JavaScript API. Возможно, это может быть полезно в вашей ситуации.
Диаграмма используется для установления отношений ввода-вывода сетевых элементов и двух представлений формы аннотаций. Основываясь на диаграммах и видах форм, можно систематически создавать программы JavaScript для приложений форм PDF. Таким образом, «чтение» исходного кода сводится к проверке его соответствия спецификациям: диаграмме и двум видам формы.
В реализации моего программного обеспечения используются конструкторы и прототипы. Если производительность становится проблемой, то замена прототипов членами экземпляра может повысить производительность за счет увеличения использования памяти. Массивы также используются. Если производительность становится проблемой, то используются прямые ссылки.
Некоторые свойства создаются с помощью eval; для объектов с очень многими свойствами это уменьшит объем кода в исходном файле и уменьшит количество набираемых текстов программистом.
источник
Все еще возможно и рекомендуется писать JavaScript так, как вы привыкли. Вот хорошая книга, в которой рассматриваются наиболее важные шаблоны проектирования в JavaScript.
https://addyosmani.com/resources/essentialjsdesignpatterns/book/
Существует также множество JavaScript-фреймворков, основная цель которых - разделить код на разные файлы и модули. Если конкретный фреймворк, в котором вы работаете, требует, чтобы весь ваш код был в одном файле, то вам определенно стоит переключиться.
источник