Должны ли конструкторы подклассов быть приватными при реализации синглтона?

Question

[Алексей Николаев]

Доброго времени!

Есть классический singleton-класс. От него наследуются другие классы. Вопрос: должны ли эти классы точно так же реализовывать логику паттерна (т.е. через getInstance), или их-то как раз можно создавать классическим образом через new? Есть ли какие-либо рекомендации на этот счет, или паттерн можно применять по необходимости даже в подклассах?

Как вариант, корректен ли и хорош ли с точки зрения чистоты и красоты программирования создать в родительском классе переменные по типу инстанса:
public static $_controller;
...и после, создавать их в наследуемом классе:
parent::$_controller = new self;
Чтобы таким образом иметь экземпляры подклассов, сконцентрированных в едином главном классе?

Буду благодарен за советы и рекомендации, спасибо.

Answer 1

[Алексей Николаев]

Как выяснилось годом позже, речь шла о разновидности Dependency Injection, и по факту к синглтону вопрос не имел отношения.

Answer 2

[Alexander Sydorenko]

Эммм.. Классический синглтон не может быть отнаследован. У него приватный конструктор. Разве нет? habrahabr.ru/post/31375

Comments

[DancingOnWater]

Сделать его protected, делов-то

[Alexander Sydorenko]

@DancingOnWater: Его можно и пабликом сделать.. Но он тогда перестанет быть класическим синглтоном в моем понимании синглтона.

[DancingOnWater]

Не стоит передергивать. protected конструктор все также недоступен внешнему коду.
Вызвать же базовый инстанс в этом случае не получится, т.к. базовый должен иметь фабричный метод.
Да, действительно это не совсем классический синглетон, но отличия минимальны. Гораздо меньше, нежели между синглетоном Майерса и синглетоном с подсчетом ссылок

[Алексей Николаев]

Alexander Sydorenko почему же? Конструктор у наследуемых подклассов будет их собственный. Это если там прописать parent::__construct - тогда да, а если нет, то все ок работает.

[Alexander Sydorenko]

Алексей Николаев: @DancingOnWater: Ок, тогда объясните, пожалуйста, мне логику _статической_ _приватной_ переменной $_instance (или как обычно называете) для класса singleton? Я понимаю так:

1. раз конструктор будет protected, то он не сможет проинициализировать в наследнике статическую приватную переменную $_instance
2. если сделать $_instance protected, тогда получиться, что getIncantce наследника, перепишет при ранней иницализации parent::$_instance, и при последующем вызове парент вернет чепуху - инстанс наследника.
3. Если изощрятся и в наследниках добавлять еще и свою собственную приват статик $_instance тогда зачем делать таких наследников?

Answer 3

[DancingOnWater]

Есть классический singleton-класс. От него наследуются другие классы. Вопрос: должны ли эти классы точно так же реализовывать логику паттерна (т.е. через getInstance), или их-то как раз можно создавать классическим образом через new?

Если вы наследуетесь от синглетона, значит вы хотите. чтоб эти классы были тоже синглетонами. Тогда ответ очевиден - да.
Если же вы не хотите, чтоб классы были синглетонами, значит вам не надо наследоваться и тогда ответ -нет.

Как вариант, корректен ли и хорош ли с точки зрения чистоты и красоты программирования создать в родительском классе переменные по типу инстанса:
public static $_controller;
...и после, создавать их в наследуемом классе:
parent::$_controller = new self;
Чтобы таким образом иметь экземпляры подклассов, сконцентрированных в едином главном классе?

Буду благодарен за советы и рекомендации, спасибо.

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

Comments

[Алексей Николаев]

@DancingOnWater спасибо за развернутый ответ! Немного поясню: есть класс плагина, который свою работу строит на запросах к БД, и данные сохраняет у себя в переменной. Он реализован по принципу MVC, то есть у него есть родительский класс Plugin (singleton), и классы PluginModel, etc. Переменная, хранящая в себе данные, одна и находится в Plugin, посему он должен быть один на всю систему (чтобы минимизировать повторные запросы). А остальные классы я пока сделал обычными (просто не прописал в их конструкторах вызов конструктора родителя).

У меня были сомнения в логичности этого шага, т.к. как-то костыльно смотрится, теперь вижу, что в общем-то не ошибался и они все должны быть синглтонами в этом случае.

Answer 4

[asd111]

По моему в вашем случае лучше сделать protected static controller чтобы он был недоступен для ненаследников и писать self::controller=new self() тогда ваш родитель будет как интерфейс а наследники будут его реализовывать

Comments

[Алексей Николаев]

Спасибо за идею!

Answer 5

[Григорий Васильков]

Кажется я понял что ты имеешь в виду. Сейчас сам как раз копаюсь над этим.
Ты хочешь микро-модули сделать, которые контроллируются из единой оболочки/шины/модуля, так?

В JS это очень четко делалось:

App = {};
Module = {
  b : function() {}
};
App.b = Module.b;
App.b();

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

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

Comments

[Алексей Николаев]

Именно! В результате, к слову, забил на это и сделал несколько независимых классов, экземпляры которых либо передавал через внедрение зависимости в __construct, либо в том же __construct создавал по необходимости

[Григорий Васильков]

а я таки сделал. позвони в вайбер 375 33 656 2680 скину тебе код.