2

I have a large class consisting of properties that are kind of (import) options. They are stored in one bundle class, so that it's easy to serialize them (or set eg. from environmental variables during the unit tests). It's something like :

class MyImportantAppSettings {
  string Dbo;
  string User;
  int BatchSize;
  int RecordLimit;
  int AllowAsync;
  int VeryImportantOtherOption;
  ...
  int The25thVeryImportantOption;
}

The instance of this class is being used across the application, this causes my code tightly dependant from it. Despite the settings are hidden behind an interface and injected to objects through IOC, I feel a bad smell here.

What would be best/cleanest way to implement settings in the code and spread them to classes?

7

If many places in your code really do need all those 25 important options, there is nothing to be done. You either perform a major refactoring so that concerns in your system are separated better, or you accept that this is the best solution.

However, if most of these places need only a few of these options, then the thing to do is to expose the options bundle under different interfaces, each of which is much smaller than your current mega-interface. That way, when details of some options change, only the places that actually use these options need to care and not all places.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.