d11wtq wrote:Hockey wrote:I'm a hardcore OOP zealot...but I disagree with using classes for everything and anything...
I don't know...perhaps your onto something here with using a singleton...
I'm not sure actually why I disagree with using classes in this instance...
I guess it's because for me...the number one rule of OOP is reusability...if you can't reuse it...don't OOP it. Config settings are not very portable....their kind of application specific...
So the whole 'drop right in' appeal of OOP is kinda stomped on...
I'd personally use a module with GLOBALS and the constant modifier (if you can in PHP) but maybe thats just my old stubborn arse talking...?
Interestingly enough you certainly got me thinking...not sure if I"ll ever change my mind on the subject, but i'll think about it

I respectfully disagree that this is not reusable. Providing you keep your config directives somewhere separate it works the same everywhere. In fact, scrap the "configDirectives" class and have a file called config.xml. Then all you need to do is have the singleton load that file and parse, just the first time you call getInstance() and voila, a whole set of config directives. I picked XML as an example becuase it parses extremely easily and it's flexible. Start chucking globals into your OOP app and how far do you go before you realise your app is getting rather large and you've got more globals than you can handle flying around? -- Start out with the best design you can, you're less likely to kick yourself in the teeth (just how many times did you start writing a "little" app and suddenly you ended up with a large project on the go?) Just my $0.02.
Edit: After some more thought, I'm not sure I agree 100% with myself even...it's a tough call...I still say classes aren't the right solution for config data, but they do a slightly better job ensuring that data isn't misused or abused than straight GLOBALS do (although if the const modifier was available that problem would be solved).
/Edit:
I can't disagree...neither is really re-usable though. Seeing how config settings are app sepcific. Perhaps my problem comes in with accessing a classes properties directly, but I still disagree with using classes in this instance. If your using accessors/mutators IMHO your already gone way to far in abusing what classes are intended for.
As for experiencing problems with GLOBALS I can honestly say I have never encountered a problem with using GLOBALS. In PHP I use a pretty lengthly naming strategy which dissuades re-assignment at runtime.
A class (in my opinion) should be re-usable and offer the opportunity for derivation, inheritance, etc...encapsulation is important I agree and the additional namespace protection is nice too, but still.
Consider a simple wrapper class, which does little but offer an OOP API around a library of functions.
As an example lets say: CString which encompasses all of the string manipulation functions PHP has to offer (or any language)
Although it likely doesn't derive from any object, nor will it likely be used as a base class, it still supports the following:
1) Reusablility
2) Encapsulation
Now i'm not even sure where I'm going with this...maybe i'm arguing for the sake of arguing
My 2 biggest problems with using classes in this situation are:
1) Reusability - This is number ONE (for me personally) when designing a class.
2) There is a difference between being an OOP zealot and and OOP fanatic. You "could" use classes for everything, but often you end up going beyond the original intended use. For example, you could use PHP classes like:
Code: Select all
class myView{
function showHeader($title)
{
echo '<head><title>'.$title.'</title><script src="test.js"></script></head>';
}
}
This is valid syntactically, but OOP friendly? No! it breaks the number one golden rule of re-usability.
Templates are a much better solution.
You could implement an entire class which parses source code, but it makes for alot cleaner code using EBNF and a parsing framework.
My point being, sure classes are awesome, but their intended for a very specific purpose and solving a certain set of problems. Config data isn't one of them IMHO.
Using interspersed techniques (instead of JUST classes) also helps in managing large code bases. Instead of storing image data in classes, obviously you store it in their native format on the HDD or maybe in a database, the point is, when you need that image, you know exactly where to get it and your not stuck sifting through 100's of classes trying to find that image config class.
I've listed all my concerns with using classes as a config solution and thats that

I promise I will not critique or question any methods any more - at least with this topic (i'll try not to anyways)
