Beautiful Code [122]
These concerns would become much more prominent if you were to cache element names rather than just namespace URIs. In this case, there are many more names to cache and the names are shorter. It might make more sense to use a table in this case than a simple array. Perhaps verification is just faster; I have not yet performed the detailed measurements necessary to determine the best design, although I plan to for XOM 1.3.
Correct, Beautiful, Fast (in That Order): Lessons from Designing XML Verifiers > The Moral of the Story
5.9. The Moral of the Story
If there's a moral to this story, it is this: do not let performance considerations stop you from doing what is right. You can always make the code faster with a little cleverness. You can rarely recover so easily from a bad design.
Programs usually become faster over time, not slower. Faster CPUs are a part of that process, but not the most important. Improved algorithms are a much bigger contributor. Therefore, design the program you want in the way it should be designed. Then, and only then, should you worry about performance. More often than not, you'll discover the program is fast enough on your first pass, and you won't even need to play tricks like those outlined here. However, when you do, it's much easier to make beautiful-but-slow code fast than it is to make fast-but-ugly code beautiful.
Framework for Integrated Test: Beauty Through Fragility > An Acceptance Testing Framework in Three Classes
6. Framework for Integrated Test: Beauty Through Fragility
Michael Feathers
I have some ideas about what good design is. Every programmer does. We all develop these ideas through practice, and we draw on them as we work. If we're tempted to use a public variable in a class, we remember that public variables are usually a symptom of bad design, and if we see implementation inheritance, we remember that we should prefer delegation to inheritance.[*]
[*]Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1995.
Rules like these are useful. They help us move our way through the design space as we work, but we do ourselves a disservice if we forget that they are just rules of thumb. If we forget, we can end up with design where we are "doing everything" right, but we still miss the mark.
These thoughts were driven home to me back in 2002 when Ward Cunningham released Framework for Integrated Test (FIT), his automated testing framework. FIT consists of a small set of elegant Java classes. They maneuver in a path around nearly every rule of thumb about design in the Java community, and each little turn that they make is compelling. They stand in stark contrast to design that just follows the rules.
To me, FIT is beautiful code. It's an invitation to think about the contextual nature of design.
In this chapter, I'll walk through one of the earliest released versions of FIT. I'll show how FIT deviates from much of the current accepted wisdom of Java and OO framework development, and describe how FIT challenged me to reconsider some of my deeply held preconceptions about design. I don't know whether you'll reconsider yours after reading this chapter, but I invite you to look just the same. With luck, I'll be able to express what makes FIT's design special.
6.1. An Acceptance Testing Framework in Three Classes
FIT is relatively simple to explain. It's a little framework that lets you write executable application tests in HTML tables. Each type of table is processed by a programmer-defined class called a fixture. When the framework processes a page of HTML, it creates a fixture object for each table in the page. The fixture uses the table as input to validation code of your