Причины, чтобы избежать модификаторов доступа в php

Каковы действительные причины НЕ использовать ключевые слова public, private, protected in php?

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

Я знаю, что некоторые подобные темы уже существуют

Важность защищенных / частных в PHP-классах
Почему бы не использовать «защищенный» или «закрытый» в PHP?
Лучше всего использовать частные методы или защищенные методы?

однако есть несколько причин, по которым я отправляю этот

Я не спрашиваю, следует ли мне использовать «публичный» или нет. Я уже не использую его.
Мне явно не интересно слышать, почему модификаторы доступа хороши (я знаю, что они плохие, мне просто нужен эксперт, чтобы подтвердить это).
Если вы расскажете мне о «лучших практиках» и «принципах ООП», пожалуйста, не беспокойтесь.

ТИА

Related of "Причины, чтобы избежать модификаторов доступа в php"

private модификатор – imho – сильно злоупотребляют. Проблема заключается в том, что он не позволяет расширять классы. Но что более важно, это концепция, которая заставляет писать код, который является ориентированным на классы, а не объектно-ориентированным.

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

действительные причины НЕ использовать ключевые слова public, private, protected in php?

когда вы хотите быть обратно совместимыми с PHP4 (потому что они не существуют в PHP4)
когда кодовое соглашение определяет / разрешает
когда не заботятся об инкапсуляции и скрытии информации
когда не используется парадигма ООП в PHP (нет классов, нет видимости)

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

Это похоже на нетипизированные переменные: на типизированных языках каждая переменная явно вводится в строчную форму, но в PHP предполагается, что программист знает тип каждой переменной.

Марио прибил его (скопировал из комментариев)

Модификаторы доступа имеют смысл в Java / C ++ и скомпилированный код в целом, где они подлежат исполнению. На нескомпилированных языках сценариев их можно легко вырвать. Следовательно, их следует рассматривать только как декораторов, и, таким образом, прагматично может быть реализовано как соглашение о кодировании. (См. Underscoritis в Python и почти любой другой язык сценариев. PHP довольно одинок с бесцельными декораторами доступа.)

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