tags:

views:

163

answers:

2

This is for my DB class. I am new to OO, been a procedural lad for some time, so I'm still a bit murky.

My first idea was using a bunch of setter functions/methods.. but after writing a whole bunch, I thought about using PHP's define function, like so.

define('MYSQL_USERNAME', 'jimbo');

Is this an accepted practice? What is the best practice? Should I really clutter my class with a bunch of setter functions (I am currently the only developer using these classes). What are your solutions?

Thank you!

+2  A: 

there are probably a few options to deal with this:

  1. just use setters, it's perfectly acceptable, but can get a bit "wordy" with a lot of config options.

  2. use a config object to pass in:

    $config = (object) array(
       'prop1' => 'somevalue',
       'prop2' => 'somevalue2',
       'prop3' => 'somevalue3',
    );
    
    
    $db = new DB($config);
    
  3. if you want to use constants, you could restrict them to the class to avoid global namespace pollution:

    class DB {
        const USER = 'mysqluser';
    }
    
    
    echo DB::USER; // for example
    
Owen
oops thanks for the syntax correction
Owen
God, PHP makes my teeth itch. Having to do that to create an anonymous object "concisely" is ridiculous.
eyelidlessness
Thanks for your response, I will definitely keep this in mind with future development :)
alex
+1  A: 

I use const only for creating mnemonic names for immutable constants in the class. The define() function does not create constants as part of the class, it creates constants in the global space.

class MyClass
{
  const CONFIG_FILE = 'myapp.ini';

Class configuration data I usually declare as a protected hash-array in the class. Keys are useful for mnemonics. Values are defaults.

  protected $config = array(
    'logfile' => 'err.out',
    'debug' => false
  );

Then I load an "ini" format file with parse_ini_file() and use array_merge() to map the keys into your class config array:

  public function __construct() {
    $ini_data = parse_ini_file(self::CONFIG_FILE, __CLASS__);
    $this->config = array_merge($this->config, $ini_data);
  }

}
Bill Karwin
What's the overhead like on parsing an ini file? Do you think it would become an issue? I'd imagine a keyed array within PHP would be much quicker?
alex
How do you go about securing this INI file? Place it above the root web accessible directory?
alex
Parsing a PHP file versus reading an ini file are not significantly different.
Bill Karwin
Yes, secure an ini file as you would secure any of your other class-declaring code by placing it outside the docroot. Only the actual PHP template files need to be accessible.
Bill Karwin
this sounds like the best solution (cos I know the ini will make more sense to a designer then a keyed array) so I'm going to place it above my docroot and name it something.ini.php Thank you!
alex
Yes, that's another advantage of ini files -- they're easy to edit.
Bill Karwin
The way this site is already set up (3 mini sites off a TLD) means that the ini might get lost in the folders above the root.. any other way of obscuring them? Blocking with .htaccess?
alex
Well, I'd keep all my PHP classes outside the docroot (e.g. /var/www/library as a sister of /var/www/htdocs) and add that location to PHP's include path. Unfortunately, parse_ini_file() doesn't heed the PHP include path, so you need to use an absolute path.
Bill Karwin
I found that if I begin the ini file with <? and end with ?> PHP will still parse it but won't output the contents if called directly. Seems like a solution to me!
alex
That's a bad solution, since the PHP module could fail leading to your file being read as text. Best to follow Bill's suggestion and keep out of the docroot
Eran Galperin
But if the PHP module does fail, then won't all of my code be readable?
alex
Yes, that's the reason you shouldn't keep your code under the docroot.
Bill Karwin