Singleton и наследование

[zerkms]

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

вопрос, зачем наследоваться, если можно сделать:

public static function getInstance()
{
return factory::getInstanceOf(__CLASS__);
}

ну и для пущей красоты реализовать интерфейс ISingleton. м?

 

[FractalizeR]

Но влияет на качество кода. Если подразумевается, что функция должна обязательно определяться всеми потомками по-своему, есть все основания объявить ее абстрактной. Вы ведь заботитесь о тех, кто будет ваш код читать?

zerkms
Вы имеете ввиду в Singleton эту функцию объявить? А если PHP младше, чем 5.3? LSB-то еще не было.

 

[stanis]

Автор оригинала: FractalizeR
zerkms
Вы имеете ввиду в Singleton эту функцию объявить? А если PHP младше, чем 5.3? LSB-то еще не было.

Я так понял, что нет, объявлять её надо во всех классах, желающих стать синглтонами. LSB тут ни при чём.

-~{}~ 16.09.09 17:09:

Автор оригинала: zerkms ну и для пущей красоты реализовать интерфейс ISingleton. м?

Зерыч, а в какого рода приложениях нам надо штамповать синглтоны десятками инстансов? Я что-то как-то не представляю себе. Код, не стремящийся уйти от "жёсткой сцепки", а наоборот, на неё всячески направленный? Могу представить себе данный подход как эффективный только в одном случае: работодатель не вникает в код и работодатель платит за время.

 

[Beavis]

stanis
LSB тут при том, что он позволяет не объявлять одну и ту же функцию в каждом синглтоне, а объявить её только в базовом классе

 

[stanis]

Автор оригинала: Beavis
stanis
LSB тут при том, что он позволяет не объявлять одну и ту же функцию в каждом синглтоне, а объявить её только в базовом классе

Давай разберёмся. Предложенный Зерком вариант содержал ключевое слово "интерфейс". Ты знаешь, чем интерфейс отличается от класса?

 

[zerkms]

Beavis
не тормози.

 

[alex77]

FractalizeR

Но влияет на качество кода. Если подразумевается, что функция должна обязательно определяться всеми потомками по-своему, есть все основания объявить ее абстрактной. Вы ведь заботитесь о тех, кто будет ваш код читать?

на что ругается Strict Standards: Static function Singleton::getInstance() should not be abstract in ... %)

 

[FractalizeR]

Да, действительно

-~{}~ 16.09.09 15:15:

Раньше это было возможно:
http://www.php.net/manual/en/migration52.incompatible.php

 

[Mandor]

Автор оригинала: FractalizeR
Это-то понятно. Мне непонятна суть фразы "Не факт что потомки вашего класса (наследники синглтона) тоже должны быть синглтонами." Если они "не должны быть синглтонами", то зачем я могу захотеть их от него унаследовать?

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

 

[fixxxer]

Синглтон со static:: и наследованием - это фабрика, сделанная через задницу.

Не нужно этого хотеть.

 

[stanis]

Автор оригинала: fixxxer
Синглтон со static:: и наследованием - это фабрика, сделанная через задницу.

Золотые слова!

 

[Sad Spirit]

Разрешите привлечь ваше внимание к сделанной через задницу фабрике синглтонов.

 

[r4sh]

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

>>реестр умеет только хранить данные. сам инстанциировать объекты по имени он не должен
ага, иначе теряет смысл как реестр.

 

[zerkms]

r4sh
и это единственное, что у них будет общего в иерархии наследования. бред?

 

[r4sh]

Всегда надо выносить фабричный метод в отдельный класс?
Имеет смысл всегда базовый класс делать асбтрактным, и сразу создавать фабрику для порождения каждого класса в системе, если есть подозрение что когда-нибудь будет не только класс Product1, а еще класс Product2?
zerkms, ты же согласен, что применение шаблонов бывает и избыточным?

Фабрика как отдельный класс большее значение имеет когда нужно создавать несколько связанных между собой объектов Например HTMLHeader, HTMLfooter, HTMLBody , XMLHeader, XMLfooter, XMLBody - Примеры не из реальной жизни, что пришло в голову.

 

[zerkms]

Всегда надо выносить фабричный метод в отдельный класс?

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

zerkms, ты же согласен, что применение шаблонов бывает и избыточным?

согласен. а ещё я согласен, что программирование с гаданием не имеет ничего общего, поэтому

есть подозрение что когда-нибудь будет

- не аргумент

 

[r4sh]

Мм, может ты меня не так понял. Ситуация - класс product и наследники - concrete_product1, concrete_product2, concrete_product3. Я бы несколько раз подумал, создавать фабричный метод отдельным классом, для получения одного из продуктов, или реализовать фабричный метод как метод базового класса abstract product.

Если уже принято решение, что клиенту не нужно знать с каким конкретным продуктом он работает, он знает только интерфейс.

не аргумент

Поэтому и написал так. Что рефакторинг производится постепенно, и шаблоны не всегда выделяются сразу.

 

[zerkms]

Ситуация - класс product и наследники - concrete_product1, concrete_product2, concrete_product3.

у тебя изначально неверный посыл. в твоём примере иерархия уже существует и классы объединены чем-то общим. в обсуждаемой же теме единственная связь между классами в предке - способность порождать объекты.

 

[r4sh]

в обсуждаемой же теме единственная связь между классами в предке - способность порождать объекты.

А, тогда согласен с твоими суждениями День тяжелый был, с вечера плохо с внимательностью.