Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM design

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: Edwin Goei <edwingo AT sun.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM design
  • Date: Mon, 2 Dec 2002 08:23:11 -0500

At 9:38 AM -0800 11/28/02, Edwin Goei wrote:

2) XOM does not allow method call chaining

3) JDOM: Setter methods don't return void


Setter methods should return void. Partially, this is based on my experience with JavaBeans, where returning void is necessary for a method to be recognized as a property setter. However, more importantly, it's semantically the right thing to do. By invoking a setter method (or any adder or mutator method) you are changing an existing object. You are not creating a new object. You are not getting a reference to some value that you did not have before. Nothing has been created that did not exist before. There is no justification for returning anything.

This naturally prevents method chaining, but perhaps this is a good thing. I find long strings of method chains to be ugly and unreadable. For example, consider this JDOM code:

(new Element("word")).appendChild("d").appendChild("o").appendChild("g");

Does this create <word>dog</word> or <word>god</word>? How sure are you of your answer? What if the middle method call throws an exception? What state is the object left in? Again, how sure are you of your answer?

Dividing this statement up into multiple relatively atomic operations makes the code cleaner, easier to read, easier to understand. Yes, there are classes in the Java class library that don't operate this way, most notably StringBuffer. Perhaps this makes sense for StringBuffer, where it's basically the equivalent of the + operator. Honestly though, this is really just a sop thrown to performance to avoid allocating lots of extra strings. Logically, the plus operator should do what it does for numbers: return a new object that is neither of its operands.

There is simply no logical justification for a setter or mutator method returning the object itself. It is a crutch designed to support a particular programming idiom, but that idiom is neither necessary nor helpful. Method call chaining is not an improvement.
--

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo AT metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
| XML in a Nutshell, 2nd Edition (O'Reilly, 2002) |
| http://www.cafeconleche.org/books/xian2/ |
| http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/ |
+----------------------------------+---------------------------------+
| Read Cafe au Lait for Java News: http://www.cafeaulait.org/ |
| Read Cafe con Leche for XML News: http://www.cafeconleche.org/ |
+----------------------------------+---------------------------------+




Archive powered by MHonArc 2.6.24.

Top of Page