OO versus XML + agile programming languages?

by Uche Ogbuji

Related link: http://www.xmldatabases.org/WK/blog/1094?t=item



Kimbro Staken skewers a terribly contrived example of OO-to-the-max. It's great fun at first glance, but in the end I find the treatment somewhat troubling.




I've myself undergone a conversion from mainstream OO orthodoxy to what I consider post-OO programming sensibility, and I have posted my own criticisms of the OO mainstream (recent example: "Objects. Encapsulation. XML?"). But there is good OO and bad OO, and I think that even OO advocates would scoff at the article Kimbro quotes as an unworthy straw man. I certainly hope I never perpetrated anything so ugly in all my years in the OO mainstream.




I think the stronger argument is that even when I think my designs were well considered, I could have done things better with dynamic, declarative and data-driven (D4) methodologies, mixing in OO in small doses only where it is clearly the best model. Aside: In my struggles to find good terminology for my recent thinking, "D4" == "Agile programming" == "Post-OO", where agile programming is not the same thing as agile process, such as Extreme Programming (which can be used with non-agile programming languages such as Java).




Anyway, Kimbro does point out the sore fact that OO often impairs maintenance and code reuse, two of its advertised benefits. Then he goes on to present an alternative solution in Python and XML to the example from the original article. XML really drives this example, and the fact that Python is the host language for the use of XPath appears purely incidental. It leads to my second worry about the blog item: that it seems to advocate reflex use of XML.




I'm a huge XML advocate, and I think it is the main catalyst, if not the quintessence, of the growing mainstream acceptance that it is okay to deviate from pure OO. But XML is certainly no panacea, and if you find yourself thinking that XML is overkill for a certain task, it probably is. Unfortunately, Kimbro does precisely say that XML is overkill in his code but proceeds to use it anyway.




As it happens, using only Kimbro's code as evidence, I agree that XML is overkill. A Python dictionary would be a much better data represenation, and if persistence is needed, pickling would do the trick. Kimbro advocates XPath for its simplicity and I would agree if XML were a gven. But one must consider that XPath is much more complex than Python dictionary lookup.




Additional context might justify the use of XML, for example, perhaps the XML example is a standard interchange format. Of course, I would have little patience for such an XML interchange format. It brings me far too much to mind of Apple's XML property lists, which rank among the ugliest uses of XML I've found.




In this case the key to fixing the mess presented by OO extremity is not data-driven extremity, but rather the dynamicism of languages such as Python. When I first got into REXX, my fist agile programming language, there was no XML, but it was very clear to me how REXX's expressiveness was superior to the rigid object hierarchies I'd become used to creating.




This does not mean that "Dynamic" is the most important part of D4. If you go from toy examples to real-world problem solving, declarative and data-driven programming soon show their importance. If XML itself is not part of the solution, much of the mind-set that XML represents (setting aside reflex-OO tools such as SAX, DOM and parts of W3C XML Schema) helps bring sanity back to programming.




I don't want to leave off without saying that OO is not always evil. It can be a useful way to package modest but strongly-cohesive bits of code (basically Abstract Data Types without declarative axioms). It can also make sense in systems-wide design if it naturally reflects the real world problem space the system simulates. I do think that such cases are rare, though (the original article was an example of how rigid OO can force you to invent all sorts of daft contrivances that have nothing to do with the actual problem space). The world is much too rich to be shoved into PIE.




What are your experiences with extremity in either OO, agile languages or XML?