Еретики... и private нужен, и strict. Я везде применяю strict, чтобы в подсказках лишние методы не маячили.

Dimitry SibiryakovУ классов для сторонних пользователей любое private смердит, поскольку не позволяет использовать полиморфизм ради которого (в том числе) классы и задумывались.

И каким же образом доступность кишок класса связана с полиморфизмом?

Вообще. Я вижу так: public и protected - это интерфейс, API. Менять его может быть затруднено и болезненно. А private - это внутренняя реализация, которую можно менять как вздумается. И без этой области свободных манипуляций внесение изменений в класс взрастит такой геморрой у разработчика, что ну вас нафиг с такими идеями.

Dimitry SibiryakovПриватные методы нельзя оверрайдить. К приватным полям нельзя достучаться. Изменить
поведение базового класса, автор которого злоупотреблял приватностью, невозможно.
Полиморфизм недоступен.

Полиморфизм вполне себе доступен в рамках, отведенных для этого автором. Всё, что свыше этого, - от лукавого либо результат совсем уж убогой реализации. А вот доступ к кишкам класса куда вреднее. Например:


При этом FSomeObj всегда создается в конструкторе и потому предполагается, что всегда не nil. Но условному апологету безграничного полиморфизма не нравится доступ по свойству, и он использует FSomeObj. А потом автор понимает, что FSomeObj нужен далеко не всегда и не сразу, поэтому встраивает создание перед использованием, меняя объявление на


И вот тут апологет ловит AV at address $000000 и идет курить бамбук.

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

Valery_BЕсли ты не разрабатываешь компоненты, то лучше использовать 1 модуль=1 класс.
Явист детектед))