Beautiful Code [12]
Speed was the driving factor in each successive refinement, but in this case the improvements in speed were accompanied by improvements in beauty as well. I hope to dispel the myth that fast code must be illegible, ugly code. On the contrary, I believe that more often than not, improvements in beauty lead to improvements in execution speed, especially taking into account the impact of modern optimizing compilers, just-in-time compilers, RISC (reduced instruction set computer) architectures, and multi-core CPUs.
5.1. The Role of XML Validation
XML achieves interoperability by rigorously enforcing certain rules about what may and may not appear in an XML document. With a few very small exceptions, a conforming processor can process any well-formed XML document and can identify (and not attempt to process) malformed documents. This ensures a high degree of interoperability between platforms, parsers, and programming languages. You don't have to worry that your parser won't read my document because yours was written in C and runs on Unix, while mine was written in Java and runs on Windows.
Fully maintaining XML correctness normally involves two redundant checks on the data:
Validation occurs on input. As a parser reads an XML document, it checks the document for well-formedness and, optionally, validity. Well-formedness checks purely syntactic constraints, such as whether every start tag has a matching end tag. This is required of all XML parsers. Validity means that only elements and attributes specifically listed in a Document Type Definition (DTD) appear, and only in the proper positions.
Verification happens on output. When generating an XML document through an XML API such as DOM, JDOM, or XOM, the parser checks all strings passing through the API to make sure they're legal in XML.
While input validation is more thoroughly defined by the XML specification, output verification can be equally important. In particular, it is critical for debugging and making sure that the code is correct.
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