Comments 47
что мешает вообще все методы засунуть в конфиг и обрести тем самым невъебенную расширяемость? ой, да это же получатся классы и их наследование! поздравляю с велосипедом х)
Много очевидных вещей описываете.
Говоря о jQuery, считаю лучшей практикой оформлять код в виде плагина.
Говоря о jQuery, считаю лучшей практикой оформлять код в виде плагина.
> считаю лучшей практикой оформлять код в виде плагина
Вот уж воистину, а то потом замучаешься рефакторить.
Вот уж воистину, а то потом замучаешься рефакторить.
Позволю не согласиться, т.к. нужно как минимум знать, как называются все другие плагины, ипользуемые в проекте: коробочные, написанные вами, написанные другими разработчиками.
Плагины выполняют каждый свою задачу. То, как объекты взаимодействуют (а это по большей части именно то, что вы программируете), плагином быть не должно, имхо. Хотите дублировать функционал, создавайте глобальные расшаренные объекты, прикручивайте к ним нужные методы.
Плагины выполняют каждый свою задачу. То, как объекты взаимодействуют (а это по большей части именно то, что вы программируете), плагином быть не должно, имхо. Хотите дублировать функционал, создавайте глобальные расшаренные объекты, прикручивайте к ним нужные методы.
Конечно вы вольны не соглашаться, но указанные вами доводы не выглядят убедительными.
Вам в любом случае не помешало бы знать названия плагинов которые вы используете. К тому же я не вижу разницы — запоминать названия плагинов или имена объектов, объявленных в глобальном пространстве имён.
То что я программирую плагином быть не должно? А что должно быть плагином?
Описанный автором элемент интерфейса ни что иное как двухуровневая панель вкладок. Разве не работа плагина на основе HTML структуры создать для пользователя удобный элемент навигации? Выходит, что этот объект просто выполняет свою задачу и ни как не взаимодействует с другими.
Вот если бы автор описал некий объект Boy и объект Girl, которые каким-либо образом взаимодействуют между собой, тогда правда ваша, тут плагинам не место.
Вам в любом случае не помешало бы знать названия плагинов которые вы используете. К тому же я не вижу разницы — запоминать названия плагинов или имена объектов, объявленных в глобальном пространстве имён.
То, как объекты взаимодействуют (а это по большей части именно то, что вы программируете), плагином быть не должно, имхо.
То что я программирую плагином быть не должно? А что должно быть плагином?
Описанный автором элемент интерфейса ни что иное как двухуровневая панель вкладок. Разве не работа плагина на основе HTML структуры создать для пользователя удобный элемент навигации? Выходит, что этот объект просто выполняет свою задачу и ни как не взаимодействует с другими.
Вот если бы автор описал некий объект Boy и объект Girl, которые каким-либо образом взаимодействуют между собой, тогда правда ваша, тут плагинам не место.
Даже в панели вкладок нужно, к примеру, связать подсвеченную вкладку с текущей открытой вкладкой.
Чаще всего, создавая свои плагины мы создаем универсальный разводной ключ… из дерева.
Чаще всего, создавая свои плагины мы создаем универсальный разводной ключ… из дерева.
Может вы опишите те случаи когда плагины нужны, а когда нет.
Исходя из ваших комментариев кто-то сделает ошибочный вывод, что плагины — зло, а все блюда надо готовить из объектов в глобальной кастрюле.
Исходя из ваших комментариев кто-то сделает ошибочный вывод, что плагины — зло, а все блюда надо готовить из объектов в глобальной кастрюле.
Нет-нет, что вы! Плагины — отличная вещь. Просто не надо все подряд оформлять в виде плагина.
Вот и я о том же =)
В данном конкретном примере плагин был бы в кассу, в каких-то других случаях правильнее было бы использовать классы или object literals
В данном конкретном примере плагин был бы в кассу, в каких-то других случаях правильнее было бы использовать классы или object literals
В данном конкретном сулчае про jQuery и библиотеки лишь упоминание чтоб не писать длинные примеры, речь не о библиотеках, речь о стиле написания программ, не важно на jQuery вы пишете или на mootools, так что каменты о плагинах здесь не совсем уместны.
А случаи когда плагины уместны а когда нет определить в двух словах просто:
Код независим? Да, можно вынести в плагин: Нет, есть связь, в плагин выносить нельзя.
А случаи когда плагины уместны а когда нет определить в двух словах просто:
Код независим? Да, можно вынести в плагин: Нет, есть связь, в плагин выносить нельзя.
Не пробовали MooTools?
А какая связь между затронутой темой и MooTools?
Реализация классов в MooTools намного более продвинутая. Если собираетесь писать в ООП стиле — MooTools намного лучше jQuery.
Ничего, они будут плохой код писать, а мы будем чинить… За деньги ;)
иногда их код не хочется чинить ни за какие деньги =(
Здесь же по сути не в классах дело как таковых, а, грубо говоря, в группировке кода, с этим, у меня например, прекрасно справляются обьекты типа как из первого примера. Если делать все обдумав хорошо то писать в стиле ООП не такая уж и важная вещ, главное думать когда пишешь.
JS проповедут прототипное ООП, вставлять классовые костыли — не гут. Учите язык и его возможности.
habrahabr.ru/blogs/javascript/111393/ таки вы меня убедили написать топик.
хоть педали две и то радует.
Еще чуток довести до ума и дописать удобств и получатся классы аля Prototype/Mootools.
Прекрасная статья для таких новичков в js как я. И паттерн новый, очень приятно было почитать.
Этот паттерн называется ЧООП — черезмерно объектно ориентированное программирование. Здесь вместо того, чтобы менять тело функции при изменении требований заказчика, вы будете 1) придумывать, как называть параметр в конфиге, 2) менять структуру функций, чтобы они зависили от конфига, 3) рефакторить все остальное. И так при каждом хныке заказчика.
Такой подход мог бы помочь человеку с огромным опытом (знает, что будет и чего лучше) и хорошей памятью (помнит, что как и где работает). Новички не из таких.
Такой подход мог бы помочь человеку с огромным опытом (знает, что будет и чего лучше) и хорошей памятью (помнит, что как и где работает). Новички не из таких.
Для тех, кто не понял, то, что описано в статье не является паттерном. Object Literal — объектный литерал, синтаксическая конструкция языка программирования.
Это как называть «var a = 10» новым паттерном, избавляющем вас от необходимости написания «var a; a=10;»
Пихать ООП куда не надо — зло.
Это как называть «var a = 10» новым паттерном, избавляющем вас от необходимости написания «var a; a=10;»
Пихать ООП куда не надо — зло.
Про Object lteral вы конечно же правы, но всё же определитесь как надо было показанный пример реализовать, ато плагин неправильно, ООП тоже неправильно, а своих вариантов не предлагаете.
Вы не поверите, но то, как решать данный пример, лучше всего описано во втором листинге поста — там нет лишних плагинов и наворотов :)
Я бы лишь переписал небольшой кусок на случай, если вы захотите изменить место куда вставляется контент и урл. А вообще, лучше сразу в хтмл создать блок (и урл можно было бы на нем же прописать).
Я бы лишь переписал небольшой кусок на случай, если вы захотите изменить место куда вставляется контент и урл. А вообще, лучше сразу в хтмл создать блок (и урл можно было бы на нем же прописать).
jQuery(function ($) {
$('#myFeature li')
.each(function() {
$("<div class='content'/>")
.load('foo.php?item=' + $(this).attr('id'))
.appendTo(this);
}
.click(function() {
$(this).find('.content').show();
$(this).siblings().find('.content').hide();
});
});
Ну, не «паттерн». Я, честно говоря, не знаю как это правильно назвать. Если вы знаете — поправьте.
Для меня подобный метод удобен для структуризации UI кода по следующим причинам:
Конечно, кодга у меня появляется какой-то «стандартный» элемент типа галереи картинок, я создаю плагин для jQuery. Но если выбирать между плагинами, разрозненными функциями, обычными объектами new Object и Object Literal для описанного функционала, последние кажутся мне более уместными.
Для меня подобный метод удобен для структуризации UI кода по следующим причинам:
- Object Literal — он типа синглтон, и ему в подобном применении не нужны инстансы, и, скорее всего, наследование. По крайней мере у меня желание отнаследовать пока не возникало.
- Иногда бывает, что на одной странице происходит работа одновременно с несколькими подобными объектами (например когда есть стандартные блоки типа корзины или залогинивания). В этом случае Object Literal лучше просто разрозненных функций, потому что создаёт подобие namespace-ов. Типа:
PostUI.vote(-1), CartUI.add() и AuthUI.showLoginBox().
Конечно, кодга у меня появляется какой-то «стандартный» элемент типа галереи картинок, я создаю плагин для jQuery. Но если выбирать между плагинами, разрозненными функциями, обычными объектами new Object и Object Literal для описанного функционала, последние кажутся мне более уместными.
Это не синглтон.
Считайте, что
это сокращенная запись
Ему не нужны инстансы =) Он уже инстанс класса Object.
Подведем черту. Вы просто сгруппировали несколько функций под крышей одного объекта используя сокращенный синтаксис, т.к. вас не интересует создание класса.
var a = {};
var b = {};
alert( a == b); // false;
Считайте, что
var ob = {
i: 10,
method: function () { return this.i}
}
это сокращенная запись
var a = new Object();
a.i = 10;
a.method = function () {return this.i};
Ему не нужны инстансы =) Он уже инстанс класса Object.
Подведем черту. Вы просто сгруппировали несколько функций под крышей одного объекта используя сокращенный синтаксис, т.к. вас не интересует создание класса.
Оке :) Спасибо за разъяснение
Хотя не до конца, но я с TEHEK согласен. В данном случае автор просто использовал Hash как неймспейс и вся суть подхода свелась к тому, что все функции находятся в одном неймспейсе. Такой подход имеет рациональное зерно, но это далеко не откровение.
Ну здесь, на хабре, для опытных, много чего не откровение, но когда видишь такой код:
То удивляешься почему люди не используют такие «откровенные» подходы как описанный в данном топике.
var url = 'some.url';
var flag = false;
var isWorking = flase;
...
function func1(param)
{
if( isWorking ) return;
isWorking = true;
func2( param );
isWorking = false;
}
function func2(param)
{
// blah blah blah using variables flag and url
}
То удивляешься почему люди не используют такие «откровенные» подходы как описанный в данном топике.
Рекомендую посмотреть JavascriptMVC
Я почему-то тоже пришёл к такому паттерну, но пока не уверен, что это лучший вариант. По этому за статью — спасибо — буду знать, что не только я так делаю :)
Вообще в JS я начал углубляться недавно, до этого занимался только server-side программированием. И в описанной конструкции лично меня немного бесит необходимость обращаться к объекту по имени:
По этому в начале каждой функции у меня стоит присвоение self = this. Опять же, не знаю, насколько это правильно:
Кстати, объекты с этим паттерном у меня используется только для работы с интерфейсом и выполняют роль расширенного «контроллера» в терминах MVC, а операциями с данными не затрагивающми интерфейс (сохранение комментария, голосование) у меня выполняют т.н. «модели». Они проектируются в виде стандартных объектов и создаются в контроллерах:
Я посмотрел приведённую выше ссылку про JavascriptMVC и мне показалось это черезмерным усложнением. Буду рад если кто-то разъяснит его преимущество перед описанным автором статьи и мною методом организации JS-а. Может JavascriptMVC или подобный фреймворк становится необходим при создании полноценных JS-приложений?
Вообще в JS я начал углубляться недавно, до этого занимался только server-side программированием. И в описанной конструкции лично меня немного бесит необходимость обращаться к объекту по имени:
myFeature.buildSectionNav(myFeature.$sections);
По этому в начале каждой функции у меня стоит присвоение self = this. Опять же, не знаю, насколько это правильно:
self = this;
self.buildSectionNav(self.$sections);
...
$element.click(function() {
self.showContent($(this));
});
Кстати, объекты с этим паттерном у меня используется только для работы с интерфейсом и выполняют роль расширенного «контроллера» в терминах MVC, а операциями с данными не затрагивающми интерфейс (сохранение комментария, голосование) у меня выполняют т.н. «модели». Они проектируются в виде стандартных объектов и создаются в контроллерах:
vote: function(value) {
var self = this;
var voter = new Voter({model: 'blog.post', type: 'rating', id: this.post_id});
voter.vote(value,
function(data){ // Всё ок
self.$voter.find('.score')
.html(data.score)
.attr('title', 'Количетво голосов: ' + data.votes_count);
self.$voter.find('.vote').removeClass('voted');
self.$voter.find('.vote_' + (value + 3)).addClass('voted');
},
function(error){ // Ошибка
alert(error.message);
}
);
return false;
},
Я посмотрел приведённую выше ссылку про JavascriptMVC и мне показалось это черезмерным усложнением. Буду рад если кто-то разъяснит его преимущество перед описанным автором статьи и мною методом организации JS-а. Может JavascriptMVC или подобный фреймворк становится необходим при создании полноценных JS-приложений?
Да ё-мое, не успел… habrahabr.ru/blogs/javascript/111290/#comment_3551330
на счёт вредной привычки писать
Да. Пока создаёшь небольшие приложения, типа лёгкая динамика на сайте можно обойтись сырым процедурным подходом без всяких ухищрений.
var self = this я писал в статье Правильный захват контекста в JavascriptМожет JavascriptMVC или подобный фреймворк становится необходим при создании полноценных JS-приложений?
Да. Пока создаёшь небольшие приложения, типа лёгкая динамика на сайте можно обойтись сырым процедурным подходом без всяких ухищрений.
Я не люблю jQuery по той же самой причине, почему многие не любят php — нулевой порог вхождения.
С тем же успехом мы просто создали объект, напихали в него функций и т.д. Отличный объект. Старый подход. Но что делать при частичном изменении требований — вот тут так, а вот тут, где это же использовалось — иначе. Создавать новую функцию? Передавать параметр?
Поздравляю — как заметили выше — педали хоть и две, но руля не предусмотрено. На JS отлично реализуются паттерны DI и т.д.
Поздравляю — как заметили выше — педали хоть и две, но руля не предусмотрено. На JS отлично реализуются паттерны DI и т.д.
Может я не удачный пример привел. Если использовать JQuery, то данный пример действительно лучше оформить в виде плагина.
В данном случае фреймворк ни при чем.
Существует много разных подходов и все они имеют право на жизнь (главное избегать спагетти-кода).
В данном случае фреймворк ни при чем.
Существует много разных подходов и все они имеют право на жизнь (главное избегать спагетти-кода).
Автор, когда Вы делаете перевод, принято это указывать и размещать ссылку на оригинал, а иначе это плагиат. В данном случае, как я понимаю, Вы перевели http://blog.rebeccamurphey.com/2009/10/15/using-objects-to-organize-your-code.
Sign up to leave a comment.
Использование объектов для красивой структуры кода в JavaScript