Насколько оправдан ООП на стороне клиента?
 

Хотелось бы услышать мнения гуру.

На данный момент я это дело вижу так...

На стороне клиента нет никаких оснований писать ООП код, максимум - процедурное программирование. Ибо он не столь сложен ( ошибаюсь ? ) и во вторых есть тот же jQuery упрощающий работу с DOMом донельзя.

Как оно складывается на практике?

Стоит ли уходить в тонкости JavaScript? Или же сэкономить время и потратить на тонкости серверного кодинга ( PHP + MySQL ) ?

Ответ: Насколько оправдан ООП на стороне клиента?
 

Если это 150 строк JS, то конечно городить супер структуры - не стоит.

Всё зависит от ситуации. Я лично предпочитаю модульность, и если знаю что мне пригодиться что-то из данного решения - я пишу модуль и делаю его само-достаточным, затем юзаю где нужно и потенциально в будущем.

В то же самое время "почему нет"? Никто не запрещает писать ООП код, и он не сложнее а порой проще когда привыкаешь к рутине. Следственно какие будут аргументы писать не ООП код.

Имхо, но код должен быть чистым, а красиво оформленные объекты с классическим наследованием (prototype) проще говоря OOP, где каждый метод максимум 20 строк кода - вот это красиво. Удобно и легко читается. Разобраться в таком коде проще, т.к. ООП приводит к абстракциям которые помогают разрбраться и структурировать код.

Ответ: Насколько оправдан ООП на стороне клиента?
 

Если ооп и не обязательно, то следовать паттернам ОБЯЗАТЕЛЬНО. Гугл MVP/MVVM. Рекомендую взглянуть на knockout.js (mvvm паттерн).

Ответ: Насколько оправдан ООП на стороне клиента?
 

>oop
>js
:super:

собсно зачем использовать ооп (mvp, mvvm, %подставь_свой_любимый_паттерн%) там где его можно не использовать ? вот наглядный пример http://habrahabr.ru/post/153225/

очень нравится наблюдать за эволюцией программиста, сначала он ковыряет что-то без понимания, потом он находит книжку с паттернами и просто обмазывается ими как герой из зелёного слоника, потом до него приходит немного понимания, потом он открывает что существует больше чем одна парадигма программирования, потом к нему приходит немного мудрости (это лет так через 5), потом он смотрит https://vimeo.com/71278954, и пооотооом он чуть-чуть что-то понимает :crazy:


(программист с 10 лет опыта)

так что KISS, и не еби мозги ни себе, ни js движку, ни заказчику, ни тому кто будет твой код сопровождать потом :crazy:

Ответ: Насколько оправдан ООП на стороне клиента?
 

А в чём приципиальное влияение клиентскости/серверности на необходимость юзания ООП ? От задач всё зависит же.

Ответ: Насколько оправдан ООП на стороне клиента?
 

И всё верно говоришь jimon, только последняя фраза:
Тут прибегает студент с книжкой паттернов и говорит: "Да всё просто, это же Dependency Injection а тут у нас Singleton'чик и пару Menager'ов"... Тяжело расценивать свои способности самому, самокритика у программистов - вообще гиблое дело. Тебя могут только рассмотреть другие кодеры работая с тобой, но сам, уж нет.
И тут же прибегает Functional JS гик, и говорит: "Зачем городить всю эту ересь с ООП и евентами, давай всё в один flow запихнём, так же проще понимать!". Кода в 2 раза больше, и абстракций нет, следственно чтобы изучить работу кода нужно погрузиться почти во все аспекты его работы.. Но он на это так не смотрит.

Пиши как пишешь, и верно Брет сказал: Знай что ты нихера не знаешь - будь свободен.
Эксперементируй, не ищи догмы у других, пол рашки так в религию подались им же нужен был ответ на их вопросы. Заместо того чтобы искать его самому и не суть в нахождении ответа, суть в поиске.

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

Ответ: Насколько оправдан ООП на стороне клиента?
 

Типичное чуство новичка : А вдруг я программирую неправославно?

За советы - спасибо. Похоже я действительно совокупляюсь с мозгом =) иногда бывает...