Форум Flasher.ru
Страница 2 из 3 < 1 2 3 >
Показывать 40 сообщений этой темы на одной странице

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   реализация паттерна singleton на AS3 (http://www.flasher.ru/forum/showthread.php?t=109596)

etc 18.03.2008 14:25
WindWalker получает плюс. Холивар холиваром, а на личности переходить нельзя.

NePridymal 18.03.2008 14:44
Цитата:
Я не очень поддерживаю карательные меры, но, если говорить о коде синглтонов опубликованых здесь, то __etc прав. Код ужасный.
Могу показать конкретные косяки.
Ну а мне в моем коде (на второй странице) можно показать косяки? Если уж говоришь - то делай.

А насчет использования/неиспользования... Врядли кто-то будет возражать что для некоторых целей это очень удобная штука, и как и в любом патерне, в нем есть как плюсы так и минусы.
А идеальное еще не изобрели все равно :) .

Iv 18.03.2008 15:03
Нет косяков у тебя. Но предложенный тобой вариант есть в обсуждении синглтона: http://yarovoy.com/2007/10/24/single...ctionscript_3/
Там-же к коментах есть и мой:
Код:
public static const INSTANCE : Singleton = new Singleton();
public function Singleton () {
        if (INSTANCE) throw new Error("**Error** - singleton. Сonstructor is locked.");
}
С подробным описанием того, какие недостатки других синглетонов в нем устранены.

BlooDHounD 18.03.2008 15:03
абсолютно неудобная. если она используется больше чем в одном месте.

terbooter 19.03.2008 09:17
Iv, спасибо за разъяснения.
Еще два вопроса.

1) Какой-нибудь конкретный пример "правильного" применения синглтона в АС3

2) Присоединяюсь к
Цитата:
Сообщение от WindWalker
...
Вот если есть нечто глобальное, что влияет на всё приложение в целом, то каким образом это лучше всего реализовать?

Пример с опциями уже приводил.
Другой пример - имя игрового аккаунта (в мультиплеерной) или игрового профиля (в сингплеерной) игре. Показывать и использовать надо в разных местах. А хранить надо в одном.
Каким образом это лучше всего реализовать?

Iv 19.03.2008 13:39
terbooter,
ситуация такова, что это очень сильно зависит от контекста.
Если ты делаешь баннер, то там можешь вообще всё реализовывать через синглтоны не задумываясь.
Если ты пишешь реюзабельный код, то довольно трудно сказать где синглетон будет незаменим.

Примеы:

Сокет-коннектор.
приложение устанавливает сокет-соединение с сервером. Из разных частей приложения вызываются команды коннектора. Команды организуются в очередь FIFO и производится контроль ответов сервера.
В этой ситуации синглетон - верное решение. Его задачи - не дать ошибиться программеру случайно создав второй экземпляр и не производить постоянную проверку на наличие коннектора перед вызовом его метода.

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

Как видите, синглетон (он переводится как одиночка) - это такой класс, у которого может быть один и только один экземпляр.
Его одиночество как проверочное действие: если теоретически может быть несколько экземпляров, то это не синглетон.

BlooDHounD 19.03.2008 14:59
Цитата:
Сообщение от Iv
Сокет-коннектор.
приложение устанавливает сокет-соединение с сервером. Из разных частей приложения вызываются команды коннектора. Команды организуются в очередь FIFO и производится контроль ответов сервера.
В этой ситуации синглетон - верное решение. Его задачи - не дать ошибиться программеру случайно создав второй экземпляр и не производить постоянную проверку на наличие коннектора перед вызовом его метода.
ну тут я могу согласится ... и то при условии, что Сокет-коннектор должен иметь специфичный интерфейс. иначе - статический свойтва и методы. кстати, не только теоретически, но и практически на примере игр, соединений обычно больше одного. синглтон уже не применим.
Цитата:
Сообщение от Iv
Библиотека кэшированных изображений.
В приложении часто используются одинаковые подгружаемые картинки (например иконки папок и файлов в меню). Существенного ускорения доступа можно достигнуть используя внутреннее кэширование. Для этого организуется библиотека-синглетон, которая при запросе картинки проверяет ее наличие в кэше и т.д.
тут через статические свойста и методы сделать удобнеее. если библиотека используется больше чем в 2х методах, меня затрхает каждый раз писать
Код:
var s:Singletone = Singletone.getInstance();
var c:Class = s.getClass();
обычно в игре таких строк около сотни. я предпочитаю написать:
Код:
var c:Class = StaticClass.getClass();

WindWalker 19.03.2008 15:25
Вот бредятина-то.

Вместо одного "пусть неправильно зато писать мало" предлагается "ещё более неправильно, зато писать ещё меньше".

Iv 19.03.2008 15:55
BlooDHounD,
собственно в рассуждениях ты допускаешь типичную ошибку трактовки синглетона.
Метод доступа к данным (статические методы или через экземпляр полученный через getInstance) значения не имеют.
Ты пытаешься оценивать синглетон в качестве способа глобального доступа, что в корне неверно. Синглетон не для этого предназначен.
Ну как сравнивать молоток с микроскопом.

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

WindWalker 19.03.2008 16:02
Хмм... А если тогда реализовать Синглтон следующим образом:

Делаем публичный класс-обёртку и скрытый класс-синглтон, который непосредственно и содержит весь функционал.

Класс-обёртка выполнение всех методов делигирует синглтону.
Конструктор никоем образом не прячем - пускай создаются несколько обёрток (или лучше назвать розетками или гейтами?), всё равно работать у нас будет в итоге единственный экземпляр.

Сейчас попробую это в виде кода оформить...

Iv 19.03.2008 16:09
Идея понятна, но дело совершенно не в этом.
Прелесть синглетона в том, что можно его быстро переделать в обычный класс и обратно.
Собственно это одна из причин, по которой не стоит увлекаться статическими методами.

WindWalker 19.03.2008 16:21
Во.
Есть интерфейс:
Код:
package {
        public interface IDoer {
                function doSomething():void;
        }
}
Вот класс, который использует синглтон:
Код:
package {
        public class User {
                public function User() {
                        var doer1:IDoer = new Singleton();
                        var doer2:IDoer = new Singleton();

                        doer1.doSomething();
                        doer2.doSomething();
                }
        }
}
А вот непосредственно реализация синглтона:
Код:
package {

        public class Singleton implements IDoer {
               
                private var realDoer:IDoer;

                public function Singleton() {
                    realDoer = RealSingleton.getInstance();
                }

                public function doSomething():void {
                        realDoer.doSomething();
                }
        }
}

internal class RealSingleton implements IDoer {

        private var counter:int = 0;
        private static var instance:RealSingleton;

        public static function getInstance():RealSingleton {
                if (!instance) instance = new RealSingleton();
                return instance;
        }

        public function doSomething():void {
                trace(counter+": Hello world!");
                counter++;
        }
}
Плюс такого подхода, в том, что никто извне не знает, что это синглтон.
Используют как обычный класс.
Таким образом, если мы решим отказаться от использования синглтона (например, потребуется несколько соединений к серверу), то меняем только один файл. Для остальных классов ничего не изменилось.

То есть уровень абстракции выше, переделка в обычный класс совершенно прозрачна.

BlooDHounD 19.03.2008 16:23
Цитата:
Сообщение от Iv
Идея понятна, но дело совершенно не в этом.
Прелесть синглетона в том, что можно его быстро переделать в обычный класс и обратно.
Собственно это одна из причин, по которой не стоит увлекаться статическими методами.
ты уже сам себе противоречишь. сперва ты горишь что это чисто экземпляр, потом ты говоришь, что экземпляра может и не быть ... приводишь примеры в которых используешь синглтон как глобальный доступ, а мне говоришь, что я его не правильно трактую. чё-то Вы сударь сами запутались.

BlooDHounD 19.03.2008 16:27
WindWalker, а нафига делать синглтон, о котором никто не узнает? это уже не синлтон получает, а фигня какая-то.

WindWalker 19.03.2008 16:34
Это называет ин-кап-су-ля-ци-я.
Чем меньше мы знаем о внутреннем устройстве, тем легче живётся и крепче спится.

Про класс мы знаем. Инстанциируем, используем.
А про то, что он реализован через синглтон - не знаем и знать не хотим.
И если когда-нибудь он волшебным образом перестанет быть синглтоном (с сохранением интерфейса, логики и функциональности), то нас это никак не будет волновать.

Хочу обратить внимание, что класс-пользователь не использует статические методы и не содержит никаких упоминаний getInstance().

Iv 19.03.2008 16:41
BlooDHounD, можно поподробнее, с моими цитатами?

BlooDHounD 19.03.2008 17:03
Цитата:
Сообщение от Iv
BlooDHounD, можно поподробнее, с моими цитатами?
все цитаты чуть выше постами. перечитай сам, пожалуйста. а твои примеры я отношу к категории:
Цитата:
Сообщение от __etc
В абсолютном большинстве случаев
(с этой формулировкой ты соглаился)


WindWalker, мне всё равно как Вы это называете :) просто я не пониманию, зачем усложнять структуру приложения, даже если программист никогда не увидит внутренности :) по мне так проще вместо создания "непоймикакогосингтона" написать как-нить так:
Код:
                private static function $doSomething():void {
                        realDoer.doSomething();
                }
                public function doSomething():void {
                        $doSomething();
                }
и работает и быстрее, и нету никаких инстансов внутри.

Iv 19.03.2008 17:08
BlooDHounD, мне блевать хочется от такого общения как сейчас с тобой.
Научись отстаивать свою точку зрения, а не прятаться за общими фразами.

2morrowMan 19.03.2008 17:33
Iv, необращай внимания на тех, кто до этого еще не дорос, а то зря только время потратиш... я хоть посмеялся, пока читал посты отдельных пользователей))

BlooDHounD 19.03.2008 17:36
Iv, ты меня расстраиваешь :) я давно, привык что ты общаешься сам собой, так что ты уж меня прости, что не цитирую тебя очень часто. мне кажется я чётко расписал в чём ты не прав. извини, что не приготовил тебе нормальный завтрак. не могу тебе сейчас помочь с пищеварением.

WindWalker 19.03.2008 17:41
Цитата:
Сообщение от BlooDHounD
по мне так проще вместо создания "непоймикакогосингтона" написать как-нить так:
Ну в некоторых случаях действительно можно и так.
Если точно уверены, что не будем наследовать, потому как со статическими методами не всё так просто.

Вот пример. Есть базовый класс.
Код:
package {
        public class MyClass1 {               
                private static function $hello():void {
                        trace("Hello from class 1");
                }

                public function hello() {
                        $hello();
                }
        }
}
Решили переопределить метод:
Код:
package {
        public class MyClass2 extends MyClass1 {               
                private static function $hello():void {
                        trace("Hello from class 2");
                }
        }
}
Ну и проверям:
Код:
new MyClass2().hello();
Ай-яй-яй, бага.
В данном случае - легко заметная и быстро исправляемая.
А в реальном проекте можно очень долго её ловить.

Iv 19.03.2008 17:42
2morrowMan, здесь профессиональный форум и изначально я отношусь к любому как к коллеге, уважительно.
При этом не имеет значения уровень - что гуру, что начинающий, в моих глазах имеет одинаковый респект.
Но блин, есть же общепринятые нормы общения. Если высказываешься, будь готов аргументировать свою точку зрения. Я готов поспорить и с удовольствием откажусь от собственных заблуждений, если оппонент мне аргументированно докажет это. С удовольствием, подчеркиваю. Потому, что этот человек подымет мой проф уровень, за что ему респект и спасибо.
Но не все понимают и частенько весь их текст несет информации не более чем пук в воду. Это бесит.

BlooDHounD 19.03.2008 18:07
Iv, я аргументировал. что у тебя вызвало вопрос, я не понимаю. извини, что не умею писать 10 кб текста неся при это одну единственную мысль: "ты привёл не правильные примеры использования синглтонов". ну не прозаик я. написал коротко и ясно. ты обиделся почему-то. извини.

WindWalker, я не понимаю зачем вы пытаетесь переопределить приватный, к тому же статический метод, не используя слово override. Может я не понимаю, но у меня в обоих случаях выводится: "Hello from class 1".

если вы хотели переопределить, то надо было написать так:
Код:
package {
        public class MyClass2 extends MyClass1 {               
                public override function hello():void {
                        trace("Hello from class 2");
                }
        }
}

WindWalker 19.03.2008 18:24
Цитата:
Сообщение от BlooDHounD
WindWalker, я не понимаю зачем вы пытаетесь переопределить приватный, к тому же статический метод, не используя слово override.
Чтобы показать, насколько негибкими являются статические методы.
override вообще нельзя писать одновременно со static (как я буквально только что выяснил :)).

Цитата:
Может я не понимаю, но у меня в обоих случаях выводится: "Hello from class 1".
Вот-вот. Это и есть бага.

Преимущество синглтона в том, что он - экземпляр.
1. У него нормальные методы, которые можно переопределять (со статическими просто так не выйдет).
2. Он может имплементировать интерфейс (попробуйте сделать это со статическими методами).
3. В последствии мы можем отказаться от требования иметь только один экземпляр, и насоздавать их несколько.

BlooDHounD 19.03.2008 18:44
Цитата:
Сообщение от WindWalker
Чтобы показать, насколько негибкими являются статические методы.
override вообще нельзя писать одновременно со static (как я буквально только что выяснил :)).
Собственно на это я и намекал. это в принципе идеологически неверно :) Если вам надо что-то переопределить, то я привёл код, как это делается. пока не вижу логики. Ваш вариант реализации ничем не отличается, так как до самого синглтона, наследник тоже никак не дотянется, как и до приватного статического метода. что-то Вы перемудриваете. даже если вы создадите наследника синглтона, то во всех инкапсулированных классах будет использоваться его родитель, что никак не приведёт к желаемому вами результату..
Цитата:
Сообщение от WindWalker
Преимущество синглтона в том, что он - экземпляр.
1. У него нормальные методы, которые можно переопределять (со статическими просто так не выйдет).
2. Он может имплементировать интерфейс (попробуйте сделать это со статическими методами).
3. В последствии мы можем отказаться от требования иметь только один экземпляр, и насоздавать их несколько.
1. никакого преимущества.
2. это я написал в самом начале разговора. использование синглтона в принципе может быть обусловленно, только имплементацией определённого интерфейса. иначе он просто не имеет смысла, и приводит к потери скорости работы приложения и потери скорости разработки приложения.
3. если такая необходимость возникнет (это ошибка проектирования), то вам никак это не поможет. вам придётся переколбасить кучу кода, что бы везде привести работу к конкретному экземпляру. работы будет не меньше, чем со статиками. можно конечно на скорую руки превратить синглтон в мультитон, и сделать дефолный аргумент, по которому будет возвращаться используемый вами везде экземпляр, но этот путь приведёт к запутыванию кода, и непониманию его работы в целом.

update:
забыл аргументировать первый пункт (специательно для Вани).
1. никакого преимущества.
так как Ваня описал выше, это класс который должен быть один одинёшеньки. наследование такого класса может привести к непредсказуемым последствиям. так как вполне логично, что и наследник будет выполнять схожие со стоим родителем задачи, их действия могут пересечься, что слегка нарушит всё логическое обоснование одиночки.

miramax 19.03.2008 19:57
А я не люблю паттерны. =)
Раньше использовал синглтон только если в глобальной точке доступа необходимо было наследоваться или имплементировать какой-то интерфейс (например IEventDispatcher).
Потом отказался в пользу обыкновенных объектов находящихся в статических константах.
Стало проще жить =).

P.S. BlooDHounD, синглтон - интуитивно финальный класс, это все понимают. В первом пункте речь о наследовании полей самим синглтоном, т.е. о том из-за чего и я использовал его в начале.

BlooDHounD 19.03.2008 20:01
Цитата:
Сообщение от miramax
P.S. BlooDHounD, синглтон - интуитивно финальный класс, это все понимают. В первом пункте речь о наследовании полей самим синглтоном, т.е. о том из-за чего и я использовал его в начале.
как это вытекает из написанного тут:
Цитата:
Сообщение от WindWalker
1. У него нормальные методы, которые можно переопределять (со статическими просто так не выйдет).
толи я идиот, толи вы невнимательно читали.

miramax 19.03.2008 20:05
Код:
public class Singleton extend EventDispatcher{}
И класс Singleton имеет методы addEventListener, removeEventListener готовые для переопределения.

BlooDHounD 19.03.2008 20:08
я то это понимаю. это и называется "определённый интерфейс". это пункт 2.

WindWalker 19.03.2008 20:10
Цитата:
Сообщение от BlooDHounD
Ваш вариант реализации ничем не отличается, так как до самого синглтона, наследник тоже никак не дотянется, как и до приватного статического метода.
Лёгким движением руки класс RealSingleton переноситься в отдельный файл и делается публичным. И никто этого даже не заметит (даже поддельный Singleton. В худшем случае дописываем import).

Далее можно наследовать (если очень хочется).

Со статическими методами не всё так просто. Можно превратить их в public, но переопределять их всё равно не сможем.

Цитата:
даже если вы создадите наследника синглтона, то во всех инкапсулированных классах будет использоваться его родитель, что никак не приведёт к желаемому вами результату..
У нас есть класс-посредник. Никто, кроме него, про синглтон не знает.
Вот в нём-то, если надо, и делаем необходимые изменения, чтобы первым создавался именно экземпляр наследника, а не родителя.

Цитата:
2. это я написал в самом начале разговора. использование синглтона в принципе может быть обусловленно, только имплементацией определённого интерфейса. иначе он просто не имеет смысла, и приводит к потери скорости работы приложения и потери скорости разработки приложения.
В AS2 он позволял наоборот увеличить производительность по сравнению со статическими методами :)
Но согласен, в AS3 это уже не актуально.

Цитата:
3. если такая необходимость возникнет (это ошибка проектирования), то вам никак это не поможет. вам придётся переколбасить кучу кода, что бы везде привести работу к конкретному экземпляру.
Не факт.
Пример с сетевым соединением как раз мне нравится.
Допустим, первоначально предполагалось, что соединение должно быть одно и только одно. Сделали синглтончик Connection.

Потом решили, что надо балансировать нагрузку и сделать так, чтобы клиент имел несколько параллельных соединений к разным серверам и примерно пропорционально раскидывал запросы между ними.
Модифицируем Connection - делаем так, чтобы он больше не был синглтоном, а метод getInstance возвращал наименее занятое соединение (например, просто по принципу револьвера, но это уже не так важно).

И ещё не забываем, что у нас есть класс-посредник (в случае с соединениями например класс Request).
И про одиночку и его одиночество знает только этот посредник (да и то не всегда). Соответственно, и необходимые изменения (возможно, хотя и не всегда конечно) достаточно будет сделать только в нём.

Цитата:
так как Ваня описал выше, это класс который должен быть один одинёшеньки. наследование такого класса может привести к непредсказуемым последствиям. так как вполне логично, что и наследник будет выполнять схожие со стоим родителем задачи, их действия могут пересечься, что слегка нарушит всё логическое обоснование одиночки.
Я могу привести пример, где такое наследование может пригодиться.
Опять же сетевое соединение. Опять же одновременно только одно.
Но!
Сперва пробуем SocketConnection, если обломались, то его убиваем и используем HTTPConnection.
Оба наследуются от некоего AbstractConnection.

Вот тут уже возникает более интересный вопрос: как реализовать "расширенную одиночку", который гарантирует одновременное существование только одного экземпляра с учётом всех потомков?
Вот на этот вопрос я сейчас не знаю как ответить. :)
И на вопрос "а нафиг это вообще надо" тоже :)
Но есть ощущение, что чисто статическими методами тут тоже не обойтись (точнее обойтись то можно, но выйдет некрасиво).

P.S.
Хотя насчёт "расширенной одиночки" подозреваю, что тут всё довольно просто - кто раньше встал, того и тапки. Статическая переменная instance то одна для всех. Как только чей-то экземпляр туда засунули, все остальные автоматически идут лесом.

llllllllll 19.03.2008 20:13
Цитата:
Сообщение от Iv
Прелесть синглетона в том, что можно его быстро переделать в обычный класс и обратно.
Один единственный раз использовал и именно по этой причине :)

miramax 19.03.2008 20:14
Цитата:
Вот тут уже возникает более интересный вопрос: как реализовать "расширенную одиночку", который гарантирует одновременное существование только одного экземпляра с учётом всех потомков?
Вот на этот вопрос я сейчас не знаю как ответить. :)
И на вопрос "а нафиг это вообще надо" тоже :)
Но есть ощущение, что чисто статическими методами тут тоже не обойтись (точнее обойтись то можно, но выйдет некрасиво).

P.S.
Хотя насчёт "расширенной одиночки" подозреваю, что тут всё довольно просто - кто раньше встал, того и тапки. Статическая переменная instance то одна для всех. Как только чей-то экземпляр туда засунули, все остальные автоматически идут лесом.
Хм... Всё чуть хуже, чем я думал. Вероятно WindWalker'у надо сказать, что синглтон - финальный :)

divinus 19.03.2008 20:17
может закончим холивар? все равно ведь все останутся при своем!!! а за время пока вот тут идут дебаты, я открыл для себя паттерн "абстрактная фабрика", может еще по поводу него поспорим? ;)

WindWalker 19.03.2008 20:19
Цитата:
Сообщение от BlooDHounD
я то это понимаю. это и называется "определённый интерфейс". это пункт 2.
Определённый интерфейс - это implements ISerializable, например.

Цитата:
Сообщение от miramax
Хм... Всё чуть хуже, чем я думал. Вероятно WindWalker'у надо сказать, что синглтон - финальный :)
Ок. Я книжку-то про паттерны так и не прочитал, так что каких-то ограничений могу и не знать. :)
Раз есть какие-то веские причины, чтобы он был всегда финальным - пусть будет финальным (кстати, какие именно причины?).

Но таки меняем пункт 1.
Синглтон может от кого-то наследоваться, переопределяя методы (в том числе вызывая старые методы через super()).
А со статическими методами возникнет ряд проблем...

-----------------------------

Последняя добавочка.

Я на самом деле использую и статические методы, и синглтоны.
И то и другое - для глобального доступа. Потому что глобальный доступ - это такой "черный ход", который зачастую позволяет сильно сократить путь.
Когда времени мало, а надо, чтобы какой-то очень мелкий объектик, обычно отвечающий за какую-то мелкую функцию, вдруг узнал что-то общее (например, громкость звука или url к сервлету) или даже вообще сделал что-то глобальное (например, какой-нить мелкий бонус вдруг взял да увеличил количество очков у игрока), и передавать это всё по цепочке не хочется - использую глобальный доступ.

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

miramax 19.03.2008 20:47
Цитата:
Сообщение от WindWalker
Ок. Я книжку-то про паттерны так и не прочитал, так что каких-то ограничений могу и не знать. :)
Раз есть какие-то веские причины, чтобы он был всегда финальным - пусть будет финальным (кстати, какие именно причины?).
Цитата:
Сообщение от WindWalker
Но таки меняем пункт 1.
Синглтон может от кого-то наследоваться, переопределяя методы (в том числе вызывая старые методы через super()).
А со статическими методами возникнет ряд проблем...
Я тоже книжек не читал, просто статические свойства по своей сущности финальны. Синглтон привязан к статическим переменным, а наследование синглтона требует переопределения статических свойств, что противоречит логике.

WindWalker 19.03.2008 20:51
Так статический метод только один: getInstance().
Пускай остаётся таким, какой он есть.

Я говорю про методы/поля самого экземпляра. Прекрасно переопределяются.

BlooDHounD 19.03.2008 20:55
Цитата:
Сообщение от WindWalker
Ещё раз повторяю: у нас есть класс-посредник.
я уже в который раз спрашиваю: зачем создавать класс посредник, чтобы реализовать в нём ещё синглтон? что это даёт?
либо по другому: зачем создавать синглтон в классе посреднике, если он и сам может выполнять этот функционал? вы приводите пример в которм используется синглтон, ради самого его существования.

даже если вы вынесете синглтон в отдельный класс, то класс посредник уже нафиг не нужен, так как к нему будут иметь доступ все. наследовать его тем болие не надо. зачем? у нас же есть класс посредник мы может прям там написать.
Цитата:
Потом решили, что надо балансировать нагрузку и сделать так, чтобы клиент имел несколько параллельных соединений к разным серверам и примерно пропорционально раскидывал запросы между ними.
Модифицируем Connection - делаем так, чтобы он больше не был синглтоном, а метод getInstance возвращал наименее занятое соединение (например, просто по принципу револьвера, но это уже не так важно).
это будет уже не сингтон. вся идеология нарушена. я тут описал:
Цитата:
Сообщение от BlooDHounD
можно конечно на скорую руки превратить синглтон в мультитон, и сделать дефолный аргумент, по которому будет возвращаться используемый вами везде экземпляр, но этот путь приведёт к запутыванию кода, и непониманию его работы в целом.
Ваш PS говорит о том, переопределять синглтон ваще нафиг не нужно. проще его изменить.

Цитата:
Но есть ощущение, что чисто статическими методами тут тоже не обойтись (точнее обойтись то можно, но выйдет некрасиво).
конечно. потому сетевые соеденения вообще нельзя делать сингтонами. пример неудачный.

p.S: у нас кстати реализован ваш пример. конечно без сингтона. и уж тем болие без статиков.

miramax 19.03.2008 20:56
Цитата:
Сообщение от WindWalker
Так статический метод только один: getInstance().
Ну вот этот метод будет всегда возвращать инстанцию класса в котором он объявлен.

BlooDHounD 19.03.2008 20:58
Цитата:
Определённый интерфейс - это implements ISerializable, например.
между прочим, с наследованием класса, ты наследуешь все его методы и свойтсва (условно можно считать этот набор интерфейсом класса), а так же и все его интерфейсы.

WindWalker 19.03.2008 21:55
Цитата:
Сообщение от miramax
Ну вот этот метод будет всегда возвращать инстанцию класса в котором он объявлен.
Блин, точно :)
Всё, понял-отстал!

Цитата:
либо по другому: зачем создавать синглтон в классе посреднике, если он и сам может выполнять этот функционал? вы приводите пример в которм используется синглтон, ради самого его существования.
Наверное потому, что экземпляр класса Request (или одного из его потомков) и экземпляр класса Connection - это немного разные сущности и не стоит их мешать в одну кучу.

Connection - синглтон, Request - посредник.

Цитата:
даже если вы вынесете синглтон в отдельный класс, то класс посредник уже нафиг не нужен, так как к нему будут иметь доступ все.
Если у меня где-нить эдак классов 30-50 уже используют посредника, то из-за того, что кто-то там стал видимым, я не буду эти 30-50 классов переписывать. В этом-то и фишка посредника, что он прячет делали от остальных классов.
Он может использовать скрытый синглтон. Он может использовать публичный синглтон. Он может использовать мультитон. Он может сам реализовывать весь функционал, а синглтон удаляется. Он может использовать статические методы - свои или другого класса.
При этом все остальные ничего не замечают.
Он реализует интерфейс, а как он это делает - дело десятое.

То есть, вообще говоря, синглтон тут вовсе даже и не главный получается :)
Просто - как одна из возможностей реализации.

Цитата:
Сообщение от BlooDHounD
между прочим, с наследованием класса, ты наследуешь все его методы и свойтсва (условно можно считать этот набор интерфейсом класса), а так же и все его интерфейсы.
Очень условно. Очень-очень условно.
Потому что интерфейс (в ООПешном понимании) - это, вообще говоря тип, а не просто набор методов.
Со всеми вытекающими...

Цитата:
p.S: у нас кстати реализован ваш пример. конечно без сингтона. и уж тем болие без статиков.
Да у меня тоже реализован. Причём несколько раз :)
Но вот щас не могу вспомнить подробности, а исходников под рукой нет.


Часовой пояс GMT +4, время: 04:05.
Страница 2 из 3 < 1 2 3 >
Показывать 40 сообщений этой темы на одной странице

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.