даже «автор ООП» аккуратно вставил «quite». но Вы считаете, что только абстракция? окей. есть я, банкомат и деньги. зачем мне обращаться к банкомату и авторизовываться, не легче ли мне просто взять деньги? именно по-этому а) мои знания о системе ограничиваются банкоматом б) деньги инкапсулированы в банкомате
> я против использования для этого кривых, неполноценных способов…
извиняюсь за демагогию, но под этими способами подразумевается локальная переменная. соответственно, когда все методы и все свойства наружу торчат, это «полноценность?»
>… которые в любом случае не решают поставленную задачу на 100%
а в чем задача? скрипт написать? или системку, которая будет удобна в изучении, изменении и переписывании?
> знак подчеркивания
Вы считаете, что единственный смысл инкапсуляции — скрыть значение переменной? тогда сказать пользователю: «не трогай эту переменную!» — вполне достаточно, спорить не с чем. она нужна, насколько я могу понять, чтобы работать было удобнее.
надо проводить грань скриптованием и ООП. в т.ч. инкапсуляция, имхо, как раз лежит на этой грани.
только терминология
определение "структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту" реализуется совершенно иначе, и добавление новых методов противоречит сути декоратора
JS — язык удивительно гибкий, предоставляющий средства для решения множества типов задач. причем, гибкий настолько, что в его названии присутствует слово «script» (сценарий), а мы рассуждаем об инкапсуляции.
конечно, СНЯПом его именуют благодаря ярко выраженной специфике (утиная типизация, нативное прототипирование) и области применения. onclick'и, location.href и CSS-всегда-под-рукой никак не способствуют «каноническим» решениям повседневных задач — но позволяют добиться того, чего надо в кратчайшие сроки. и все бы хорошо, но…
… никто не хочет вызубрить работу с DOM'ом и всю жизнь только «дивы двигать». мы хотим более разнообразные задачи и более внушительным оклад. ООП! Оно и мозги расшевелит, и в технологи переведет.
Но и тут нам мало. Мы не хотим понимать, что такое ООП, мы хотим послушать, что о нем говорят наши коллеги и, сделав свои выводы, употреблять это слово в статьях, в резюме, в общении.
Года полтора назад я твердо заявлял: «Я знаю ООП!» Потому что я пользовался объектами и оператором new. Кастомный скроллинг с ноля? не вопрос, 8 часов, а если попрет, то вдвое меньше. Создать slider с кучей настроек, удобным API и гибкой взаимодействующей версткой — да пару дней, вместе с документацией и кучей рабочих примеров. Если я делаю такие сложные вещи (мне тогда так казалось) так быстро, используя new и объекты, то, само собой, я знаю ООП.
А потом мне попался калькулятор один. Сам бы я его не осилил просто. Писал я его под диктовку проект менеджера с 15 годами опыта в C++. День на третий я понял, что ООП это следствие развития науки со стажем многократно превосходящим срок жизни clien-side и обогатившейся за счет множества людей, даже более продвинутых, чем ПМ с 15 годами опыта в C++. Что я знаю об ООП? Ничего. Могу ли я, не понимая сути предмета, делать свои выводы? Наврядли.
сейчас про ООП я знаю не многим больше, чем тогда. но я могу с уверенностью сказать следующее: не поняв зачем нужна инкапсуляция, не стоит отвергать её из-за специфики.
Специфика это то, что накладывается на основу.
Не стоит и проводить тесты скорости, доказывающие только преимущество прототипирования. Рассуждать о плюсах и минусах инкапсуляции в ООП, это как рассуждать о пользе почки в своем теле. Можно рассуждать лишь о применимости инкапсуляции в JS, не прибегая к таким словам, как «ООП», «наследование», «декоратор» (в комментах был), «private», «protected», «public» — это слова из совершенно другой оперы.
аллоу, какие «шашечки или ехать»? статья называется «Реализация паттерна декоратор на JS», неужто она должна быть про анимацию, или абстракцию алгоритма?
а смысл создавать велосипед, который копирует нативный фукнционал?
server-side JS, конечно, да, не поспоришь, но вещь в наших краях редкая.
может, подумать в сторону расширяемости какой-нибудь, ну там сравнение ссылок, еще чего-нибудь придумать?
да, единственный способ заставить объект работать — вызвать его метод (сообщение передать). когда мы говорим классу: «new» — нам возвращается новый объект. чтобы упростить устное общение с коллегами по цеху, придумали слово «наследование». и прочую кашу другие понятия.
> по ходу действия он может все что хочет делать с сообщением
если делегирование работает как декорирование (их вообще этично сравнивать?), то не лучше так его и назвать?
> глобальный объект… чтобы определить новый класс
процентаж употребления этого метода при работе с глобальной областью видимости больше 10?
> Интересное значение, раньше не встречал.
согласен, но из контекста понятно, что человек имел ввиду
> слишком мало общего с JS
да, именно это я имел ввиду
> Я уже аргументировал
простите, но с моей точки зрения, его контр-аргументация убедительна, только на кодосрач зря скатились (оба)
> повторяет чьи-то истины
2) только я куда больше обеспокоен «мнением» xaja (первый коммент в ветке)
1) наврядли кто-то из комментаторов внес вклад в развитие программирования, как науки ;) но возможно, что Вы повторяете более продвинутые истины.
> кучка идиотов возводит шоблончеги в божество какое-то
тут надо учесть контекст сегодняшнего клиент-сайда. это готовые плагины для jQuery (копипаста 2.0), на этом «культура» клиент-сайда начинается и заканчивается. очень хорошо, что люди задумываются о гибкости своих разработок, понимают что если продукт работает, то это еще ничего не говорит о его качестве. даже их бездумное применение принесет для JS очень много пользы.
есть несколько, уже упомянутых, понятий: делегирование, декорирование, наследование. они, правда, в разных весовых категориях, но можно взять абсолютно любой код, выдрать из него ± любой кусок и сказать: «здесь употребляется (делегирование|декорирование|наследование)».
только если делегирование дополняет функциональность (логирование и иже с ним не считаем), оно ближе к декорированию. если делегирование создает объект и перезаписывает его методы, оно ближе к наследованию.
передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
// да, я не говорю, что просто код это плохо по определению
синтаксис, я так понимаю, применялся в значении «реализация на конкретном языке». сходства у любых языков имеются.
я так и не понял, почему у ap3rus'а мозг гладкий? я даже готов признать, что мой мозг маленький и гладкий, есть Вы доступно, с толком, с расстановкой это аргументируете
> я против использования для этого кривых, неполноценных способов…
извиняюсь за демагогию, но под этими способами подразумевается локальная переменная. соответственно, когда все методы и все свойства наружу торчат, это «полноценность?»
>… которые в любом случае не решают поставленную задачу на 100%
а в чем задача? скрипт написать? или системку, которая будет удобна в изучении, изменении и переписывании?
> знак подчеркивания
Вы считаете, что единственный смысл инкапсуляции — скрыть значение переменной? тогда сказать пользователю: «не трогай эту переменную!» — вполне достаточно, спорить не с чем. она нужна, насколько я могу понять, чтобы работать было удобнее.
надо проводить грань скриптованием и ООП. в т.ч. инкапсуляция, имхо, как раз лежит на этой грани.
определение "структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту" реализуется совершенно иначе, и добавление новых методов противоречит сути декоратора
конечно, СНЯПом его именуют благодаря ярко выраженной специфике (утиная типизация, нативное прототипирование) и области применения. onclick'и, location.href и CSS-всегда-под-рукой никак не способствуют «каноническим» решениям повседневных задач — но позволяют добиться того, чего надо в кратчайшие сроки. и все бы хорошо, но…
… никто не хочет вызубрить работу с DOM'ом и всю жизнь только «дивы двигать». мы хотим более разнообразные задачи и более внушительным оклад. ООП! Оно и мозги расшевелит, и в технологи переведет.
Но и тут нам мало. Мы не хотим понимать, что такое ООП, мы хотим послушать, что о нем говорят наши коллеги и, сделав свои выводы, употреблять это слово в статьях, в резюме, в общении.
Года полтора назад я твердо заявлял: «Я знаю ООП!» Потому что я пользовался объектами и оператором new. Кастомный скроллинг с ноля? не вопрос, 8 часов, а если попрет, то вдвое меньше. Создать slider с кучей настроек, удобным API и гибкой взаимодействующей версткой — да пару дней, вместе с документацией и кучей рабочих примеров. Если я делаю такие сложные вещи (мне тогда так казалось) так быстро, используя new и объекты, то, само собой, я знаю ООП.
А потом мне попался калькулятор один. Сам бы я его не осилил просто. Писал я его под диктовку проект менеджера с 15 годами опыта в C++. День на третий я понял, что ООП это следствие развития науки со стажем многократно превосходящим срок жизни clien-side и обогатившейся за счет множества людей, даже более продвинутых, чем ПМ с 15 годами опыта в C++. Что я знаю об ООП? Ничего. Могу ли я, не понимая сути предмета, делать свои выводы? Наврядли.
сейчас про ООП я знаю не многим больше, чем тогда. но я могу с уверенностью сказать следующее: не поняв зачем нужна инкапсуляция, не стоит отвергать её из-за специфики.
Специфика это то, что накладывается на основу.
Не стоит и проводить тесты скорости, доказывающие только преимущество прототипирования. Рассуждать о плюсах и минусах инкапсуляции в ООП, это как рассуждать о пользе почки в своем теле. Можно рассуждать лишь о применимости инкапсуляции в JS, не прибегая к таким словам, как «ООП», «наследование», «декоратор» (в комментах был), «private», «protected», «public» — это слова из совершенно другой оперы.
Вы уверены? т.е. Вы сможете привести пример ООП программы, даже без абстракции (набора объектов)?
про такие ограничения лучше сразу говорить, пусть и можно перевесить обработчик выше
так было бы куда честнее:
function clearFileInputField(Id) { document.getElementById(Id).parentNode.innerHTML += " "; }u.catalogues // [«somepath», «relative», «path»]
еще можно mailto проработать, к нему можно в get-параметрах тему и текст сообщения передавать
и есть псевдопротоколы, вроде magnit или javascript, для них наверняка можно что-нибудь полезное придумать
server-side JS, конечно, да, не поспоришь, но вещь в наших краях редкая.
может, подумать в сторону расширяемости какой-нибудь, ну там сравнение ссылок, еще чего-нибудь придумать?
прочую кашудругие понятия.> по ходу действия он может все что хочет делать с сообщением
если делегирование работает как декорирование (их вообще этично сравнивать?), то не лучше так его и назвать?
> глобальный объект… чтобы определить новый класс
процентаж употребления этого метода при работе с глобальной областью видимости больше 10?
согласен, но из контекста понятно, что человек имел ввиду
> слишком мало общего с JS
да, именно это я имел ввиду
> Я уже аргументировал
простите, но с моей точки зрения, его контр-аргументация убедительна, только на кодосрач зря скатились (оба)
> повторяет чьи-то истины
2) только я куда больше обеспокоен «мнением» xaja (первый коммент в ветке)
1) наврядли кто-то из комментаторов внес вклад в развитие программирования, как науки ;) но возможно, что Вы повторяете более продвинутые истины.
> кучка идиотов возводит шоблончеги в божество какое-то
тут надо учесть контекст сегодняшнего клиент-сайда. это готовые плагины для jQuery (копипаста 2.0), на этом «культура» клиент-сайда начинается и заканчивается. очень хорошо, что люди задумываются о гибкости своих разработок, понимают что если продукт работает, то это еще ничего не говорит о его качестве. даже их бездумное применение принесет для JS очень много пользы.
только если делегирование дополняет функциональность (логирование и иже с ним не считаем), оно ближе к декорированию. если делегирование создает объект и перезаписывает его методы, оно ближе к наследованию.
передача вызовов в глобальный объект в 90% (не 100%, только 90%) случаев, имхо, скорее просто код безо всякой архитектуры. согласны?
// да, я не говорю, что просто код это плохо по определению
я так и не понял, почему у ap3rus'а мозг гладкий? я даже готов признать, что мой мозг маленький и гладкий, есть Вы доступно, с толком, с расстановкой это аргументируете