OO, XML and quantum mechanics
We just had an interesting discussion on the internal chat server at Oops. We were talking about when, in XML, a value should be an attribute and when it should be an element. I argued that it depends on the whole set of data that is represented in XML.
In one case, some value might be best represented as an attribute, while in another it’s best to use an element. We have specified some XML documents in our project recently. One of them looks (in part) like this:
<team name="Northern Team" region="Up North"> <br />
<totalAmount>10000.0</totalAmount> <br />
<insuranceCompany name="Oops Life"> <br />
<share ownerName="Jeff Bridges" amount="8000.0" /> <br />
</insuranceCompany> <br />
</team>
Here, we use attributes for the name and region of a team, and elements for the total amount of commissions to be paid to the team, and the insurance companies that commissions come from (which in turn has a name and a “share”). My point is, that had this information been about the team and not about commission shares for the team, the name might have been better to represent as an element:
<team> <br />
<name>Northern Team</name> <br />
<region>Up North</region> <br />
<contact>Leif Pagrotsky</contact> <br />
</team>
This made me think about object-oriented design, and how there are no absolutes: you can’t say that something always belongs in a particular place. In fact, it depends very much on its environment. Just see the “Feature Envy” code smell in the book Refactoring, by Martin Fowler, which suggests that a method should be moved if there’s another class more interested in it than the class where it currently resides.
I like that the best design for an object depends on the objects that use it. It seems very obvious to me now, but I haven’t thought about it this way before. This in turn makes me think of the principle that no thing is separate from everything else (which I wrote about after having read a book by Alan Watts).