Я зробив собі боляче класами.
Що мені подобається в JavaScript, так це можливість писати код як в чисотму ООП стилі, так і суто в функціональному. А для поціновувачів є можливість змішувати обидва підходи.

Зараз я працюю над однією цікавою задачею — переношу графік з монолітного репозиторію в окреме репо для графіків. Рендеряться вони, очевидно, за допомогою d3. І от в тому репозиторії усі графіки зроблені класами. Очевидно, спочатку я вирішив — чому ні? Дай-но я й собі свій графік зроблю красивим класом.

І мене підвело саме це бажання, зробити усе красиво, з розділенням відповідальностей, з інʼєкцією залежностей, оце все. Я витратив два дні, намагаючись правильно виокремити клас-композер, клас для даних, клас-рендерер. Чому витратив?

По-перше, я вже сто років не писав щось складніше кастомного компонента. По-друге, я просто загубився в тому, що саме і куди класти. Мої пошуки ідеального розділення відповідальностей постійно гальмувалися розумінням, що мені треба усе дрібніші класи з вузькими задачами. А ще ж треба забезпечити взаємодію між екземплярами, щоб дані оновлювались, ререндер відбувався, графік перемальовувався.

І тут до мене прийшло розуміння — проблема не в моєму знанні ООП. Вона полягає в тому, що цей підхід просто надмірний для такого роду задачі. Те, над чим я бодався два дні, і так і не наблизився до завершення, вдалося зробити буквально за пів дня за допомогою простого функціонального підходу. Я просто наплодив невеличких функцій, скомпонував де треба, і маю чудову, просту й легку систему, яка робить рівно те, що мені треба: отримує дані, обчислює необхідні стани та генерує відповідний SVG.

І тут може скластися хибне враження, що ООП підхід безбожно застарів. Однак, на мою думку, це далеко не так. Радше спростилися задачі й необхідні для них підходи. ООП усе ще набагато потужніший за функціональний підхід, якщо ви проєктуєте складну систему, яка повинна працювати як годинник. Однак це потребує доволі багато зусиль, бо, як я раніше писав, навіть невеличкий модуль на пару класів уже потребує додаткових систем життєзабезпечення, аби сутності працювали разом.

З функціональщиною усе простіше — засунув зверху дані, вони пройшли мʼясорубку вашої композиції, на виході маємо якийсь детермінований результат. І саме цей підхід у фронтенді покриває більшість задач. Але не всі.

З усього цього я, правда, зробив висновок, що це не ООП поганий, а мені варто покращити й підтягнути свої знання в ньому. Буду відвертим, мене дуже дратувало те, що я не міг просто й прозоро скласти в голові таку собі діаграму класів та описати для себе, як вони спілкуються.

Ну і очевидно, черговим уроком стало те, що треба вміти чітко розуміти масштабність та складність задачі наперед, щоб обирати підхід, який забезпечить максимум результату за мінімум часу.

Так, ця задача стала для мене цікавим експериментом, нагадала, що я доволі непогано знаю класовий синтаксис та деякі особливості роботи класів в JS, а от саме ООП уже дещо стерлося з моєї памʼяті. І саме тому мені варто його підтягнути, замість переконатись, що воно "не працює". Воно працює, і працює чудово, просто не треба намагатися копати лунки для розсади промисловим екскаватором.

Цей дослід нагадав мені: ключ не в тому, який підхід "правильний", а в тому, наскільки інструмент відповідає масштабу задачі.

@babichdev

#думки_вголос