Question

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?

Bonus 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)

Answer 1

• 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.