Search code examples
javaoopsolid-principles

Redundancy according to SOLID


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?


Solution

  • 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 .