I've been working lately on a custom framework, so before posting my concern I will explain the way I organized the framework.
There is a main class, from which all other classes are extended. All the other classes are interconnected between them with a a variable which has the name of the class. Easier said, I have the MAIN class. I also have the classes THEME, URI, INIT.
After the framework has initialized, if I get the MAIN instance and assign it to a variable, lets say $main, and I can use the other classes like this:
$main->theme;
$main->uri;
$main->init;
I can even use $main->theme->uri->theme->init if I want :D, but no way $main->theme->theme.
Also, from inside the classes (other than MAIN), I can access the other classes like $this->init, $this->theme, etc.
The properties that point to those classes are references.
Now my concern, when I print_r the $main variable, I get a lot of RECURSION elements. The framework loads fast, and the memory consumption is 28MB, but still I get that recursion. Does it mean that the way I organized my framework is wrong, or it's just the print_r function that sees pointers pointing to same classes, and avoids infinite recursion?
Ok, here's a print_r of the TF_TFUSE class (the main one i was talking about). Here only two other classes have been implemented (too reduce output).
TF_TFUSE Object
(
[framework_version] => 2.1
[load] => TF_LOAD Object
(
[_the_class_name] => LOAD
[framework_version] => 2.1
[buffer] => TF_BUFFER Object
(
[_filters:protected] => Array
(
)
[_buffer:protected] =>
[_the_class_name] => BUFFER
[_is_end:protected] =>
[framework_version] => 2.1
[load] => TF_LOAD Object
*RECURSION*
)
)
[buffer] => TF_BUFFER Object
(
[_filters:protected] => Array
(
)
[_buffer:protected] =>
[_the_class_name] => BUFFER
[_is_end:protected] =>
[framework_version] => 2.1
[load] => TF_LOAD Object
(
[_the_class_name] => LOAD
[framework_version] => 2.1
[buffer] => TF_BUFFER Object
*RECURSION*
)
)
)
The problem is that you are linking everything together inside your objects. This problem is normally solved by creating a container class that holds the other objects and creates interactions between them.
To be able to do $main->theme->uri->theme->uri->theme->uri->theme->uri->theme->uri->theme->uri->theme->uri->theme->uri->theme->uri->theme->uri->theme->init should give you an indication that something is wrong . . .
A possible solution is represented generically below:
class Manager {
$theme;
$uri;
$init;
}
And THEME, URI, and INIT no longer have direct relationships to each other.
I believe your problem is more related to the fact you have instances of each of the other classes inside each other. theme->uri should not be possible if uri->theme is possible. Only one should have an instance of the other, if either are to have instances of other classes at all.
Think of it like this: I have a Player, he is holding a Bat and a Ball. You have a Player, he is holding a Bat and a Ball, the Bat is holding a Player and a Ball, and the Ball is holding a Bat and a Player.
You don't need all those cross-references, you need to establish a sane hierarchy of objects.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With