2009/10/12 Stephan Ebelt <ste@xxxxxxxxxxxxxxx>:
> as far as I understood/use it: I try to hardcode as many workable defaults in
> the vo class as possible (ie. see $subject in the example). Then I create objects
> by passing result records from the database (arrays) to the constructor. That
> either returns a object or crashes the application if something is wrong.
> Optionally I can create objects without any passed-in parameter which will give
> one with only the defaults set. Depending on the class' definition those may
Ok, I'm going to make a case against the use of default values
hard-coded within the class here:
a) Default values mean more code.
The less code you have, the less bugs. Just strip the defaults out,
and they'll never cause errors.
b) Default values hide missing values.
If a value gets mislaid during the build process, the class will still
work, kinda, sortof, but it won't behave as expected. Better to exit
loudly and let the build manager fix the missing value, rather than
try to muddle through on partial data, and fail /really/ impressively
further down the road.
c) You should store all your config options in the same place.
This is simply good practice - it makes life easier for anyone coming
after you who knows that /everything/ is in one place. Zend_Config is
a nice approach - the Config object parses an ini file, and you pass
fragments of the config object to your class constructors. Eg:
$conf = new Zend_Config_Ini( 'config/settings.ini', 'live' );
$db = Zend_Db::factory( $conf->application->databasesettings );
d) Default values lead to assumptions.
MyClass assumes that DbClass connects to localhost if nothing is
passed. This means that MyClass is relying on a feature of DbClass
where it doesn't strictly have to, and DbClass is a little bit less of
a black box.
e) Defaults aren't.
What makes sense on one machine (eg a default of 'localhost' for the
db) may not make sense on another. Rather than tweak the class
defaults to fit the local conditions every time you deploy it, and
have dozens of slightly different versions hanging around, just be
explicit and push the parameters in from outside.
Comments welcome of course, but I've strayed off PHP and into OO design, here.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
