На сколько жива концепция модульного програмирования, и что можно сделать с помощью ООП?
Я только начинаю делать маленькие вещи на JS, и сделал простой календарь, и нужны ответы от людей, опытных в веб. разработке на несколько вопросов!
календарь
Я прекрасно понимаю, что читать полностью и вникать в весь код никто не будет (пустая трата времени), НО прошу ваших ответов на более концептуальные вопросы:
- При данном функционале календаря (думаю он прост) как можно реализовать ООП? Понятия не имею досих пор что есть ООП в JS? На 99.9999% ресурсов создаётся объект
personи с помощью классаPerson, поэтому мне не очень понятно как применять ОПП в JS для создания проектов, которые не несут в себе обращение с пользовательскими данными, быть может вы просто подадите идею в стиле "сделать календарь объектом, у которого свойства это стили, а методы это создание различных блоков, и применение к ним стилей" ?! - Модульный подход . . . Если не вдумываться в
JSкод, то вы заметите, что данный календарь сделан на чистомJS, изHTMLтам только контейнер, в который мы просто вставляем календарь (можно прописатьdocument.body. . .при создании модуля, и тогда html вообще не понадобится), и он либо принимает размеры контейнера, либо мы сами в объектеconfigзадаём параметры календаря, так вот, насколько эта практика используется в реальных проектах? Ну например, я сейчас делаю todo лист и у меня загвоздка, поэтому я сделал этот календарь, чтобы в будущем его просто вставить модулем в этот todo . + Есть в том-же календаре элементы, типо 41го див блока в которых отображаются числа месяца, которые на мой взгляд бы было глупо прописывать вhtml, поэтому проще сделать это циклом (ну на мой субьективный взгляд) - В чем профит использования ООП перед модульно - процедурном подходом, т.к. по сути мой модуль это тоже приватная единица, которой не нужны внешние данные, и она не изменяет их, все переменные будут локальными в модуле, вставил в свой проект, настроил (настройки в проекте сделаны пока чисто формально, можно сделать хоть толщину и стиль рамки этого календаря офк) и забыл? И не много ли у меня кода для простого календаря?
- Как можно найти проекты людей (не большие типо слайдеров, калькулейторов, календариков, тудушек), код которых действительно написан грамотно? (я к тому, что не просто нарваться на популистскую статью типо "как сделать крутой слайдер в js, или делаем суууперпростой калькулятор для новичков") Дело в том, что И Я могу запостить на хабре свой календарь, НО его во первых засмеют, а во вторых недайбог найдутся те, кто возьмёт что-то для себя из него на заметку, быть может на гитхабе (пока ещё ниразу не пользовался этим сайтом) есть подобное, из раздела НЕ мусор для новичков, с примерами правильного ООП, мудульного програмирования?
Ответы (2 шт):
Боюсь, вы не найдете каноничных примеров ООП в приложениях написанных на javascript.
Javascript не самый удачный выбор для изучения ООП, т.к. классы в этом языке всего лишь синтаксический сахар над функцией-конструктором и prototype объектом.
Надо понимать, что под каждым языком программирования лежит определенная философия, понимание того для решения каких задач данный язык был создан и нацелен. Изначальная цель создания JS - написание небольших скриптиков на пару десятков строк, внедренных в HTML страничку. И это всё на что был, так сказать, замах.
Отсюда проистекает динамичность this, слабая типизирование, наличие глобальных переменных, hoisting, coercion и проч. и проч. Но волею судеб данный язык на хипстерской волне превратился в универсальный инструмент для написания всего спектра прикладных программ. То есть, изначально была придумана и создана "пилка для ногтей", а превратилась она в нечто на чем запустили конвейер по выпуску автомобилей.
На конвейере работают бригады рабочих, а программы пишут на галерах джуны, мидлы и сеньоры. Изначально интерпрайз-галеры гребли с помощью вёсел типа Java, C++ и C#. Данные весла повлияли на культуру и технологию создания конечного продукта, которая во многом базируется на применении ООП.
И тут в интерпрайз ворвался нечесаный, со стаканчком из старбакса весь такой модный JS... И "пилку для ногтей" стали переделывать, точнее обвешивать необходимым, чтоб этим можно было хоть как-то коллективно и по команде продакт-менеджера грести.
Такая вот информация к размышлению.
Вопросов много, а в JS я не эксперт, поэтому отвечу что знаю.
3. ООП vs Модульность
ООП и модульность действительно имеют сходство, но можно сказать, что ООП – это развитие модульности. В ООП есть 4 базовых принципа:
- Абстракция
- Инкапсуляция
- Наследование
- Полиморфизм
А модульность это только инкапсуляция и возможно в какой-то мере абстракция. Без наследования и полиморфизма, а профит в них есть – повышение адаптивности кода и его переиспользования.
Однако здесь стоит смотреть на код в разном масштабе. Когда вы используете какие-то структуры данных и алгоритмы, или взаимодействие по сети с кучей настроек, или моделируете физический мир с визуализацией, то здесь пригодится объектно-ориентированное программирование во всей красе. Но на масштабе выше, особенно по части GUI (например, JavaBeans) и особенно в вебе, популярна разновидность ООП – компонентно-ориентированное программирование (КОП).
2. Модульность в JS
Есть популярные фреймворки для фронтэнда – Angular, React, Vue. Насколько я знаю, они все придерживаются КОП, и делают это очень хорошо. Вы можете создать какой-нибудь компонент, в котором будет сразу HTML, CSS, JS (например, форму ввода пользовательской инфы), поместить внутрь него чей-то чужой компонент (например, красивое поле ввода email), и свой компонент положить ещё в чей-то чужой компонент (на страницах регистрации и редактирования юзверя). При этом, компоненты могут передавать друг другу какие-то значения и настройки, а их комбинация и настройка происходит гораздо проще и следовательно быстрее (на радость дизайнерам), чем традиционная модульность, где вручную создаваётся большая каша из HTML, CSS, JS и настроек всех элементов страницы.
Кстати, средние и крупные компании зачастую регламентируют используемые фронтэнд технологии (т.е, выбирают один из упомянутых фреймворков) и создают внутренние реестры компонентов, чтобы разработчики не тратили время на создание велосипедов, а дизайнеры общались с разрабами на одном языке.
Так выглядит современная модульность, точнее ООП, а ещё точнее КОП, в клиентском JS. Но учтите, что это на масштабе дизайна и UI, если же вам нужны какие-то сложные алгоритмы, то вполне может пригодиться традиционное ООП (к слову, в основе JS лежит его разновидность – прототипное программирование).
4. Примеры
Примеры ищите в первую очередь на GutHub, а также можно смотреть по ключевым словам в реестре пакетов JS – NPM. Но здесь знатоки современного JS подскажут лучше.
Из книг присоединяюсь к рекомендации про "Совершенный Код" Стива Макконелла, а также советую найти хороший современный учебник по одному из упомянутых фреймворков, если интересует развитие в направлении фронтэнд разработки.