Is this object inheritance good?

[feketegy]

Hello, I was playing with PHP classes and inheritance and I found out this little trick. With this method we can create a big super object(in the code is called base) and a class extending this super object can also access other classes created by this super object.

BUT is this a good practice to follow or not? Maybe if we want to plug a module to our code

class Base {

    function __construct($what)
    {
        //class always instantiated
        $var = 'A';
        $low_var = strtolower($var);
        
        $this->$low_var = new $var;
        //-------------------------
        
        //optional classes instantiated        
        foreach($what as $var)
        {
            $low_var = strtolower($var);
            $this->$low_var = new $var;
        }
    }    
}
class A {
    function __construct(){
        echo ' a | ';
    }
    function test(){
        echo 'test function from class a';
    }
}
class B {
    function __construct(){
        echo ' optional b | ';
    }
}
class theClass extends Base {
    function __construct(){
        $what[0] = 'B';
        
        parent::__construct($what);

        $this->a->test();
    }
}

$tmp = new theClass(); 

[feketegy]

Anybody?

[krt]

BUT is this a good practice to follow or not? Maybe if we want to plug a module to our code

I can't really tell if you are talking about your code snippet specifically or are using that as an example for a general case.

Of course, inheritance has its place and it may look like overkill, like in the example you have made, but it is useful for for modular design and derivations (such as a data source base class with derivations for certain database platforms etc.).

[feketegy]

Ok, then what is the best way to do similar stuff like this?

Picture this for a request (check the attached picture) is this good ?

The main idea is that the front controller figures out which module to instantiate and that module gets the access to all the classes loaded by base class (core classes)
This seems logical to me, but I want to hear your opinion, advice on this.

module_arhitecture.gif

[krt]

Well that is the general idea of MVC, which is a recommended approach to many standard web applications. The front controller analyses the request, the client device, platform and other details and dispatches the request, e.g. toa page controller.

I can't download your attachment at the moment ("attachments pending approval")

[feketegy]

Ok, then maybe try this link i uploaded to imageshack: module arhitecture

[feketegy]

Can anybody help me out with this? I need your opinions...

[kyberfabrikken]

If you instantiate dependencies (objects) inside the constructor, you get a quite rigid design. You should provide a way to pass dependencies in from the outside - At least as an option. Why don't you just pass them in the constructor? If you want to be able to instantiate classes, without knowing about their dependencies, you can use some kind of factory pattern.

[feketegy]

Can you explain this a little bit more, because i don't really understand what you're trying to say...

[kyberfabrikken]

Can you explain this a little bit more, because i don't really understand what you're trying to say...

Presumably, your class TheClass needs an instance of A and B. Thus A and B are dependencies for TheClass. You can manage this dependency in the following way, by passing the dependencies in the constructor:

class TheClass
{
  protected  $a;
  protected  $b;

  function __construct(A $a, B $b) {
    $this->a = $a;
    $this->b = $b;
  }
} 

This way, it's clear which dependencies TheClass has, and you don't have to extend Base. Sometimes it can be a problem, that the code, which instantiates TheClass needs to know which dependencies it has. This is the case, when you're creating the instance from a dynamically resolved name; For example, if you use the URL to map to a classname. To overcome this problem, you can encapsulate the instantiation in an object, which "knows" how to create the class. This is called a factory. A factory is a very general pattern; There are several ways to implement it.

[feketegy]

Yes, thank you for you reply.
I checked on the Factory pattern and also Singleton and Registry patterns as well.
Is it best to implement these class instantiaton/creation patterns as static objects? Does it hearts memory usage or something else?

[kyberfabrikken]

I checked on the Factory pattern and also Singleton and Registry patterns as well.

Yes, Singleton is a specific form of Factory, and Registry is strongly related.

Is it best to implement these class instantiaton/creation patterns as static objects? Does it hearts memory usage or something else?

"Best" depends on the context. I try to avoid static methods at all costs, but it's a strategic choice.
Static methods/properties have global scope, which makes the code less flexible. So in terms of functionality, class instances are superior to static methods. They do add a little bit of complexity, since it can be harder to look at the code, and figure out exactly which type a given object has. Putting it on the edge; If you never use the flexibility, that you add, you have paid the price of complexity, without cashing in on the benefit of flexibility.

You shouldn't worry about memory usage, unless there is some concrete reason to do so. Most likely it's irrelevant.

[feketegy]

Yes. Thank you.
And then what is the best practice to make globally available objects?

[kyberfabrikken]

Pass them in the constructor - Don't access them through global means.