Refactoring – Why Using Other Object’s Data in Switch Statement is Bad

Though I think I've heard composition-vs-inheritance discussions long before GoF, I can't put my finger on a specific source. Might have been Booch anyway.

<rant>

Ah but like many mantras, this one has degenerated along typical lines:

1. it is introduced with a detailed explanation and argument by a well-respected source who coins the catch-phrase as a reminder of the original complex discussion
2. it is shared with a knowing part-of-the-club wink by a few in-the-know for a while, generally when commenting on n00b mistakes
3. soon it is repeated mindlessly by thousands upon thousands who never read the explanation, but love using it as an excuse not to think, and as a cheap and easy way to feel superior to others
4. eventually, no amount of reasonable debunking can stem the "meme" tide - and the paradigm degenerates into religion and dogma.

The meme, originally intended to lead n00bs to enlightenment, is now used as a club to bludgeon them unconscious.

Composition and inheritance are very different things, and should not be confused with each other. While it is true that composition can be used to simulate inheritance with a lot of extra work, this does not make inheritance a second-class citizen, nor does it make composition the favorite son. The fact that many n00bs try to use inheritance as a shortcut does not invalidate the mechanism, and almost all n00bs learn from the mistake and thereby improve.

Please THINK about your designs, and stop spouting slogans.

</rant>

The case for any change of practice is made by identifying the pain points created by the existing design. Specifically, you need to identify what is harder than it should be because of the existing design, what is fragile, what is breaking now, what behaviors can't be implemented in a simple manner as a direct (or even somewhat indirect) result of the current implementation, or, in some cases, how performance suffers, how much time it takes to bring a new team member up to speed, etc.

Second, working code trumps any arguments about theory or good design. This is true even for bad code, unfortunately. So you're going to have to provide a better alternative, which means you, as the advocate for better patterns and practices, will need to refactor to tease out a better design. Find a narrow, tracer-bullet style plane through the existing design, and implement a solution that, perhaps, for iteration one, keeps the god object implementation working, but defers actual implementation to the new design. Then write some code that takes advantage of this new design, and show off what you win because of this change, whether it's performance, maintainability, features, correction of bugs or race conditions, or reduction of cognitive load for the developer.

It's often a challenge to find a small enough surface area to attack in poorly architected systems, it may take longer than you'd like to deliver some initial value, and the initial payoff may not be that impressive to everybody, but you can also work on finding some advocates of your new approach if you pair on it with team members that are at least slightly sympathetic.

Lamenting the God Object only works when you're preaching to the choir. It's a tool for naming a problem, and only works for solving it when you've got a receptive audience that's senior and motivated enough to do something about it. Fixing the God object wins the argument.

Since your immediate concern appears to be executive buy-in, I think you're best off making a case that replacing this code needs to be a strategic goal and tie those to the business objectives that you're responsible for. I think you can make a case that you can provide some technical direction by first working on a technical spike on what you think should be done to replace it, preferably involving resources from one or two technical people that have reservations about the current design.

I think you've found enough resources to justify your argument; people in such meetings will only pay attention to summary of your research, and they'll stop listening after you mention two or three corroborating sources. Your focus initially should be in getting buy-off to work the problem you see, not necessarily proving someone else wrong or yourself right. This is a social problem, not a logical one.

In a technology leadership role, you need to tie any of your initiatives to business goals, so the most important thing for making your case to executives is what the work will do for those objectives. Because you're also considered the "new guy," you can't just expect people to throw away their work or expect to rapidly fall in line; you need to build some trust by proving that you can deliver. As a long term concern, in a leadership role, you also need to learn to become focused on results, but not necessarily be attached to the specifics of the outcome. You're now there to provide strategic direction, remove tactical obstacles from progress by your team, and offer your team mentorship, not win battles of credibility with your own team members.

Making a top-down decision will rarely be credible unless you have some skin in the game; if you are in a similar situation all over again, you should focus more on consensus building within your organization rather than escalating once you feel the situation is out of control.

But considering where you are now, I'd say your best bet is to argue that your approach will bring measurable long-term benefits based on your experience and that it's in line with the work by well-known practitioners like uncle Bob and co., and that you'd like to spend a few days/weeks leading by example on a narrow refactoring of the highest bang-for-buck aspect, to demonstrate what your view of good design should look like. You'll need to align whatever your case is to specific business goals beyond your personal preferences, however.