Are there any rules how the number of indirection layers should be limited?

Question

Just like the two opposing mirrors are enough for infinity, most of design patterns can be applied repeatedly producing any amount of LOC desired. We can always create a factory for any factory or wrap a delegating layer around any class that already delegates.

This is of course somewhat artificial example, but I hope it explains why I think that some developers time to time write too much of code, applying the indirection multiple times. Are there any standard approaches to limit the proliferation of the indirection layers?

Answer 1

You're confused about the purpose of design patterns.

It's not that using a design pattern is good because more patterns = better code in any way. Patterns are recurring workable solutions to recurring complex constraints on our solutions. If we use a pattern, it's because it fits our present constraints, not because many other people also do it. The point of naming and sharing them is to alert other users to a possible solution we found, and to simplify communication about recurring complex class structures.

Therefore, if your program exhibits constraints that make using a factory of factories the best solution, then do it. If it doesn't, don't. Once you've done it it makes sense to call your classes the obvious names so that future readers of your code can follow your reasoning faster. But it's the reasoning that must decide whether to use a pattern and how often, not the lure of the pattern.

Answer 2

Code reviews.

If someone can't justify creating another indirection layer to his/her peers, it doesn't need to exist. If they can and the benefit is worth the work, it's probably ok.

Some projects will require a lot of indirection, others not so much. Only a human will have a chance at determining if it is justified or not.

Code reviews are a way to sanity check each other. Use them.