В двух словах, если метод переопределен в дочернем классе, то по ссылке $this на объекте вызовется именно он, если не переопределен, то вызовется родительский.
Спасибо! Правильно ли я понимаю, что в интерфейсах, говоря по-простому, можно только обозначить название метода, то есть без каких-либо действий внутри этого метода? Поэтому интерфейс и называется абстракцией?
Получается, что интерфейс - это как некоторая шпаргалка, чтобы программист не забыл, как называть нужный ему метод? Ведь по сути, можно и без интерфейсов создавать одноименные методы у разных классов, и кода вроде как будет поменьше.
Интерфейс лишь показывает имена, аргументы и тип возвращаемого значения методов объекта. После того как в коде мы проверили что объект реализует интерфейс, мы можем вызывать у него методы, указанные в интерфейсе. Кроме того мы можем указать в качестве аргумента метода интерфейс, и передавать туда объект любого класса, реализующего этот интерфейс.
То есть зная, что перед нами объект, реализующий такой-то интерфейс, то мы можем вызывать у него вот такие методы с такими-то аргументами и ожидать, что он это вернет.
Немного мудреный этот полиморфизм. Как я понял это, когда методы не зависят от определенного класса, их можно переопределять, т.е. в родительском классе хранится некая абстракция метода.
В дочернем классе мы можем строить из этих абстракций нечто новое свое, под определенную задачу подстраивать родительские методы и изменять.
Аналог с интерфейсом, мы не прописывали в интерфейсе что будет делать метод, это некая абстракция. А уже в классах мы описали что конкретно делает этот метод.
Я про принцип подстановки Барбары Лисков, где наследование должно дополнять базовый класс, а не переопределять его. Во всяком случае, везде пишут о том, что если наследуя, мы переопределяем родительские методы новой логикой, а не просто дополняем(расширяем) их, значит с архитектурой что-то не так...
А, вот вы про что) В целом да, следовать SOLID нужно, но не рассказать о возможности переопределения нельзя. Далее мы рассмотрим возможности интерфейсов и абстрактных классов в плане полиморфизма, без нарушения принципа L.
Здравствуйте Артём, я понимал проявление полиморфизма, в том что мы можем переопределить родительские методы в дочерних классах. Теперь прочитав комменты, получается что моё понимание не совсем верное, если следовать принципам SOLID. Или имеется ввиду, чтобы не полностью переписать родительский метод, а добавить в существующий функционал дополнительную логику? К примеру есть класс проверяющий авторизацию, с методом checkLogin, проверяет он допустим по одному логину, мы наследуемся от этого класса и добавляем в метод ещё и пароль. И тут у меня возникает вопрос зачем мне наследоваться, если я могу в родительском классе в метод добавить этот пароль?
Или у меня пример кривой?
Пример какой-то кривой, что это за проверка только по логину) Полиморфизм - про возможность зависеть от какого-то интерфейса (публичные методы родительского класса тоже являются интерфейсом, через который происходит взаимодействие и с объектами родительского класса, так и дочернего), а не реализации. К примеру, при отсутствии полиморфизма было бы невозможно использовать объект дочернего класса вместо объекта родительского класса.
Большое спасибо за очередной качественный урок! До сих пор не перестаю радоваться формату материала. Чувствуется, что автор делал это от чистого сердца. Мир=)
Спасибо классный урок, как работает разобрался, однако сформулировать для себя что именно такое полиморфизм до конца не смог)
Главное что понял как работает, потом сформулируешь, программируй давай)
Дмитрий, пригодилось понимание полиморфизма в реальной практике?)
Ну я так понял что, полиморфизм это способность функции выполняться в зависимости от внешних факторов
В двух словах, если метод переопределен в дочернем классе, то по ссылке $this на объекте вызовется именно он, если не переопределен, то вызовется родительский.
Суть не только в этом. Прежде всего это возможность зависеть от абстракций, а не от реализаций.
Безусловно, просто с ходу понять эти абстракции очень не просто...
Сходу да, со временем придёт =)
Можно на пальцах, что именно тут имеется ввиду под понятиями абстракция и реализация? Уроки мне нравятся, спасибо!
Абстракция - это интерфейс, а реализация - это классы. Могут быть разные классы, реализующие один и тот же интерфейс.
Спасибо! Правильно ли я понимаю, что в интерфейсах, говоря по-простому, можно только обозначить название метода, то есть без каких-либо действий внутри этого метода? Поэтому интерфейс и называется абстракцией?
Получается, что интерфейс - это как некоторая шпаргалка, чтобы программист не забыл, как называть нужный ему метод? Ведь по сути, можно и без интерфейсов создавать одноименные методы у разных классов, и кода вроде как будет поменьше.
Интерфейс лишь показывает имена, аргументы и тип возвращаемого значения методов объекта. После того как в коде мы проверили что объект реализует интерфейс, мы можем вызывать у него методы, указанные в интерфейсе. Кроме того мы можем указать в качестве аргумента метода интерфейс, и передавать туда объект любого класса, реализующего этот интерфейс.
То есть зная, что перед нами объект, реализующий такой-то интерфейс, то мы можем вызывать у него вот такие методы с такими-то аргументами и ожидать, что он это вернет.
Рад что сюда попал. Толковое объяснение. Спасибо.
На здоровье, дружище!)
Понятно, спасибо!
Спасибо за уроки!
Спасибо за твой выбор в пользу этих уроков)
Спасибо за урок, конечно полностью понять трудно но суть логики данного кита немного понял...)
Немного мудреный этот полиморфизм. Как я понял это, когда методы не зависят от определенного класса, их можно переопределять, т.е. в родительском классе хранится некая абстракция метода.
В дочернем классе мы можем строить из этих абстракций нечто новое свое, под определенную задачу подстраивать родительские методы и изменять.
Аналог с интерфейсом, мы не прописывали в интерфейсе что будет делать метод, это некая абстракция. А уже в классах мы описали что конкретно делает этот метод.
Если я правильно понял:)
Всё верно. Возможность выбора реализации во время выполнения кода и есть полиморфизм
спасибо за уроки!!
как я понял, какой метод ближе, тот и вызывается) как по принципу наследования
Да, реализация в ближайшем родительском классе
А как это соотносится с принципом SOLID?
Это хорошая идея - переопределять наследуемые методы?
Это хорошая идея когда это нужно. Вас что-то смущает?
P.S. SOLID - это не один принцип.
Я про принцип подстановки Барбары Лисков, где наследование должно дополнять базовый класс, а не переопределять его. Во всяком случае, везде пишут о том, что если наследуя, мы переопределяем родительские методы новой логикой, а не просто дополняем(расширяем) их, значит с архитектурой что-то не так...
А, вот вы про что) В целом да, следовать SOLID нужно, но не рассказать о возможности переопределения нельзя. Далее мы рассмотрим возможности интерфейсов и абстрактных классов в плане полиморфизма, без нарушения принципа L.
Здравствуйте Артём, я понимал проявление полиморфизма, в том что мы можем переопределить родительские методы в дочерних классах. Теперь прочитав комменты, получается что моё понимание не совсем верное, если следовать принципам SOLID. Или имеется ввиду, чтобы не полностью переписать родительский метод, а добавить в существующий функционал дополнительную логику? К примеру есть класс проверяющий авторизацию, с методом checkLogin, проверяет он допустим по одному логину, мы наследуемся от этого класса и добавляем в метод ещё и пароль. И тут у меня возникает вопрос зачем мне наследоваться, если я могу в родительском классе в метод добавить этот пароль?
Или у меня пример кривой?
Пример какой-то кривой, что это за проверка только по логину) Полиморфизм - про возможность зависеть от какого-то интерфейса (публичные методы родительского класса тоже являются интерфейсом, через который происходит взаимодействие и с объектами родительского класса, так и дочернего), а не реализации. К примеру, при отсутствии полиморфизма было бы невозможно использовать объект дочернего класса вместо объекта родительского класса.
Согласен пример не подходящий, но всё-же моё понимание верное или нет?
Мне кажется у вас спуталось понимание полиморфизма и принципов SOLID. Прочитайте статьи в интернетах и про то и про это.
Большое спасибо за очередной качественный урок! До сих пор не перестаю радоваться формату материала. Чувствуется, что автор делал это от чистого сердца. Мир=)
Как я понял.
Полиморфизм - это использование метода с одним и тем же названием, но с разным функционалом. Это вкратце.
С начала этого курса меня прет от того, насколько это интересно. Спасибо большое, разбираемся дальше)
Рад слышать) Успехов в обучении!