Page 1 of 1
Classes: Use seperate files or keep them combined?
Posted: Thu Feb 19, 2004 3:56 pm
by voodoo9055
Do you keep your classes in individual files for example: database.class.php, login.class.php, etc or do you create a master class file and have all of your classes located in that file?
Would there be a significant slowdown if you used multiple includes for individual class files?
Posted: Thu Feb 19, 2004 4:05 pm
by uberpolak
For the sake of keeping everything organised, I like separate files. No speed problems yet, although I'd imagine you'd have some if you used a single file and it got to be too big (of course by speed I'm referring to download time for the user, not script execution).
Posted: Thu Feb 19, 2004 5:14 pm
by cybaf
yeah... if the file is too big then the script maximum execution time might be exeeded... but I guess if you have loads of small files then it would be the same amount of data so the script would still time out... hmm
I always keep classes in separate files anyways...
//cybaf
Posted: Thu Feb 19, 2004 6:49 pm
by McGruff
Also, classes ought to be in separate files so that they can be combined in different ways. You wouldn't want to include an entire library just to get at a single class.
Not sure if it's possible to write a php script so large that trying to open it would exceed a normal setting for php max execution time. I suspect the programmer would exceed his own max execution time first.
Posted: Thu Feb 19, 2004 7:43 pm
by Tanus
I normally have a class in its own file, with the name of the file the same as the name of the class. Lets you do nice things like dynamic include and instantiation at runtime, ie
Code: Select all
require_once($clsName.".php");
$obj = &new $clsName();
$obj->GenericFunction();
Posted: Fri Feb 20, 2004 7:22 am
by voodoo9055
Tanus
I didn't even think about that. Great ideal. Thanks for that. You gave me some ideals now.
Posted: Fri Feb 20, 2004 9:06 am
by Tanus
To improve on the code, you could do something like
Code: Select all
@include_once($className);
if( !class_exists($className)
error_stuff("Couldn't get the class");
else
$theClass = &new $className($vars, $you, $need);
Posted: Sat Feb 21, 2004 12:51 am
by eletrium
Gotta go with separate files as a rule of thumb. Lots of times when developing stuff, I keep classes in the same file just to save time. If I end up keeping the class, then I save it to its own file then.
In another non-PHP program I wrote, I have a parent class in the same file as it's descendent classes if the descendent classes have like only one or two functions. Like it's easier to look at 5 very small classes in the same file. They all descend from the same parent and only override a single function or two in each case. So I keep them together so I can make sure if there is an issue with one class, I can check out the siblings easily. In this case though, I don't even have to scroll. All classes are on the same page. It's that small.
But overall 99% of my classes are in their own files. When I need to find classNameB, it's just easier to open cclassNameB.whatever then to have to recall which file it was in.
Sound like it won't happen to you? Just spend years developing a base of code and by then, belive me, <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> gets jumbled fast. Write code with the assumtion that you are 100% guaranteed that a year and a half from now, you will have to go in there and fix something that is broke or needs to be upgraded. For me that includes keeping classes in their own files.
Posted: Sat Feb 21, 2004 10:22 am
by ilovetoast
While I agree that most classes should be in separate files, their are two exceptions that are worth noting - one kind of major and one kind of minor.
#1 - Core/foundation classes for a given feature set can be lumped into one file.
An example of the is the PEAR base class. The PEAR.php file includes 2 classes - PEAR and PEARError. You're never using one without the other, so put them in one file. Other examples are the various database abstraction classes out there. They typically have a class that contains a factory method or similar, an Error class, a Results class, and maybe a separate Query class. All of these classes can get lumped into one file - you need them all every time. The classes for each database are then stored in separate files - one for MySQL, one for PGSQL, et. al..
#2 - If optimization is mission critical, abstraction classes can be condensed completely.
In other words, if speed is critical to your app, you can combine files just prior to deployment. For example, if you're deploying to a MySQL/PHP setup it would be reasonable to move the MySQL class into the same file as the rest of the database abstraction classes. No reason to have an extra include everytime you create a db connection. This does require a conditional block around the require_once statement, but that's not a big thing compared to the statement itself. Other examples include filesystem abstractions, authentication schemes, and many others. Do remember however that most sites/apps (90%+) do not need this level of optimization as they don't have the load to even begin to require it.
toast should be free
Posted: Sat Mar 06, 2004 11:36 am
by lastcraft
Hi...
I think you may have made a poor choice of example:
ilovetoast wrote:The PEAR.php file includes 2 classes - PEAR and PEARError. You're never using one without the other, so put them in one file.
This is one of the fundamental problems with PEAR. Libraries shouldn't inflict their error handling system on you, it is up to the application to handle this or perhaps a framework. PEAR is plain rude over this for dictating the architecture.
As for keeping classes in their own file:
I have used both files as packages of classes and used one class per file (except for groups of trivial subclasses). Both work well. You can always refactor these (despite resistence from CVS).
yours, Marcus