Alternative design approaches

In the NCAA basketball tournament that just ended, we had 65 teams with a chance to win the championship. It also poses an interesting design problem in figuring out how to pair teams. If you were just figuring out how many games it would take to anoint a champion, you could work your way back from the championship game (2 teams in, 1 out) to the final four (4 teams in, 2 out) to the elite 8 (8 in, 4 out) and eventually out to the round of 64 plus the playoff game to get the 64th slot. Then, you could add up all the games in each round to determine how many games and pairings were needed. It's "1 + 2 + 4 + 8 + 16 + 32 + 1".

Or, you could simply realize that 64 of the 65 teams lose once, and the losers go home. It requires one game to lose, therefore 64 games are played.

It's an interesting example of an alternative way of decomposing problems. The different approach shows an easier way to solve the same problem.

Often, a design technique is presented as "the way" to design software systems. Whether it's TDD, UML-based OOAD, or some other approach, I've rarely if ever seen an author recommend changing approaches in different situations. I'd think it's a better approach to change perspectives in design as a way to find better solutions—sometimes TDD works well, sometimes OOAD gives good results. Maybe it's even worth trying approaches randomly or trying to use at least two different approaches to solve the same problem.

Once such approach is called "anti-objects". Here, a Colorado researcher compares anti-objects to OOAD, which the author says has pitfalls: <www.cs.colorado.edu/~ralex/papers/PDF/OOPSLA06antiobjects.pdf>.

Enjoy the article…