Вставлю свои 5 копеек, уворачиваясь от вил.

Существует архитектура "пирога", которая предполагает использование нескольких програмных слоев, на каждом из которых реализуется определенная логика.

Ее я и решил применить в флэш-проекте на AS3.

1) Я отнаследовал Main.as от MovieClip
2) Я создал класс RegistrationForm и повесил listener на кнопку registrationButton
3) В callback методе я использовал RegistrationManager.getInstance().register()

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

Заменим его на класс ApplicationManager который будет общаться с сервером вызывая методы NetConnection.call и получая callbacks.
Фактически, этот класс будет оберткой NetConnection и он должен быть единственным, т.к. нужен только один коннект к медиа серверу.

В чем здесь неоправданное использование шалона "одиночка"?
Как этот функционал реализовать по другому?

BlooDHounD:
Если он мне нужен всего один, то я и буду делать всего один, зачем мне 2 одинаковых? В этом и задача синглтона - намерено не дать создать другой такой же объект... Конекшн уникальный по своим параметрам, и другого такого как он быть не может, потому что второму такому делать нечего будет. А нужен будет еще один, но с другим функционалом - так я и создам другой...

Alexander Balaganov:
Собственно, наш спор до этого был о том, что лучше использовать:
Manager.someStaticMethod(); или Manager.getInstance().someMethod();
Мое мнение такое, что если удобнее пользоваться методами объекта, у которого нужно вызвать метод (например, нам его нужно унаследовать от EventDispatcher, чтобы можно было рассылать события из него, а не через какoе-нибудь опять же статическое свойство хранящее ссылку на экземпляр EventDispatcher, то, мое мнение, что удобнее использовать синглтон. Но если класс ни от чего наследовать не нужно, то проще обойтись статическими методами.

пример:
1. есть хитрый класс обрабатывающий соединение. ему для работы нужен сериализатор;
2. есть сериализатор. ему для работы нужны параметры сереализации;
3. нужно сделать игровой поток, и чатовый поток. оба потока в принципе работают можно объединить в один, но мы хотим их развивать независимо;
4. мы берём хитрое соединение, сереализатор, меняем параметры, получаем соединение;

каждого соединение существует по одному. логично! зачем нам 2 чатовых соединения? из вашей логики мы должны сделать следущие:
1. сделать синглтон-класс ChatConnection;
2. сделать сингтонр-класс GameConnection;

вроде бы всё лочгично, но зачем? ведь два класса будут отличать только парметрами серелизатора.

сделай один, зачем делать из него синглтон? Ошибка! задача синглтона совсем в другом. если ты "намерянно" пытаешь создать второй такой объект, значит тебе надо! и ты ошибся проектируя класс. Задача синглтона разграничить твои права. Дело в том, что работая с синглтоном, ты не знаешь создаётся ли объект, или этот один и тот же экземпляр. логика шаблона заключается в том, что информация, об источнике появления объекта тебе не известна. но ты точно знаешь, что это ЭКЗЕМПЛЯР.
тоесть есть внешние параметры его создания? тогда какой же это синглтон?
функционал может быть тот же самый, но "target" другой.
неа! это значит ты меня не внимательно читал. тут вообще никаких статиков, и никаких гетинстанс быть не должно.
тоже не соглашусь с формулировкой. сиглтон нужно использовать только тогда, когда тебе этот объект надо передавать аргументом, или тебе важна цепочка наследования. иначе лучше необходимые объекты инкапсулировать.

Млин, короче... я не хочу спорить... ты все не правильно понял, ну да ладно, не важно.

- порадовало :))

Какие страсти-то разыгрались - брррр... :)
А инициатором был я :quiet:
В ЭтогЕ, я так, честно говоря, и не нашел именно "синглтон случая", когда без него, ну, никуда. Облазил весь инет - пока что-то жесткой необходимости в классе-сингле не нашел. Возможно, сам пойму, когда столкнусь с такой задачей, где именно он нужен будет...