Видимость метода при расширении абстрактного класса в PHP

Question

Видимость метода при расширении абстрактного класса в PHP

0

В моем абстрактном классе My_Class меня есть метод My_Class::foo() который вызван из другого метода, принадлежащего классу. Например:

abstract class My_Class {
    function foo() {
        // Stuff.
    }

    function bar() {
        $this->foo();
    }

    // More methods etc...
}

Теперь я занимаюсь расширением своего абстрактного класса. Например:

class My_Class_Extended extends My_Class {

}

Как вы узнаете, My_Class::foo() и My_Class::bar() наследуются My_Class_Extended.

Я никогда не хочу My_Class::foo() будет называться вне My_Class или My_Class_Extended, так что я не знаю, чтобы сделать его видимость public. Моя проблема в том, что я не уверен, чтобы сделать ее видимость protected или private.

Мой вопрос

Учитывая, как я называю My_Class::foo() в приведенном выше сценарии, должен ли он быть protected или private? Я не уверен, что вызов My_Class::foo() происходит из дочернего или родительского класса.

Заранее спасибо.

henrywright 10 март 2015, в 14:17

Источник

4

Как правило, всегда используйте защищенный, если у вас нет особой причины, почему он должен быть закрытым
Mark Baker 10 март 2015, в 12:21
0

возможный дубликат PHP: публичный, частный, защищенный
Mark 10 март 2015, в 12:25
0

Вы спрашиваете о разнице между защищенным и частным? Потому что оба скрывают эту функцию от стороннего мира. Разница в том, что защищенный делает функцию доступной для дочерних классов. Если вы этого хотите или нет, полностью зависит от архитектуры вашего приложения и ваших предпочтений.
Quasdunk 10 март 2015, в 12:26
0

Это действительно дубликат (см. Здесь: stackoverflow.com/questions/4361553/… ), но если вам нужно что-то, что должно быть доступно дочернему классу, оно должно быть защищено.
Mark 10 март 2015, в 12:26
0

Я обновил вопрос, чтобы показать, что то, что я спрашиваю, немного отличается от вопроса, с которым вы связаны.
henrywright 10 март 2015, в 12:43
0

protected свойства и методы приводят к нарушениям Открыто-Закрытого Принципа , потому что они могут быть изменены в классе потомка
Yang 10 март 2015, в 12:54
0

@bad_boy, ты меня запутал. Разве я не должен использовать protected тогда?
henrywright 10 март 2015, в 13:05
0

@henry Защищенные переменные и методы имеют свое собственное использование, но в основном люди продолжают злоупотреблять ими. Как правило, вы должны попытаться написать классы, которые делают только одно , и пометить их внутренние инструменты (методы и свойства) как private . И сам класс должен быть помечен как final class Foo {} . Что касается защищенных методов, вы всегда должны помечать их как final если вы не собираетесь переопределять этот метод в классе-потомке.
Yang 10 март 2015, в 13:13
0

Во всяком случае, это целая тема, я не могу ответить обо всех лучших практиках по этому вопросу в одном предложении. Вам лучше поискать что-то вроде этого: защищенные переменные нарушают инкапсуляцию или наследование нарушают инкапсуляцию
Yang 10 март 2015, в 13:15
0

@bad_boy - лично я с тобой не согласен .... частное часто противоречит OCP именно потому, что оно не открыто, хотя предполагается, что единственный способ открыть что-то - это наследование и не использовать возможности Composition. в учетную запись
Mark Baker 10 март 2015, в 13:42
0

@MarkBaker Проще говоря, OCP подразумевает, что разработчик должен писать классы таким образом, чтобы другие разработчики не могли изменять , а только использовать его и расширять без изменения «предыдущего» состояния. Это то, что мы оба имеем в виду? Моя точка зрения заключается в том, что при объявлении защищенного метода его следует пометить как final чтобы его нельзя было переопределить в дочерних классах, тем самым придерживаясь OCP. Что касается защищенных свойств, в PHP нет способа сделать их final , чтобы их нельзя было легко изменить в потомках. Опять же, все это связано с наследованием и проблемами, вызванными этим
Yang 10 март 2015, в 13:59
0

Вот почему я все равно предпочитаю композицию наследованию .... но использование private для всего может привести к сложным ошибкам при расширении класса и использовании нового метода / свойства с тем же именем
Mark Baker 10 март 2015, в 14:40

Показать ещё 10 комментариев

Теги:

php

oop

1 ответ

Ещё вопросы

Как правило, всегда используйте защищенный, если у вас нет особой причины, почему он должен быть закрытым
возможный дубликат PHP: публичный, частный, защищенный
Вы спрашиваете о разнице между защищенным и частным? Потому что оба скрывают эту функцию от стороннего мира. Разница в том, что защищенный делает функцию доступной для дочерних классов. Если вы этого хотите или нет, полностью зависит от архитектуры вашего приложения и ваших предпочтений.
Это действительно дубликат (см. Здесь: stackoverflow.com/questions/4361553/… ), но если вам нужно что-то, что должно быть доступно дочернему классу, оно должно быть защищено.
Я обновил вопрос, чтобы показать, что то, что я спрашиваю, немного отличается от вопроса, с которым вы связаны.
protected свойства и методы приводят к нарушениям Открыто-Закрытого Принципа , потому что они могут быть изменены в классе потомка
@bad_boy, ты меня запутал. Разве я не должен использовать protected тогда?
@henry Защищенные переменные и методы имеют свое собственное использование, но в основном люди продолжают злоупотреблять ими. Как правило, вы должны попытаться написать классы, которые делают только одно , и пометить их внутренние инструменты (методы и свойства) как private . И сам класс должен быть помечен как final class Foo {} . Что касается защищенных методов, вы всегда должны помечать их как final если вы не собираетесь переопределять этот метод в классе-потомке.
Во всяком случае, это целая тема, я не могу ответить обо всех лучших практиках по этому вопросу в одном предложении. Вам лучше поискать что-то вроде этого: защищенные переменные нарушают инкапсуляцию или наследование нарушают инкапсуляцию
@bad_boy - лично я с тобой не согласен .... частное часто противоречит OCP именно потому, что оно не открыто, хотя предполагается, что единственный способ открыть что-то - это наследование и не использовать возможности Composition. в учетную запись
@MarkBaker Проще говоря, OCP подразумевает, что разработчик должен писать классы таким образом, чтобы другие разработчики не могли изменять , а только использовать его и расширять без изменения «предыдущего» состояния. Это то, что мы оба имеем в виду? Моя точка зрения заключается в том, что при объявлении защищенного метода его следует пометить как final чтобы его нельзя было переопределить в дочерних классах, тем самым придерживаясь OCP. Что касается защищенных свойств, в PHP нет способа сделать их final , чтобы их нельзя было легко изменить в потомках. Опять же, все это связано с наследованием и проблемами, вызванными этим
Вот почему я все равно предпочитаю композицию наследованию .... но использование private для всего может привести к сложным ошибкам при расширении класса и использовании нового метода / свойства с тем же именем

Sbls · Answer 1 · 2015-03-10T11-17-00.000Z

Однострочный: защищенный, потому что вы хотите, чтобы ваши дочерние классы имели доступ

Модификаторы видимости работают следующим образом:

общественность: видимая отовсюду.
- $c = new My_Class_Extended(); $c->thisIsPublic(); , Это не работает с частными или защищенными
protected: видимый внутри класса и его дочерние классы
- Вы можете вызывать только эти функции внутри функции, принадлежащей классу, который происходит от вашего родительского класса или самого родительского класса.
private: видна только для класса, в котором он определен. Вы не можете вызывать частные функции в дочерних классах и вне класса.

Модификаторы заказываются включительно. Таким образом, защищенный является более ограничительным, чем общедоступный, а частный более ограничительный, чем защищенный.

Вы хотите защитить, потому что вы хотите вызвать их внутри дочернего класса, но не за его пределами.

Кстати: в вашем контексте ключевое слово abstract гарантирует, что вы не сможете создать экземпляр из My_Class.

«Вы хотите защищаться, потому что хотите вызывать их внутри дочернего класса, но не вне его». Но, учитывая мой сценарий, действительно ли вызов My_Class::foo() происходит из дочернего класса? я не уверен
ааа! Я неправильно понял ваш вопрос. В вашем примере это не от дочернего класса. Таким образом, вы можете сделать это частным. Но это не позволит вам вызвать его внутри My_Class_Extended . Если вы также хотите иметь возможность вызывать его внутри My_Class_Extended вы должны сделать его защищенным.
«В вашем примере это не из дочернего класса». <- это та часть, которую я изо всех сил пытался понять. Я думал, поскольку метод bar() наследуется дочерним классом, тогда вызов функции foo() будет происходить в дочернем классе. Но вы говорите, что это не так?
Звучит правильно. Вы можете рассматривать оба класса отдельно. My_Class_Extended не переопределяет ни одну из родительских функций. Так что foo() вызывается в My_Class . Представьте, что foo() будет приватным. My_Class_Extended не может видеть foo , поэтому это единственная возможность быть выполненной в My_Class . Может быть , этот пример даст вам больше информации: 3v4l.org/Yg8n3 Там нет функции foo() в My_Class_Extended , следовательно , вызов foo() не может быть в дочернем классе.
Спасибо за ссылку на пример. Одна вещь: «В My_Class_Extended отсутствует функция foo ()» - так вы говорите, что хотя foo() наследуется My_Class_Extended , он не считается методом, принадлежащим этому классу?
Ну, я не сказал это идеально. foo() принадлежит My_Class_Extended . Но поскольку мы говорим о том, какое тело функции выполняется, оно не может быть телом функции в My_Class_Extended потому что его не существует. Чтобы быть педантичными, нестатические методы вызываются не внутри классов, а в объектах.