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

_____________
[продано копирайтерам]

glock18
Блин, я говорю о возможных последствиях копания-рефакторинга приватных методов, а не возможности использования их при оверрайдинге. Сама постановка утверждения, что с приватным методом методом можно делать всё что угодно, вплоть до удаления его из кода без последствий - некорректна. Так оно или иначе, но используемый приватный метод, при том же удалении, требует рефакторинга всего кода, где этот метод используется. Оно и ежу понятно, что приватный метод или поле класса являются собственностью только этого класса и предназначен для использования только внутри этого класса.

_____________
Gear Framework
Gear Framework на Github

linker
Разница в том, что protected вы не можете изменить/удалить, даже с рефакторингом класса.

MiksIr

MiksIr

MiksIr

MiksIr

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

// Core class
class VendorView 
{
    private function displayJavascript()
    {
        echo '<script type="text/javascript" scr="dslakdjaskl.js"></script>';
    }
    
    public function display()
    {
        // display something
    }
    
}

// user class
class CustomVendorView extends View 
{

    public function display()
    {
        echo '<script type="text/javascript" scr="dslakdjaskl.js2"></script>';
        parent::display();
    }

}

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

// Core class
class VendorView 
{
    protected function displayJavascript()
    {
        echo '<script type="text/javascript" scr="dslakdjaskl.js"></script>';
    }
    
    public function display()
    {
        // display something
    }
    
}

Пример, приукрашен. Таки вопрос, почему же не делать протектид во избежании таких казусов? Ведь сегодня одни требования, а завтра другие, и возможно ваш класс нужно будет расширять в том месте где вы сами и не догадывались. И да все мои вопросы, так же относятся и к final

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

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

1. public - интерфейс общения с внешней средой
2. protected - интерфейс общения внутри связей родитель-потомок
3. private - интерфейс общения внутри одного класса

Всё это объединяется одним понятием - инкапсуляция. Private применяется когда необходимо скрыть реализацию родителя от возможных потомков. Protected - когда необходимо скрыть реализацию от сторонних классов, но при этом сохранить полиморфность при наследовании, т.е. возможности при необходимости переопределить нужный метод, дабы изменить его поведение исходя из новых реалий потомка.

Финальный метод нельзя переопределить просто потому, что его функциональность конечна.

Не знаю как ещё объяснить, я ж не теоретик.

_____________
Gear Framework
Gear Framework на Github