Как в случае наследования узнать имя дочернего класса?

Статус
В этой теме нельзя размещать новые ответы.

Sanchez

Новичок
Как в случае наследования узнать имя дочернего класса?

Задача следующая: у меня есть родительский класс и несколько его наследников. Я работаю с объектами классов-наследников, и в зависимости от конкретного класса мне иногда нужно применять различные алгоритмы работы с объектами (т.е. внешние по отношению к классу). Как узнать имя класса, с объектом которого я работаю? Пробовал в родительском классе использовать __CLASS__, но он всегда возвращает имя родительского класса. Можно конечно сделать такую фишку в каждом из дочерних, но сдается мне что это не самый гуд вариант. Есть ли более красивые способы?
 

jonjonson

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

kode

never knows best
http://phpclub.ru/talk/showthread.php?s=&threadid=104728

В 5.3.0 и далее должена появится фун-ия - get_called_class(); Либо юзай из CVS либо жди релиза. Хотя jonjonson прав. Как вариант - перегрузить метод в потомке и передать имя класса через параметр родителю, те

public function abc(){
parent::abc(__CLASS__);
}
 

kode

never knows best
Стоп.....чёто меня сглючило со статикой, если работаешь с обьектами то решением будет: get_class($this)
 

Sanchez

Новичок
Да, get_class оказалось тем что нужно, спасибо :) Просто не знал о такой функции.
 

zerkms

TDD infected
Команда форума
Krishna
вообще-то не совсем для этого ;) я бы даже сказал - рефлексия совсем не для этого, хотя бы из описания:
PHP 5 comes with a complete reflection API that adds the ability to reverse-engineer classes, interfaces, functions and methods as well as extensions. Additionally, the reflection API also offers ways of retrieving doc comments for functions, classes and methods.
 

FractalizeR

Новичок
Re: Как в случае наследования узнать имя дочернего класса?

Автор оригинала: Sanchez
Задача следующая: у меня есть родительский класс и несколько его наследников. Я работаю с объектами классов-наследников, и в зависимости от конкретного класса мне иногда нужно применять различные алгоритмы работы с объектами (т.е. внешние по отношению к классу).
Я так понимаю, что алгоритм выбирается последовательностью операторов if? Это неправильно с точки зрения ООП. Вы нарушаете Принцип Открытости-закрытости (http://en.wikipedia.org/wiki/Open/closed_principle, http://en.wikipedia.org/wiki/Liskov_substitution_principle).

(см. Роберт Мартин, Быстрая разработка приложений)
 

Sanchez

Новичок
Знаю что неправильно. По идее, надо сделать отдельный метод в наследниках, который бы включал в себя алгоритм, который я реализую щас вовне, но его придется протаскивать везде - это займет много времени, а работать будет так же. Дальнейшая расширябельность в этом месте мне не понадобится, так что в данном случае "теоретическая красивость" была приведена в жертву.
 

dark-demon

d(^-^)b
> Дальнейшая расширябельность в этом месте мне не понадобится

ой, не зарекайся :)
 

kode

never knows best
Автор оригинала: Sanchez
Знаю что неправильно. По идее, надо сделать отдельный метод в наследниках, который бы включал в себя алгоритм, который я реализую щас вовне, но его придется протаскивать везде - это займет много времени, а работать будет так же. Дальнейшая расширябельность в этом месте мне не понадобится, так что в данном случае "теоретическая красивость" была приведена в жертву.
Дык если говорить о красоте архитектуры то как я уже говорил что тебе мешает перегрузить метод в каждом потомке где просто вызывать родителя с передачей ему имени своего класса? Ты хоть расскажи что ты там в этом методе делаешь, мб есть другие решения
 

Krishna

Продался Java
zerkms
Пардон, нельзя ли разжевать? Я не вижу никаких противоречий, между тем, что я написал и тем что написано на английском.
 

kode

never knows best
Автор оригинала: zerkms
Krishna
вообще-то не совсем для этого ;) я бы даже сказал - рефлексия совсем не для этого, хотя бы из описания:
Вот вы критикуете: а мне захотелось вашу mzz посмотреть: увидел нужно PDO, ради "посмотреть" php пересобирать нестану :) Но вот модуль накатать "нативный" не влом, а вот нужного интерфейса к драйверу ненашёл :) Недело. Я так понял что у вас именно на PDO заточено? HEREDOC комментарии тоже мало информативны, причём видно что код поправили а комменты не обновили. Хотя мб потому-что найтлибилтс качал? :) Но конечное мнение от кода малоприятное, нерасширяемо, нужно больше абстракции.

-~{}~ 06.01.08 13:20:

Собственно кончилось тем что я посмотрел использование DB::factory в коде - ужаснулся и удалил, смысл было делать фабрику для БД, писать страшное слово driver :) если код жёстко заточен под PDO - использовали бы прямо в коде - результат бы тот-же был.
 

zerkms

TDD infected
Команда форума
Собственно кончилось тем что я посмотрел использование DB::factory в коде - ужаснулся и удалил, смысл было делать фабрику для БД, писать страшное слово driver
1. почему драйвер не может быть 1?
2.
если код жёстко заточен под PDO - использовали бы прямо в коде
ты вообще понимаешь что такое фабрика и зачем она нужна?

3.
Но вот модуль накатать "нативный" не влом, а вот нужного интерфейса к драйверу ненашёл
ничего не мешает написать, согласно интерфейсу PDO, свой адаптер под свой DBAL

4.
HEREDOC комментарии тоже мало информативны, причём видно что код поправили а комменты не обновили.
HEREDOC очень даже удобные, в качестве подсказок при автокомплите. некоторые нестыковки есть - невнимательность

Но конечное мнение от кода малоприятное, нерасширяемо, нужно больше абстракции.
ггг ;) код уже много раз показывал себя как весьма даже расширяемым и гибким ;) а то что тебе код не понравился - ну, всем не угодишь ;)

Вот вы критикуете
критика это не всегда "негативный" отзыв. ты, вероятно, только в этом ключе этот термин и знаешь ;)

Krishna
в принципе угу, пардон.
однако:

PHP:
class b {}
class a extends b
{
    
}

$ref = new reflectionObject(new a());
echo $ref->getName();
// vs
echo get_class(new a());
вариант 2 всё таки как-то приятнее ;)
 

kernel32

Новичок
Описание кучи удобных функций для работы с классами и объектами есть в мануале :)
http://ru.php.net/manual/ru/ref.classobj.php
 

kode

never knows best
Автор оригинала: zerkms
1. почему драйвер не может быть 1?
2. ты вообще понимаешь что такое фабрика и зачем она нужна?
3. ничего не мешает написать, согласно интерфейсу PDO, свой адаптер под свой DBAL
4. HEREDOC очень даже удобные, в качестве подсказок при автокомплите. некоторые нестыковки есть - невнимательность

ггг ;) код уже много раз показывал себя как весьма даже расширяемым и гибким а то что тебе код не понравился - ну, всем не угодишь

критика это не всегда "негативный" отзыв. ты, вероятно, только в этом ключе этот термин и знаешь
1. Потому-что это неинтересно :)
2. Угу, тут я натупил, хотя с той-же лёгкостью можно было использовать ServiceLocator или Синглтон
3. Мешает. Например в нативном mysql нету широко используемых prepared запросов.
4. Я не про HEREDOC, я про то что комментарии устарели. Ну это так просто напоминание.

Ну незнаю, абстракции я там не увидел совсем. Разве дело когда метод возвращяет PDOStatement?

Неа, как раз критика это хорошо. Просто высказал своё скромное фи :)

kernel32
Ты ещё classkit предложи заюзать :))) Шутко
 

zerkms

TDD infected
Команда форума
1. Потому-что это неинтересно
аргумент от специалиста. +1 ;)
3. Мешает. Например в нативном mysql нету широко используемых prepared запросов.
повторяю фразу: что мешает написать свой адаптер?

4. Я не про HEREDOC, я про то что комментарии устарели. Ну это так просто напоминание.
спасибо ;) это просто невнимательность. но не будь так категоричен - прецедентов, я так думаю, не очень и много ;)
 

kode

never knows best
Как ты напишешь адаптер для библиотечной функции которой нету, но которая используется в коде? Самому чтоли реализовывать?
Повторяюсь: Вот например в рамках стандартной библиотеки mysql в PHP - нету prepared запросов, но они (prepared запросы) используются в коде фреймворка.
 

zerkms

TDD infected
Команда форума
Самому чтоли реализовывать?
да. это так сложно?
ps: так или иначе - я не вижу ни одной причины менять PDO на нативные функции.
разве что имея цель покричать "у вас код не гибок - потому что хороший DBAL нельзя заменить на нативные функции"
ещё вспомни что мы пхп4 не поддерживаем, и на mysql 3.x оно тоже не заведётся
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху