3

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?

amon
136k27 gold badges295 silver badges386 bronze badges
asked Feb 22, 2017 at 14:17

1 Answer 1

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.

answered Feb 22, 2017 at 14:25

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.