-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Доступ к приватным свойствам родительского класса, парадигма ООП или баг?
- Автор темы phpamid
- Дата начала
Духовность™
Продвинутый новичок
+1001!!!!
А я бы предпочел строгую типизацию и поддержку объектов примитивного типа.
В общем, судя по всему тут Adelf прав:
phpamid
Новичок
Не уместен, т.к. private - четко разделяет отношение к конкретному классу.
Adelf
Скорее всего так придеться делать, или явно переопределять метод в дочернем классе или еще чего-нибудь.
Если подводить черту, то судя по всему - это поведение PHP.
Может кто встречался с данной ситуацией в других языках ? (Python, Ruby ..) p.s. Заранее прошу прощения за вопрос не относящийся к PHP.
phpamid
triumvirat
Народ. Наароод
Читаем фразу:
-~{}~ 30.07.10 15:37:
Мм.. чет у меня в конторе опять инет повис. Пока отправлялось уже много чего успели понаписать.
-~{}~ 30.07.10 15:39:
> Если подводить черту, то судя по всему - это поведение PHP.
Нет, это по канонам ООП так.
Конфликт имен здесь неуместен. приватные вещи существуют только внутри своего класса. Вне его - их просто нет.
triumvirat
Народ. Наароод
Читаем фразу:Ну ничем. Это как два класса с одинаковым именем, но в разных неймспейсах. Это уяснили? Это важно. Идем дальше. Либо внимательно смотрим на код от codex, либо слушаем меня. Метод родителя достается нам.. ну на правах аренды чтоли. Он как бы в нашем классе тоже есть, но на самом деле когда он вызывается в контексте нашего обьекта, то для того, чтобы правильно вызвать этот метод обьект класса Son должен прикинутся обьектом класса Father(ведь метод определен там). И show_private_member() вызывается в контексте именно отца, а там знают только свой $my_private_member, который как мы уже знаем НУ НИКАК не связан с приватным мембером сына.
-~{}~ 30.07.10 15:37:
Мм.. чет у меня в конторе опять инет повис. Пока отправлялось уже много чего успели понаписать.
-~{}~ 30.07.10 15:39:
> Если подводить черту, то судя по всему - это поведение PHP.
Нет, это по канонам ООП так.
Конфликт имен здесь неуместен. приватные вещи существуют только внутри своего класса. Вне его - их просто нет.
В этом-то и трудность. Там где нужно делать объекты из запчастей, пытаются наследовать все и вся. Хотя язык вам всеми силами кричит - не делайте так!
Данный код, который мы видели в первом посте, визуально мешает в кучу методы доступа к приватным свойствам родителя и потомка.
Мне просто довольно странно было наблюдать такой код, потому как с моей точки зрения (к обсуждению, что я скажу сейчас - мало относится, но все же) для операций над приватными свойствами надо делать в каждом классе свои геттеры и сеттеры (если нужен доступ к ним с пространства имен вне пределов класса, где они определены), по крайней мере это убережет от головной боли, что где-то что-то вылезло не так.
Мне просто довольно странно было наблюдать такой код, потому как с моей точки зрения (к обсуждению, что я скажу сейчас - мало относится, но все же) для операций над приватными свойствами надо делать в каждом классе свои геттеры и сеттеры (если нужен доступ к ним с пространства имен вне пределов класса, где они определены), по крайней мере это убережет от головной боли, что где-то что-то вылезло не так.
MiksIr
miksir@home:~$
А это почти что нарушение принципов инкапсуляции
Т.е. для создания расширения объекта нужно знать не только его интерфейс, но и наборы приватных(!) свойств/методов, что бы случайно их не переопределить. Странно выглядит -~{}~ 30.07.10 19:03:
Чо? Вы хотите заставить всех работать с приватными свойствами обязательно через публичные гетеры? С дуба рухнули? А если я не хочу, более того, это четко задано - что приватное свойство должно быть приватным! И чо? Это раз. Два - а гетеры и сетеры публичные если будут переопределены (они же публичные) - как будете работать с приватным свойством? Т.е. легким движением руки вы даете все возможности сломать _внутреннюю_ работу класса переопределением публичных методов? Именно сломать, ибо приватное свойство подразумевает, что оно скрыто в исходном объекте и _никто_ не может извне на него повлиять. И пишется класс исходя из этого, а тут бац - налепили публичных геттеров
MiksIr
miksir@home:~$
Вурдалак - вы контекст прочитали? В частности, на что этот ответ был дан?
Если есть приватное свойство и в дочернем классе есть приватное свойство с тем же именем - то выдавать конфликт имен неверно, ибо для избегания таких ошибок придется знать имена всех приватных свойств родительского класса, что весьма и весьма глупо.
Если есть приватное свойство и в дочернем классе есть приватное свойство с тем же именем - то выдавать конфликт имен неверно, ибо для избегания таких ошибок придется знать имена всех приватных свойств родительского класса, что весьма и весьма глупо.
MiksIr
miksir@home:~$
Ну ясно дело, что для работы с приватным свойством извне нужны не приватные гетеры и сетеры Но топик то о другом - об области видимости. Просто приведенный в самом начале пример ничем не отличается от аналогичного, где у дочернего класса вообще нету этого приватного свойства. В этом случае логика работы понятна? Думаю всем.
Но топик то о другом - об области видимости. Просто приведенный в самом начале пример ничем не отличается от аналогичного, где у дочернего класса вообще нету этого приватного свойства. В этом случае логика работы понятна? Думаю всем.
По-моему я примеры привел того, как надо было писать и почему все вызывалось в контексте родительского класса. И в оффтоп тему увел как раз в виду области видимости. Я имел в виду внешний доступ к приватным свойствам через паблик методы. Ну не суть
