[BoxFour]

The issue at hand is not about cleverness.

Code was devised to address a specific problem (DRY), which it did quite elegantly. Then, the situation evolved, rendering the solution inappropriate. When a controller starts to deviate from the standard approach, it's best to refrain from inheriting from the base controller and instead create custom ones. Once all controllers operate independently, the base class can be safely removed.

The key lesson here is not to avoid cleverness but to be aware of when the initial problem becomes obsolete.

[sjducb]

Experience will tell you that this happens often, and it’s often better not to DRY in the first place.

[BoxFour]

If there is no process for re-evaluating code architecture choices, it can create challenges regardless of the approach taken.

Experience tells me that relying on copy+paste as a solution isn't a cure-all, or even a better approach, and often introduces new problems in the future. A thoughtful and adaptive approach to code development is crucial to ensure long-term success and maintainability.

[orblivion]

What about making all of the "clever" things composable and optional, instead of tightly coupled? That way when you get a special case you can just make that part a special handler. You neither need to throw out the whole "clever" thing nor make the "clever" thing "more clever".

[BoxFour]

Choosing to inherit from a base class always seems like an optional and intentional choice, no?