Design review of a small configuration framework [closed]

Question

I want to create a simple configuration framework. Yes I know, there are many frameworks, which make their job very well. But for interesting in architecture, I want to create my own.

My framework should notice the principles of SOLID You should be able, to store you configuration in several formats. As a proof on concept, I've drawed a simple uml.

Everything starts with a simple factory. This factory returns an abstract class called: "Configurator". Within the "Configurator"-class there's a method factory, which returns an interface, called: "IConfigurationSource". The configuration source is just a interface for storing my settings into a file or any different data storage.

Just a example of a xml implementation:

For a new format, I've to create a new class which inherits "Configurator". You've to override the factory method and return a concrete type of a "IConfigurationSource". In this class, the "IConfigurationSource" will be initialized. I've also to implement a class which inherits "IConfigurationSource" again. This class will provide my data handling into a concrete data storage, in our example a xml file.

At least, a short description of my variables (examples):

• component: For each configuration component, I'll provide a separate xml file. That means: "logging, network, users, etc..."
• valueName: This is the name of a configuration item. For example: "maxUsersAtTheSameTime"
• value: This is the value itself

This is my idea, to create a simple configuration framework. Later I'll implement something like object mapping etc...

Does this design fully support SOLID principles?

Answer 1

Well, everything you described is too abstract to really reason about, but I will try.

I believe you have the following problem. Your Configurator class looks like a in-memory configuration storage, which application will read / write to. But why to tie this to some concrete classes by creating two parallel class instances?

When you talk about configuration, you have two clear responsibilities:

1. Key-value (may be, tree-like) in-memory configuration storage for application to read / write to.
2. Various configuration readers and writers to save / load configuration from various file formats.

In your case you tie both class hierarchies (Configurator and ConfigurationSource) to file format and I believe this to be excessive. In-memory configuration storage should be format-agnostic.

Such design also makes your factory file-format focused because it should create configuration sources only given, say, resource url to load configuration from (well, let's abstract something a little). No specific Configurator needed here.

Answer 2

This is a good exercise and I like the thought-process you are on.

Here's my review of that design.

Single Responsibility Principle

It's clear that each class is responsible for a single thing.

Open-Closed Principle

I don't think this is satisfied as the factory would change when a new format is introduced. The factory doesn't need to be coupled to the set of available formats in my mind. Service discovery or dependency injection could bridge that gap.

Liskov Substitution Principle

Spot on. You have single implementation classes (please mark them final) that directly implement interfaces. The lack of a deep hierarchy makes LSP easy to achieve.

Dependency Inversion Principle

It falls down here as the ConfigurationFactory knows about both Configurator, the interface, and XmlConfigurator, the implementation. The distinction between Configuration and IConfigurationSource appears to be a meaningless partition without further context. The diagram shows no others usages of Configurator for example so there's no obvious benefit to the interface if the factory has to know the concrete implementations anyway.

This could be addressed by having the factory load the implementations via service discovery of dependency injection. In the dependency injection case the factory would be obtained from an injector and the various concrete class bindings would be in a module.

Conclusion

Overall I think you're pretty close on SOLID with this design.