Как вы смотрите, с точки зрения ООП, на конструктор в абстрактном классе?)

прекрасно

а что смущает?

главное еще сделать в конструкторе вызов абстрактной функции например init() , которая будет описана в конечном классе и дополнительно инициализировать объект abstract class MyClass { public function __construct($data) { // Готовим данные абстрактного класса, сетим основные данные // ....... // Готовим или подменяем данные уже в наследнике $this->init($data); } abstract protected function init($data); }

Как вы смотрите, с точки зрения ООП, на конструктор в абстрактном классе?)

негативно, как и на абстрактные классы в принципе

а я так и не разобрался в конструкторах...

сложно

негативно, как и на абстрактные классы в принципе

но если они уже есть, то чем конструктор в них ухудшит что то?

но если они уже есть, то чем конструктор в них ухудшит что то?

констурктор это деатль реализации

ее не должно быть в асбтракции

ее не должно быть в асбтракции

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

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

любой класс содержит конструктор, явно или не явно, даже абстракнтый

Как вы смотрите, с точки зрения ООП, на конструктор в абстрактном классе?)

ни как, от слова совсем, это тоже самое что и трейт, с точки зрения абстракции и тп он не несет никакого смысла так как инстанс не может быть создан

по этому добавление явного конструктора ничего не поменяет с точки зрения дизайна абстрактного класса

ну и да как и говорилось раньше это деталь реализации

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

хуже уже не будет)

хуже уже не будет)

именно =)

главное еще сделать в конструкторе вызов абстрактной функции например init() , которая будет описана в конечном классе и дополнительно инициализировать объект abstract class MyClass { public function __construct($data) { // Готовим данные абстрактного класса, сетим основные данные // ....... // Готовим или подменяем данные уже в наследнике $this->init($data); } abstract protected function init($data); }

а чем это отличается от parent/super вызова?

а чем это отличается от parent/super вызова?

свою функцию можно сделать обязательной для реализации + сигнатуру описать. для конструктора не знаю возможно ли такое

а чем это отличается от parent/super вызова?

обязательность реализации метода

свою функцию можно сделать обязательной для реализации + сигнатуру описать. для конструктора не знаю возможно ли такое

ну такое, и скорее всего этот метод будет протектед, в принципе тоже самое, что и абстрактные методы в трейтах

те полиморфизм здесь не причем

так как реализация метода нужна только для инциализации объекта

ну я просто предположил, я ни трейты, ни протектед ни абстрактные классы не юзаю обычно)

ну и абстрактные protected методы это больше про реализацию

ну я просто предположил, я ни трейты, ни протектед ни абстрактные классы не юзаю обычно)

копипастишь?)

нет, делю ответственности и юзаю аггрегацию

тот неловкий момент, когда ощущаешь себя недочеловеком: и абстрактные классы, и конструкторы в оных, и протектед методы - усё есть)

тот неловкий момент, когда ощущаешь себя недочеловеком: и абстрактные классы, и конструкторы в оных, и протектед методы - усё есть)

фу таким быть

фу таким быть

не знаю, мне ок)

тот неловкий момент, когда ощущаешь себя недочеловеком: и абстрактные классы, и конструкторы в оных, и протектед методы - усё есть)

так у меня тоже есть в проекте, но целеноправленно я их не юзаю, и понимаю какие траблы из за этого говна)

Как вы смотрите, с точки зрения ООП, на конструктор в абстрактном классе?)

если у тебя есть конструктор в абстрактном классе значит 90% что то что в абстрактном классе можно вынести как просто зависимость которую можно заинджектить. Это будет намного более разумно с точки зрения связанности.

так у меня тоже есть в проекте, но целеноправленно я их не юзаю, и понимаю какие траблы из за этого говна)

да хер знает где вы траблы находите) я существо тупое, пока чёт не упарывался :(

с другой стороны если мы закроем глаза на необходимость "пробрасывать" зависимости базового типа, и весь стэйт private то как бы не то что бы и сильно плохо

если у тебя есть конструктор в абстрактном классе значит 90% что то что в абстрактном классе можно вынести как просто зависимость которую можно заинджектить. Это будет намного более разумно с точки зрения связанности.

скорее всего это сделано, чтобы в насделниках не копипастить конструктор

да хер знает где вы траблы находите) я существо тупое, пока чёт не упарывался :(

тож хз, ну подумаешь следить сложнее будет за инвариантами.... как будто кто-то особо следит)

скорее всего это сделано, чтобы в насделниках не копипастить конструктор

хз надо смотреть почему так. Но это может быть симптомом проблем с декомпозицией

ну и я бы лучше скопипастил конструктор)

это не будет дублированием в общем

тож хз, ну подумаешь следить сложнее будет за инвариантами.... как будто кто-то особо следит)

ну чем сложнее-то?)

ну чем сложнее-то?)

ну это чуть проще чем следить за глобальными переменными

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

блин) без кода тяжко) я не понимаю в чём эфимерная сложность возникает и как всё это можно сравнивать с глобалами :(

блин) без кода тяжко) я не понимаю в чём эфимерная сложность возникает и как всё это можно сравнивать с глобалами :(

сложность только когда у тебя public/protected стэйт. Если весь стэйт базового класса private то все норм

угу, с примером стало понятнее)