Design for three classes with partially shared logic

Question

I am looking for a suitable design which uses composition to allow three classes to share some logic.

The problem I am solving is that I have to read 3 different json configuration files from my application, and each file needs to have a different class that allows to filter specific data accordingly, however I need to share the logic of reading the files from the filesystem and validating the schema and format. I am looking to avoid inheritance and use composition instead, and I am trying to avoid repeating code as much as possible.

The three classes I currently have are:

CompanyConfig
  getCompanies()
  getCompany()

RoleConfig
  getRoles()
  getRole()
  getRolesBy()

ThemeConfig
  getThemes()
  isThemeEnabled()

On each of these classes constructors I am using a class LoadFileContents and ValidateFileContents, however the logic to invoke these two classes repeats on each of the config classes.

Any ideas?

Answer 1

There is no design pattern for this. There are as many ways to do this as there are developers on this planet, so go for the most obvious design first.

In this case, you have 3 classes that read data from a file, validate the file format, and return strongly typed objects. Inheritance is an option here. The guideline is "favor composition over inheritance" not "don't use inheritance." The litmus test for whether or not inheritance is an appropriate solution is the "is a" test:

ChildClass is a ParentClass

If you insert your own class names into the sentence above, and the sentence is still logically true, then inheritance might be a valid solution. Having an abstract Config class with one derived type for roles, companies and themes passes this test:

CompanyConfig is a Config

RoleConfig is a Config

ThemeConfig is a Config

All three sentences make logical sense. Put the common logic in an abstract parent class.

Answer 2

I agree with @Greg above.

As an additional point, consider moving the common functionality of I/O and validation out to separate classes.

Further, utilize abstract base classes for them and then compose them into the config classes (if a reader and validator makes sense to be a component of a config in your model).

This will help you attain several aspects of SOLID design, the key aspects being Single Responsibility and Dependency Inversion.

The advantages of such a split are:

• SRP and changes across the classes will not pollute one another (your colleagues will thank you during reviews).

• Config classes will focus on hierarchy and logic for transforming configs (business and product can keep making changes to this class, allow you to focus on more testing for this)

• If composing the I/O and validation classes into the config classes, you can sub it out for more specific implementations of them (utilize O and L of SOLID - Open and closed principle and Liskov Subsitution Principle) (This will allow existing classes using old readers to avoid any changes)

Hope that helps.