Large Configuration for class, implementation suggestions

So I have a large class that I'm refactoring to be more flexible.

well over 100 configurable properties (variables) in a INI file. Some are dev settings and others are production settings.

Currently I use a environment flag to pull the INI settings I need (either dev or prod).

All the INI fields are mandatory and must be set. (currently using setters for this).

So what makes more sense?

• A: to keep the current setup
• B: Move to another type of configuration setup (like xml or something)
• C: Move all settings into the script itself and remove the INI parsing and validation code (setters)
• D: suggestions?

Bonu开发者_JS百科s question:

I was reading this over the weekend: http://berryllium.nl/2011/02/getters-and-setters-evil-or-necessary-evil/ and wanted to know how I could follow more of this type of development style but confused as how to not use getter/setter functionality with setting mandatory fields? I understand the need to getters/setters and wanted to know if I'm implementing them correctly?

I use the INI for stuff like DB settings, validation limits (think spending limit of $100 but could change), large array (static values like the 50 US States but with the ability to add US territories as well)

• If you want to keep settings readable, keep the current setup or move settings into PHP script (but do not hardcode them into classes).
• If you want to increase performance - use JSON format or PHP script - json_decode works faster, PHP script works faster and can be easily cached by APC.
• As variant, you can parse the settings file once and put all settings in cache (APC or memcache).

Also. I think nobody cares, but I have my opinion about getters and setters :)
Getters and Setters aren't evil. Idea of Encapsulation is not just hide fields, but hide, how class works. Getters and setters can be declared in interface, so you can replace one object by another - and it is what for encapsulation was invented!

Let's take example from article of Berry Langerak - withdraw and deposit it's setters. All this code can be successfully done in setBalance method, almost nothing will be changed. All these checks, comparison - it's usual work of setters.

Why public fields are evil? Because object can't control their changing and because they can't be declared in interfaces. Getters and setters can do it, so it's perfect tool of OOP.

Accessors can be written silly, of course, but it doesn't mean that they are evil. Any method in the class can be written silly.

Interesting question.

I highly doubt that all of those variables are/could be different between your development area and your production area. Not every variable that you might change when debugged would have to be stored inside a config file.

I would advice using constants for the most variables. You have auto complete, tons of IDE options and it's easily editable. Not to mention it's more logic to split them up into different files then to parse tons of ini's.