Re: Accessing class instances
Posted: Thu Jun 12, 2008 5:39 am
How come?superdezign wrote:Using include() for the necessary classes is considered better practice than the autoload capability created by PHP.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
How come?superdezign wrote:Using include() for the necessary classes is considered better practice than the autoload capability created by PHP.
We're ballancing here between the purity of abstract design and the practical process of developing code in one particular language. Noone would incidentally call a database function, so that we need to think about OOP protection. Especially considering that PHP won't warn us at compile time. But if I want to call a database function, I want to be able to do it easily, short and to the point. For the folks that want strict encapsulation and mocked up unit testing (can't imagine why in this case), I still support the $this->pDatabase->Query() style.superdezign wrote:But in the concepts that OOP was built on, objects are created and the only objects with access to them are the ones that need access. It's the whole issue of "uses" and "has." If an object only outputs HTML, and it doesn't use the database to do that, then the object should not have access. Also, the objects that do have access won't be easily identified from the objects that don't, as any object can simply add that call.
In order to clearly see which classes are using which classes. Especially useful when changing code and you accidentally leave in a class that is no longer necessary (as PHP will notify you that the class cannot be found), and when looking directly in an included class as opposed to creating documentation for it.astions wrote:How come?superdezign wrote:Using include() for the necessary classes is considered better practice than the autoload capability created by PHP.
But in doing so, wouldn't you be giving more database responsibilities to classes that potentially should have very little? For example, result-handling and error-handling.Mordred wrote:But if I want to call a database function, I want to be able to do it easily, short and to the point.
No. If I wanted to call the database, I would have called it. We're not talking about responsibilities here. What we discuss here is how do we access the database object when we know we want to. Or the response object. Or the error logging object.superdezign wrote:But in doing so, wouldn't you be giving more database responsibilities to classes that potentially should have very little? For example, result-handling and error-handling.Mordred wrote:But if I want to call a database function, I want to be able to do it easily, short and to the point.
Why is that good? What if every single class could use any other class? That's how my framework works.superdezign wrote:In order to clearly see which classes are using which classes.
Well technically, every class could always use any other class. The usage isn't a matter of design or overhead, but a matter of the fact that we make mistakes sometimes. Being able to account for everything that is being used without searching for every constructor and static method call in the class can simplify our debugging.astions wrote:Why is that good? What if every single class could use any other class? That's how my framework works.