Это не просто сообщество AS, это общая тенденция в разработке программного обеспечения. Компонентно-ориентированное программирование поощряет первоначальную настройку и проводку объектов службы, которые затем взаимодействуют с использованием переходных сообщений. Синглтоны - естественная часть этой идеи.
Кроме того, синглтоны уменьшают влияние времени выполнения объектов, которые дороги для создания.
Я думаю, что это исходит из старого способа, которым работала Flash ... В те давние времена было не так много тяжелых программистов, которые делали флеш, всего несколько, и их считали вундеркиндами (и это справедливо). Большинство людей были людьми, которые перешли из печатной промышленности ... они думали, что Flash - это новый Illustrator для webz.
В старые времена разработчики flash использовали простой в использовании TellTarget для доступа к определенному MovieClip, который мог быть вложен внутри MovieClip внутри MovieClip внутри ... и т. Д. Это просто так, как это было сделано ... те у людей (включая меня) никогда не было никакого программного обеспечения, поэтому мы жили в этом визуальном мире, и Flash думал о том, как думали дизайнеры. В AS2 многие люди (те, кто были и те, кто не умел кодировать) также столкнулись с множеством проблем с потерями «областей» внутри классов ... Я помню класс Proxy, который помог нам не потерять область в классе , В наши дни много головных болей. Люди, которые постепенно повышали свою мудрость кода, никогда не завершали свои головы полностью новыми способами кодирования в ООП ... некоторые из них считают, что Singleton можно использовать как своего рода « глобальный ». Они всегда могут разговаривать с этим « глобальным » нигде в своем приложении.
Я думаю, это просто ...
Я не совсем уверен, откуда все это происходит, Flex их полна, и, как вы уже упоминаете, мы видим их в других местах. Сначала они выглядят привлекательно, но они почти всегда приводят к головной боли где-то по дороге.
Каждый должен прочитать блог Мишко Хевери ( начните с этого ). Он делает отличные аргументы против их использования.
У синглтона есть такие функции, как Logger, но они используются намного раньше.
@skaffman Что касается преимуществ производительности, вполне разумно иметь один экземпляр объекта в вашем приложении без реализации шаблона Singleton.
К замечательным моментам, которые уже были сделаны здесь, я бы добавил, что есть что-то о высокой скорости, с которой объединены Flash-проекты, и о том, что большинство из них не нужно поддерживать, что побуждает людей просто добиваться быстро, насколько это возможно, и Singletons - хороший способ сделать это, и вы можете использовать getInstance, а не передавать ссылки, инъекции зависимостей и т. д. На практике факт состоит в том, что вы когда-либо будете иметь один экземпляр многих ваши классы, хотя теоретически вам может понадобиться больше одного.
С тех пор я изменил свою позицию в этом отношении.
Использование объектов в actionscript3 haas помогло мне улучшить модуляцию.
Я бы предположил, что, как и я, преимущества ООП являются заумными и трудными для большинства начинающих разработчиков флеш-памяти.
Я думаю, что для этого есть две причины.
1.) говорить об основах скучно, поэтому большая часть информации настолько сложна. ООП действительно просто разбивает систему на понятные детали многократного использования.
2.) процедурное программирование похоже на рабочий процесс, оно блокирует вас в определенном потоке работы, но для начинающих программистов, что облегчает понимание
3.) Вспышка - это управление состоянием флеш-виджета, поэтому для управления информацией в одном центральном месте требуется определенный уровень смысла.
---------------- Оригинальный ответ ----------------
Я часть этого сообщества AS, которое любит (и использует) одиночные игры.
Я относительно новичок в программировании (3 года PHP / MySQL / Javascript / Actionscript proffesionally).
Я думаю, что существует четкое различие между модульным программированием и ООП наследования на основе классического класса.
Модульное программирование, которое, как я понимаю, является большой частью ООП, является чрезвычайно важной частью эффективного дизайна программы.
Все, что используется несколько раз, может быть перемещено в отдельную функцию. Группы операций, которые имеют сходные функциональные возможности или атрибуты, могут быть разделены на их общие части, а затем разные части, унифицированные для его экземпляра.
Тем не менее, я считаю более эффективным сделать это с помощью набора взаимосвязанных модулей
На мой взгляд, большая часть базы наследования ООП - это просто горячий воздух. Модули, взаимодействующие друг с другом, являются гораздо более эффективным способом моделирования действий программы, в которой 15 версий в основном одно и то же.
Я создаю ядро ??и делаю модули для запуска в ядро, но никогда не должен быть под-объектом, являющимся расширением ядра. Я думаю, что расширение класса громоздко и застопорило развитие, исключив из него необходимую гибкость.
Одной из причин, по которой я часто читал (и слышал о ООП, основанный на наследовании), является то, что он повышает читаемость и поддерживаемость. Для меня все это означает, что программисты предпочитают использовать систему, которая им легко, чем система, эффективная для программы.
Я все для написания как чистый и понятный код, насколько это возможно, но только до и не до конца, где он препятствует творчеству и гибкости программы.
Я для ООП, но я предпочитаю синглтон, прототип или модуль на основе aproach.