Redundancy according to SOLID

Question

According to SOLID, are you supposed to eliminate redundancy by functionality or by category?

For example if we had 3 classes that each contained String filepath = "..." as a member variable, would it be better to create a new class, i.e. Settings.java with filepath as a member variable or would it be better to keep filepath 3 times in each of the classes that it belongs to so that each class takes full responsibility of its own attributes?

Answer 1

I would also argue that you are providing too little information to understand what would be best.

I don't recall SOLID principle saying something about redundancy per se, but there is the DRY principle.

What I have found about redundancy is that if you do one thing in more than one place if you need to change something about it you have to remember to update all places where is being done. If you forget one place, you have inconsistencies in your system where it would have at least two ways of doing the (conceptually) same thing.

This usually leads to bugs that are not always easy to find.

Of course, this is easy to solve, just don't have redundancy; before doing something see if the functionality is already in your system and if not look for something related and try to generalize it .

Answer 2

Don't Repeat Yourself is kind of the "flip side" of the Single Responsibility Principle. The SRP states that a class should have only one reason to change. DRY states that there should be a single source of truth for a fact, so that if you change a fact, every thing that depends on that fact will be affected by your one change.

In your case, it depends each of your classes' usage of filepath. If the files must have a common path in order to meet a specific business requirement, they should all refer to a single definition, kept somewhere that encompasses that requirement. Otherwise, they should probably have independent declarations, or you'll find they're not going to be very reusable.

Answer 3

"Would it be better to create a new class, i.e. Settings.java with filepath as a member variable"

No, I don't think that would be better. Without more details it's difficult but I might create an interface, called something like ISettings, and inject that into the necessary classes, using DI.

I think that would be more inline with SOLID.