Finding a class name after extending

Question

I'm having troubles finding a class name after extending other classes. Here are the relevant classes:

class Home extends Controller {
       public function test() {
           Example::all();
       }
}


Class Example extends Active {
    //Variables
}

Class Active extends Database {
     public function all() {
        //This is where I need to store a variable containing the class name Example.
     }
}

I'm trying to retrieve the name of the Class Example in Class Active from when it is called from class Home, however I've found it impossible to do this so far without adding an extra argument (which I don't want to do).

The way you do it, just go procedural, why do you bother with classes? — Itay Moav -Malimovka, Jul 23 '11 at 16:46
@Matt I guess what Itay wants to say is that the OP is doing class based programming and in that case OP can just as well do procedural because class based programming isnt object oriented at all. — Gordon, Jul 23 '11 at 16:59
@Gordon It looks at though OP is attempting to create a larger object oriented application. In which case why would he want to go procedural? — 93196.93, Jul 23 '11 at 17:41
@Matt using classes doesnt make an application object oriented. If you need statics and LSB you are using class based programming and thats much closer to procedural than oo. See the last link in my answer. — Gordon, Jul 23 '11 at 18:03

score 2 · Accepted Answer · answered Jul 23 '11 at 16:49

2

You are looking for

get_called_class — the "Late Static Binding" class name

Example (demo)

class Home  {
       public function test() {
           Example::all();
       }
}
Class Example extends Active {
    //Variables
}
Class Active  {
     public static function all() {
        var_dump( get_called_class() );
     }
}

Note that I have changed the signature of Active::all to static because calling non-static methods statically will raise E_STRICT warnings. In general, you want to avoid static methods and Late Static Binding.

answered Jul 23 '11 at 16:49

Gordon

296,205
68
508
534

about "avoid static..." after so and so years it dawned on me that I rather have to write much less, so for PHP for example I would rather have most classes have a static API, but still be able to use them directly If I need something more comples, a simple example: `$id = DlClass::getInstance($tname)->id` as opposed to: `$DL = new DlClass($tname); $id=$DL->id;` – Itay Moav -Malimovka Jul 23 '11 at 19:31
@Itay well, I think the linked article explains pretty well why you win nothing with statics. – Gordon Jul 23 '11 at 20:46
this article is just an opinion and he brought (in my private opinion) bad examples, i.e. good examples why static is bad. Every coin has two sides (otherwise the `goto` would have disappeared from the face of the earth). Assume every class you have also has the following static property+ static method. Would it save you some typing in the future? `public $LastInstance=null; static public function getInstance($params){ //some logic whether to instantiate a new object or return the last instance; return static::$LastInstance; } public function __construct(....){...} ` – Itay Moav -Malimovka Jul 23 '11 at 22:53
@Itay No, it wouldn't. What you show would be a Singleton (if it had a private ctor). [Singletons are Anti Patterns](http://stackoverflow.com/questions/4595964/who-needs-singletons/4596323#4596323). They mix creation graph with collaborator graph and thus violate SRP. They are harder to test due to the tight coupling and introduce global state and side effects into applications. They also violate DIP. Singletons hurt your architecture. The above holds true even with the public ctor. It's bad design. – Gordon Jul 24 '11 at 09:48
The above class has nothing to do with Singletons (I knew you would write that :-) ) 1. I can have as many as I want. 2. I can use normally 3. All I have is a short cut that ,manages for me some common usages of this code, that's it And that is my only point. I use some static methods for shortcuts of the most common task an object will be used to, right? would not make sense to see the following code 1000 times in your code: `$T=new F(p); $T->u()->r()-k();$T->g++; echo $->newG();` If I can do a shortcut like `$T::showNewT(p);`KISS is by FAAAAAR the most important DIP. – Itay Moav -Malimovka Jul 24 '11 at 12:24
@Itay like I said, all of what I said about Singletons applies to your example as well. What you show isn't KISS. It is bad design. If you want to create an object graph, use Builder or a Factory pattern. Please read the SOLID principles and compare with your example. On a sidenote, I am quite suprised that you gave the comment to the OP to go procedural but then fail to acknowledge the harmfulness of static methods. – Gordon Jul 24 '11 at 12:27
Bad design explode in your face after several months, been using this for two years in a llarge and intensive development project with a team of six, it holds nicely. 2. How is it different than factory? 3. My comment to the OP was somewhat sarcastic. I do not believe in using static method for the actual logic, as I wrote, just for shortcuts (Isn't factory a type of shortcut?) 4. Articles and opinions are just that, you might get to know they do not have to read as the word of god all the time. – Itay Moav -Malimovka Jul 24 '11 at 12:36
It's not opinion. It's fact. Like I said, read the SOLID principles please. Statics introduce tight coupling and global state. They make your application less maintainable and testable. If your design hasnt exploded yet, then its because you likely dont change much in it and you dont do unit-testing. If you would do unit testing you'd know that statics are death to testability and come to haunt you each time you want to mock a dependency. As for how factory or builder is different, see above again: it doesnt mix creation graph and collaborator graph (mixing is a violation of SRP). – Gordon Jul 24 '11 at 12:43
I guess something is wrong in my unit testing. I think You assume I take this approach towards all my classes, when in reality it is only to a select few which are being used extensively in the system. For those I have "hardcoded" tests to their API. It is my approach to programming, and life, that every "fact" can have some excluded cases. – Itay Moav -Malimovka Jul 24 '11 at 14:24
@Itay can we please stop to talk at cross purposes? Your codebase proves nothing. Yes, you can get away with a few statics but that doesnt mean that those few statics do not suffer from all of these things I stated above. Just because you worked around these issues, doesnt mean they dont exist. My point is: if you use statics you will suffer the consequences for violating SOLID *sooner or later*. The issues might not be immediately visible or impacting, but they are there. They are even measurable in software metrics. And they will creep into your design decisions. – Gordon Jul 24 '11 at 19:43
Thank you for this discussion, I am not convinced, but I will re-review my design decisions 9again and again, (as this is my job). I would have told you to follow me in my blog to see the consequences... I don't have one... – Itay Moav -Malimovka Jul 24 '11 at 23:30

score 0 · Answer 2 · answered Jul 23 '11 at 16:44

0

have you tried with ReflectionObject class from PHP ? Have a look to this method

Hope this helps

answered Jul 23 '11 at 16:44

wezzy

5,678
3
29
42

Finding a class name after extending

2 Answers2