Is this a stupid use for static properties?

[NotionCommotion]

I have a bunch of quasi-static values that must be available to the application.  Most of them are set based on settings in a configuration file.  Others are based on GET, COOKIE, or SESSION values, and utilize the database to get the actual values.  The values will never be written to or modified by the application, only read.

 

It seems to me that I could create some sort of superclass which includes static methods and properties, and I could access any value by something like superclass::get('some.value');  I could design the class so that the values are queried from the DB or obtained from a parsed file only the first time they are requested, and for future requests, retrieved from a static property.

 

That being said, I have been told from more than one person that I am just doing it "wrong".

 

Please let me know what is wrong about it.

 

Thank you

[ignace]

We already explained this to you at:

http://forums.phpfreaks.com/topic/293408-how-to-make-configuration-settings-available-to-all-scripts/

 

Using a static class couples your code to a specific implementation and makes it harder to change later on. Also if you ever become a professional programmer your colleagues will frown upon your use of static anything.

 

Both me and Jacques gave you good examples of the best practice.

[NotionCommotion]

Thanks ignace,

 

Yes, I agree I was given examples of best practice.  Regarding "why", I understand a static shouldn't be be because:

1. Colleagues will frown upon your use of static anything.
2. Is a bit weird.
3. Couples your code to a specific implementation and makes it harder to change later on.
4. Harder to troubleshoot.

I could live with #1 and #2.  As for #3 and #4, why is it harder to change later on or troubleshoot?  We have other super variables like $_SERVER which contain specific values based on the given state, and don't have problems.

 

I know many on this site are much more knowledgeable and experienced than me, and I should probably just let this go...

[ignace]

Consider the following code:

 

function foo() {
  $foo = Configuration::get('foo');
  // ..
}

In this example you can't change the class that is being used to read the configuration data unless you manually edit the code that uses it. The bigger your application gets, the more it takes to change it everywhere.

 

function foo(Configuration $bar) {
  $foo = $bar->get('foo');
  // ..
}

In this example it is easy to simply provide a different implementation and pass it as an argument. All it takes is changing the calling code. Because all your code expects it as an argument you can probably set the class at one point (for example index.php) which is then used throughout your entire application thus changing the implementation means changing it at that one point to make your entire application use the new Configuration instance.