3

I'm just wondering if you have an application where you define a class that defines some user configurable settings (from an xml file, or a GUI), should you design it so that it follows SOLID as much as possible like the rest of the application?

More specifically, how do you change the available settings without violating the Open Closed Principle?

Because I'm having trouble picturing this. I can see the addition of settings you can extend the class, but with the removal of settings, or change of a setting there would be no way to modify the configuration class so that it follows SOLID. Or is it possible somehow?

I can also imagine trickle down effect from those settings changes, that require classes that depend on them to be modified as well.

  • 1
    Can you be more specific about what you mean by following SOLID principles? Why would settings and application classes be treated any differently from other classes? To put it another way, why would you want to serialize any class if doing so violates SOLID? – Robert Harvey Apr 28 '14 at 22:35
  • @RobertHarvey ok mostly referring to Open/Closed principle – erotavlas Apr 28 '14 at 22:43
  • Aren't settings and Configuration classes the very essence of Open/Closed? You can add or remove settings without changing the source code of the class, especially if the configuration is merely a set of Key/Value pairs. – Robert Harvey Apr 28 '14 at 22:45
  • 1
    @RobertHarvey Ok say your working from an XML configuration file. Say the client requirements change later on and you have to add a new attribute, or node representing some new setting. Or say they don't need a setting anymore and you have to delete it (from the xml and GUI) - Aren't all these kept as properties in one or more classes, and if so it would require modifying them. – erotavlas Apr 28 '14 at 22:49
  • That is a conundrum, isn't it? – Robert Harvey Apr 28 '14 at 22:52
4

I think the problem that you are experiencing is not with the Open / Closed principle, but more so with the Interface Segregation Principle.

If you treat configuration as a dependency of the classes that use it, you would want that configuration interface to have method / properties that have high cohesion. Therefore a new configuration variable would have a relatively small impact on the system.

Having such an interface allows you to do do unit-testing for different configurations, and allow you to change how those configuration values are derived without significant changes to your application (store in database instead of xml).

public interface IBlogConfiguration
{
    public int GetNumberOfPostsPerPage();
}

public interface ICommentsConfiguration
{
    public bool AreCommentsAllowed();
    public bool CanCommentsBeNested();
}

public class WebConfigConfiguration : IBlogConfiguration, ICommentsConfiguration
{
    // implementation of both those interfaces
}

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.