Встречайте WebStorm 8: поддержка AngularJS, spy-js, интеграция Grunt и многое другое

Столкнулся с очень неприятным багом. При решении конфликтов с помощью визуального сравнения после решения всех конфликтов или при нажатии на cancel на доли секунды мелькает окошко с предложенем завершения и пропадает, после чего все окна становятся неактивными, их можно только перетаскивать, не удается даже закрыть.
ОС: OS X 10.9.2
Версия JDK изначально была 1.6.0, обновил до 1.8.0 проблема осталась. Проявляется как в версии шторма 1.8.0, так и в 1.8.1

Использование паттернов проектирования в javaScript: Порождающие паттерны

Отнаследованный можно, но что будете делать, если понадобится отнаследоваться от объекта singleton? Создавать обертку, которая будет содержать все методы объекта singleton, для переопределенных реализовывать новую логику, для сохранившихся вызывать метод сохраненного в обертке singleton? Это и называется менее гибко, какой объем работы надо будет проделать чтобы переименовать пару методов, а если наследников будет несколько? Можно еще конечно склонировать объект и переопределить нужные методы, но тут можно нарваться на грабли полного копирования объекта, т.к. поверхностное тут не подойдет, на которое можно потратить немало времени и между прочим по вычислительным ресурсам это тоже выйдет не самая легкая операция, вместо того чтобы ипользовать функции-констркуторы и прототипное наследование.

Использование паттернов проектирования в javaScript: Порождающие паттерны

Ну, что-то в этом есть, но опять же дело вкуса. Называете класс CurrentUserSingleton и проблем точно не будет

Использование паттернов проектирования в javaScript: Порождающие паттерны

Текущий пользователь всегда один, и если описан класс именно для текущего пользователя, то создание объекта каждый раз при необходимости считать его данные, подтягивание данных из бд, и т.д. просто расточительно. В то же время при сохранении единого объекта и экономии ресурсов мы сохраняем страрый привычный интерфейс создания объекта. Повторю: речь именно о текущем пользователе, а Вы пытаетесь его применить к какому-то абстрактному пользователю.

Использование паттернов проектирования в javaScript: Порождающие паттерны

Чаще всего он применяется когда конечному пользователю класса не принципиально ссылка это или новый объект: объект для доступа к БД, объект текущего пользователя и пр. Память и вычисления экономятся, объект как-будто бы новый

Использование паттернов проектирования в javaScript: Порождающие паттерны

На мой взгляд, многие классические паттерны в javascript просто не имеют смысл, так как этот язык гибче тех, на которые они в первую очередь рассчитаны.

Дело Ваше, на мой взгляд имеют.

Но в javascript нет классов!

Хотите Вы (или я) этого или нет, но в большинстве случаев используется либо какой-нибудь синтаксический сахар, либо функции-конструкторы, методы в которых записываются в прототип, что максимально приближает такую сущность к понятию класса. Согласен, не совсем корректно называть функции-конструкторы классами, но это чистой воды вкусовщина и разбирательства есть ли классы в js и называть ли их классами тот еще холивар, участвовать в котором у меня особого желания нет.

А если сделать функцию она магическим образом не будет глобальной? В requirejs можно возвращать и объект, вы не поверите.

Если использовать без какой-либо модульной системы, то да, конечно функция будет глобальной и профит по этой части получить не получится. Но я все-таки писал с оглядкой на requirejs (или другую модульную систему), в котором действительно можно возвращать объект, но это будет менее гибко: мы теряем возможность безболезненного избавления от дублирования кода путем наследования. Плюс такую реализацию, основанную на функциях довольно просто реализовать на CoffeeScript, выйдет практически тоже самое.

Суть фабричного метода — не в том, что вы описали, а в том, чтобы предоставить возможность подклассам переопределить класс (или в общем случае — способ создания) объектов, которые создаются в процессе работы этого класса

Цитата из книги Стефанова «JavaScript. Шаблоны»:

Назначение фабрики в том, чтобы создавать объекты. Этот шаблон обычно реализуется в виде классов или в виде статических методов классов и преследует следующие цели:
• Выполнение повторяющихся операций, необходимых при создании похожих объектов
• Предложить пользователям фабрики способ создания объектов без необходимости знать их тип (класс) на этапе компиляции

var obj = { createAnimal: function(){ return new this.animal(); } }; obj.animal = Dog; obj.animal = Cat;

В общем и целом это отдаленно похоже на фабрику, но каждый раз перед созданием объекта нужно будет подставлять нужный конструктор, неудобно постоянно таскать все конструкторы за собой.

То что вы описали тоже решается без каких то проблем и мысле о «паттернах»:
var animal = { cat: Cat, dog: Dog }; new animal['cat'];

Мыслей о паттернах может и не появляться, но этот код также является примитивной реализацией фабрики.

Использование паттернов проектирования в javaScript: Порождающие паттерны

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

Использование паттернов проектирования в javaScript: Порождающие паттерны

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