Should a config class be a friend of the process it configures?

[GregFreeman]

I have a config file that configures a specific process in my application. As far as I see it, I have two options to help with encapsulation. One is to just let the process that uses it, handle it. That process' class would have read config, save config, etc methods which would not be public.

 

Or, I could wrap up the functionality in its own class, making methods protected, and making it a friend of the process that uses it. 

 

Any pros/cons if each method? Or, am I splitting hairs?

Edited June 10, 2013 by for(imstuck)

[Aristos Queue]

Just let the process that uses it use it would be my normal go to in this case. The only reason I would consider a different route is if I had reason to obscure where the settings were coming from -- i.e., sometimes they come from a config file, sometimes they come from an object simulating a text file. Testing is sometimes easier if you can feed in objects that represent specific configurations, rather than having the config files for various tests.

[GregFreeman]

Just let the process that uses it use it would be my normal go to in this case. The only reason I would consider a different route is if I had reason to obscure where the settings were coming from -- i.e., sometimes they come from a config file, sometimes they come from an object simulating a text file. Testing is sometimes easier if you can feed in objects that represent specific configurations, rather than having the config files for various tests.

 

That makes sense, thanks.