Objects are for communication. A key to good design is to choose good names. This Longhorn class should be renamed now:
System.Xml.XPathDocument2
to set an example.
What does the name XPathDocument2
tell me, the reader? Well, it basically tells me there is an XPathDocument
(or maybe an XPathDocument1
and perhaps an XPathDocument3
).
It also suggest that the 2
class was developed some time *after* the first one. It might tell me not to use the first one. I don't know. The 2
is noise that wants to be information.
A better name would tell me that XPathDocument2
can be disconnected from the source, not tied to a DOM, and used for read/write, and provides change notifications. The numeral 2
cannot tell me that. Neither does it tell me that the original DOM-bound XPathDocument
still may be a good choice in some scenarios.
I don't know exactly what the better name is, but it is out there in the conversations that led to its creation, and (unfortunately) in the conversations that will take place among its consumers. Maybe ReadWriteXPathDocument
is a good choice, but only real conversations (as opposed to the ones going on in my head right now) will tell.
This post has nothing to do with XML and XPath or Longhorn. It has everything to do with why objects are important and will remain useful for their original purpose: code organization. Good names are a key to good organization.
Well, this post *does* have something to do with Longhorn... the developers at Microsoft are creating now the language many developers will use for probably a decade. Please take the time to provide meaningful names. Two years before the release date is *not* the time to affix numerals to the end of classes for relatives that provide alternate functionality!
No comments:
Post a Comment