The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Is this object inheritance good?

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

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.).

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.

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.

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.

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:

PHP Code:

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.

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?

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.

Originally Posted by feketegy

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.