открытости закрытости

открытости закрытости чего?))

если я его открыл значит можно юзать

и потом мне сложно модифицировать свой код

если статики юзать вместо именованных конструкторов, то вполне ок

я открыл доступ к тому к чему не следовало

ты также можешь сказать, что конструктор потом менять плохо

или любой другой публичный метод

ну да

так и есть)

менять публичный метод плохо, но иногда можно

если профит от изменения перекрывает недостатки

поэтому прежде чем написать public надо подумать

вообще менять публичный метод не так плохо

недостатки это только боязнь изменения?

менять публичный метод интерфейса еще хуже

не боязнь а проблема в том что кто то мог юзать этот метод

и ему придется менять код

а если окажется что после его модификаций он что то публичное уберет

ну поменяй, так бывает

это затронит других

и так цепочкой

короче таки боязнь

если у тебя кода на 1000 строк то проблем нет

тут не боязнь а скорее предостережение

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

чем меньше публичных методов тем меньше тебе поддерживать

https://www.youtube.com/watch?v=9NANcPTbDBQ

я открыл доступ к тому к чему не следовало

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

чем меньше поддерживать тем меньше кода

речь не о конструторе

именованные конструкторы - один из вариантов использования статических функций

например

функции без зависимостей, чистые - тоже плохо?

публичный конструктор

без аргументов

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

ты пишешь (LoggerInterface $logger)

и теперь все места где объект создавался надо передавать logger

гораздо лучше чтобы LoggerInterface $logger = new NullLogger())

было бы

и там где надо логировать уже передавать нужное

функции без зависимостей, чистые - тоже плохо?

почему бы для этого функции не юзать?)

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

ммм.. это щас к чему?

а если ты каждую неделю меняешь код

логировать именованные конструкторы или как?

от которого зависят другие люди

то как то не приятно

именнованные конструкторы это по сути теже фабрики

только они на основе разных вещей создают экземпляр

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

в особенности в интерфейс

в интерфейс пихать статичекие сигнатуры?

это еще зачем?

getInstance для singleton местами вписывают

фабричные методы не люблю из за статических методов, которые доступны где угодно

мы за синглтоны сейчас не говорим

речь идет конкретно о фабричных методах, а конкретно именованных конструкторах

хорошо давай детально

что мешает тебе сделать new Date в любом месте?

точно так же и Date::createFromTime(..)

что в этом конкретно плохого для тебя?

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

в пхп нет пакетов

другими участниками команды по возможности выносить в интерфейс

namespace

у тебя все сущности и DTO тоже с интерфейсами?

если раз уже речь о пхп

ограничений на неймспейсы нет как package-private в джаве

так что они не в счет

я сейчас говорю о той ситуации

когда люди создают кучу публичных штук и не скрывают это интерфейсом

я не против именнованных конструторов

зачем тебе скрывать под интерфейсом статику?

и причем здесь статические методы(конструкторы)

но когда они не уходят за пределы твоего namespace

или если это явно не необходимая вещь

чтобы юзать за пределами по поводу dto нет конечно не везде интерфесы

я не только про скрывать под интерфейсом статику имею ввиду

мы вроде о статике говорили

тебя понесло в интерфейсы и связанность

я говорю следующее что лучше прежде чем написать public стоит хорошо подумать

и если есть возможность писать private

ок... приватный именованный конструтор?)

и где ты его использовать будешь?

возвращаясь к конструкторам

приватный именнованный конструктор это глупо

так как он бесполезен

я хочу сказать что в большинстве случаев достаточно одного конструтора!

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

это не его проблема

его ответсвенность делать что полезное

и желательно только одно

а кому и как создавать этот класс это их проблема

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

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

не всегда, они имеют доступ к созданному обьекту. поэтому конструктор может быть вообще пустым

давай пример

я предпочитаю использовать ContainerInterface

и он обычно есть только в App а уже объект создается на основе того что запросил в конструкторе