Ravi Mohan's Blog
Friday, October 07, 2005
The "code should be readable" principle, like any other, can be taken to extremes. Recently, someone advocated replacing (junit's) assertEqual(5,obj1.getValue()) with Result.Of(obj1.GetValue()).ShouldEqual(5); Yet another suggestion I heard was to replace assertTrue(x > y) with Should.be(true).that(x).greaterThan(y) !!! A class called "Should" with a method called "be"? The best reaction I heard was from a friend who said, "I can write a program to substitute spaces with "." and put a "()" at the end of requirements written in English. That would be better than this lunacy. Thus I.need(true).someMoney() :-p" Remember the language where you could just "express business requirements in English" without "developer speak" coming in the way? Yes, COBOL. This ridiculous notion that code should look like English comes from a misunderstanding of the "Objects model the domain" principle.It also makes sense to those who have only (an imperfectly understood) Object Oriented Paradigm in their bag of tools and frequently those who can only "speak" Java (although I have seen this happen to some self proclaimed "smalltalk experts"). I once worked on a project where the "Chief Designer" was Object crazy and we ended up creating Objects that replicated all the components of a relational Database imperfectly. Thus we had classes like "Table" and"Query" right in the code, with all sorts of fancy tree creation (and tonnes of Visitor classes)to create simple "Select *" queries as objects. We even had a ridiculous "FieldedBusinessObject" class that was essentially a glorified Hashtable, with well over 300 fields and methods with the interrelationships laboriously hand coded. All in the name of "OOD" (and in a "100% pure XP" project too !!!). I pity the client who paid good money for this hogwash. Genuinely understanding a paradigm means knowing what it is not good for, just as well as how to apply it effectively when it is suited. Using an object structure to create a poor man's version of a very ambigous spoken language like English is a warning that the practitioner probably shouldn't be programming live systems in the first place. Doubly so when this misunderstanding is couched in terms like "Ubiquitous Domain Language", which have very precise meanings and context, totally unrelated to such foolishness. If you must have a totally unrelated language embedded in your code, it is far better to learn how interpreters and compilers work and and how to embed sublanguages in your code (no,XML is NOT a good way to do this!) Yes, that means learning some "esoteric" computer science theory. If you ever find yourself contemplating classes like "Should" with methods like "be" (coming soon to a framework near you! I am NOT joking), find the nearest wall, bang your head thrice on it, very very hard. Do this enough and you'll be ok! Or at the least you will soon not be able to do much harm. Alternatively, the nearest walmart is probably looking for checkout clerks.