Open FMRobot opened 9 years ago
Особо порадовало про "код сразу стал легко читаем" и чем дальше, тем сидишь и думаешь, штаааа. Для меня так наборот все стало китайской грамотой. Аж выбесило такое упрощение, которое из простого действия, сделало запуск баллистической ракеты. Не люблю когда упрощение сопутствует фразам учите матчасть,базовую шляпу. Упрощение это когда для дебилов понятно...
И да, я не дочитал, кинул в закладки, когда-нить вернусь чтобы осилить. А вы вот неправы. Плохие педагоги. Нехорошие. Как и все педагоги в этой стране )) Один я в пальто.
Не понравилось, очередное разжевывание. Манкипатчинг - зло.
Спасибо за статью, лично мне понравилось. Просто и понятно. Оцениваю свой уровень между junior & middle. Если отфильтровать брюзжание в комментариях, то есть интересные моменты.
Статья не про производительность и оптимизацию, а про показать разный подход в программировании на JS. Эту задачу решает :)
@bionicle12, согласен с вами на все 100%. :) Людям без понимания ООП будет сложновато. Но это не повод бросать статью!
Тут другая штука интересная! :) По этому принципу строятся множество фреймворков. Я уже упоминал выше Ext JS, Backbone и т. п. Освоив этот принцип один раз потом легче разобраться в любом из фреймворков, да и вообще в чем угодно... ООП используется и в других языках. Например PHP, Java. Везде подход очень похож, даже синтаксис имеет лишь незначительные различия.
Так что изучение данного принципа будет большим шагом вперед
@tonkado, благодарствую. :)
Критика тоже полезна, так что пусть эти толстопузые, высокомерные и тщеславные увольни и дальше брюзжат :)
P. S. Не имею ввиду никого конкретного. Выражаюсь художественным, абстрагированным языком с двусмысленными понятиями.
Ах-ах. Несмотря на то, что подход в целом интересный. И я даже кажется нашел задачу, в которой именно такой подход:
окажется более эффективным и выгодным с точки зрения общей архитектуры кода...
... но конкретно данный пример в статье синтетический и высосан из пальца. Попросту говоря, он не показывает никаких явных преимуществ перед подходами юниора или миддла, наоборот, запутывает ситуацию. Я подозреваю, изначально был написан "подход сеньора", а потом даунгрейжен до "нубовских" подходов.
Но укладывать всё приложение в прокрустово ложе "программирования классами" - идея ущербная и унылая. Впрочем, я готов взять свои слова назад, если автор покажет нам написанный "на классах" проект (не элементарную тудушечку, а что-нибудь помасштабнее).
@KarelWintersky, я уже писал о фреймворках, в которых используется такой подход. Если вы действительно заинтересованы, то сами найдете демки, написанные с использованием вышеперечисленных фреймворков.
Программировать классами это все равно что строить кирпичами :)
@vyushin как говорят в наших интернетах - "слив зощитан". А теперь разъясню: предложение "пойти посмотреть демки фреймворков" - это равнозначно посылу на три буквы. Потому что демки синтетические и очень далеки от реальной жизни. Хотя бы тем, что не показывают отрицательные стороны методологии, выпячивая положительные.
Да-да, "веб-сервер на ноде в 10 строк" и звучит и выглядит очень круто, но лично мне совершенно непонятно, в чем же профит?
@KarelWintersky, у меня есть хороший пример. Если скачать браузерное расширение Яндекс.Диска и посмотреть его код, то вы приятно удивитесь. Для удобства выкладываю уже распакованное расширение: https://yadi.sk/d/2bIfW1fAhZzg3
Советую начать с просмотра файла /background/main.min.js
Сори, вот актуальная ссылка: https://yadi.sk/d/tvLxtfCpha2aY
Советую начать с просмотра файла /background/main.min.js
зачем смотреть минифицированную часть?
@iamstarkov, что за странный вопрос? ) я обратил внимание не на минифицированную часть, а на основной файл расширения который написан с применением ООП — на примере реального проекта.
Из минифицированного кода сделать обычный можно одним кликом, например JSFormat для Sublime Text.
Советую начать с просмотра файла /background/main.min.js @ я обратил внимание не на минифицированную часть,
рилли?
Не нужно к словам придираться. Для кого-то проблема привести минифицированную версию к нормальному виду?
Рилли. Основной файл расширения — main.***.js
Отформатировать минифицированный код онлаин можно тут http://jsbeautifier.org/
Спасибо, поучительно.
Привет. Я сделал такой метод в коллекции
this.getProductsSearch = function(str) {
if(str.replace(/\s+/g, ' ').trim() == ''){
storage.forEach(function (item) {
jomresJquery('#product_id-' + item.getId()).show();
});
} else {
storage.forEach(function (item) {
if(~item.getId().indexOf(str) || ~item.getTitle().toLowerCase().indexOf(str.toLowerCase())){
jomresJquery('#product_id-' + item.getId()).show();
} else {
jomresJquery('#product_id-' + item.getId()).hide();
}
});
}
};
Это по фен-шую или так делают нубы? Или надо сделать чтобы метод возвращал коллекцию, потом я очищаю на странице старую коллекцию например через innerHTML = '' и с помощью appendTo добавляю новую? Еще думаю сортировку делать, но там вроде так просто как с поиском не получится, а надо пилить как я описал выше? Или всё х*ня и начинать по новой, тогда как?
@krontill смешана логика с представлением, не круто.
Идея предоставить три варианта решения (джуниора, мидла, сеньора) гениальна! Вот если бы все задачи разбирались подобным образом
В примере:
String.prototype.clearing = function() { return this.replace(/\s+/g, ' ').trim(); }
скрыта опасность, если уже создавать методы в прототипе, то писать с проверкой
String.prototype.clearing = String.prototype.clearing || function() { return this.replace(/\s+/g, ' ').trim(); }
Поясните нубу зачем в конструкторе явно возвращать return this; ?? Ведь вызов конструктора по умолчанию и возвращает новый объект с данными, записанными в конструкторе посредством this.
Также стоит отметить, что расширять прототип новыми функциями следует осторожно, нужно делать это ДО вызова нового метода у экземпляра.
@Pentaprizm незачем, в JS это не имеет вообще никакого смысла. А программистов, знакомых с языками, в которых есть конструкторы - это введёт в ступор.
@Pentaprizm, Согласен, что можно не указывать return из конструктора, но можно и указать — это не является ошибкой.
На мой взгляд хорошим тоном является, когда функция или метод что-либо возвращает и когда это явно видно. Я всегда пишу ф-ции и методы так, что они что-нибудь да возвращают. Если нет каких-то конкретных данных, то я возвращаю this. Это у меня выработано до автоматизма, так что в конструкторах тоже пишу return.
Скатились в преждевременную оптимизацию круглого коня в вакууме :)
А задача изначально мутная. Зачем рассчитывать цену со скидкой на стороне клиента? Другой динамики не вижу, как-то: вывод тут же оригинальной цены; выбор условий покупки и следовательно динамический процент скидки: нет аякса для днеобходимости динамической сборки. В таком случае лучшая оптимизация - вообще не использовать JS. Нет кода на стороне клиента - нет проблем оптимизации. Это как бы по данному круглому коню :)