开发者

Autoloading vs Factory and Autoloading Dangers

开发者 https://www.devze.com 2023-02-14 14:48 出处:网络
This is a two-part question, though both parts are closely related. I had create a page decorator API for our website and put the autoloader for the decorator classes in our site-wide include file.An

This is a two-part question, though both parts are closely related.

I had create a page decorator API for our website and put the autoloader for the decorator classes in our site-wide include file. Another developer thought this was a very bad idea because having an autoloader used everywhere is very dangerous and can cause odd errors. For example, serializing an object to the session and if one of your autoloaded classes has the same name and a __wakeup(), it will be run (though I tried this and was not able to reproduce it). Is it true that autoloading is dangerous, and if so, what potential dangers does it have and how can they be avoided? I am not using __autoload(), but an autoload function with spl_autoload_register().

Another argument he had against using autoload is that it would be slower than including the file directly, which is probably quite obvious. I argued that for the decorator to be guaranteed to work on each page you would ha开发者_开发百科ve to include every decorator class, so his suggestion was to create a factory class that would get the include and create the class you wanted for you. I could go on-and-on, but I have heard many people tout the merits of autoloading and say that it makes any application faster. I do like it a lot but I still want to do what is best and fastest. Any suggestions?


For example, serializing an object to the session and if one of your autoloaded classes has the same name and a __wakeup(), it will be run (though I tried this and was not able to reproduce it).

That's true, in a way. If you have two classes in two files with the exact same name, your autoloader won't be able to guess which one you want, so you just might end up with the wrong class. The easiest fix for this would be to use namespaces, that's what they are made for.

Another argument he had against using autoload is that it would be slower than including the file directly, which is probably quite obvious.

This is true, again, in a way. Autoloading is slower than a direct include, but do mind that it's much easier to use, and that you never include files that you don't need to include. That last part might just make it a tie, or perhaps even faster.

I argued that for the decorator to be guaranteed to work on each page you would have to include every decorator class, so his suggestion was to create a factory class that would get the include and create the class you wanted for you.

That's a whole lot of work for something PHP can do natively. Mind you: if you're using a self-written Factory in PHP to determine which class to load, you are actually building an autoloader, but just not calling it that ;)

Any suggestions?

I personally wouldn't want to include my files manually. It's been long since I've started using the spl_autoload_register functionality, and I don't regret it for a bit.


I think by not using an autoloader you are making things more difficult and taking away from readability.

Whilst I haven't really gotten into PHP namespaces, have a look at most of the major frameworks and PEAR libraries use autoloading.

Naming a class based on its location, and using that to load the file makes it so simple.

i.e. You have a class called My_Special_Model. A call is made to the autoloader and it includes the file model.php in my/special directory.

As far as performance goes for using an autoloader, don't worry about that until you are having performance issues. You will far more likely be able to optimize a single query than have to remove autoloading.

0

精彩评论

暂无评论...
验证码 换一张
取 消