1.

Why Is The Jdom Api Defined In Terms Of Concrete Classes Rather Than Interfaces?

Answer»

This issue has been discussed several times on the JDOM mailing list, with several people on both sides. In general, many people feel that a class-based API is better when sub classing is not needed, while an interface-based API is better when sub classing is needed. However, either system can be used in either case.

Jason Hunter summarizes the arguments against an interface-based API for JDOM:

  • With interfaces everything becomes a factory, elements have to be 'imported' into new documents instead of just added, features like long-term SERIALIZATION cannot be guaranteed, and the list goes on.
  • We started with interfaces actually. During our pre-release review to some peers we received the FEEDBACK we should try concrete classes. We did, and the design was much better for it.

THINK about java.io.File as an analogy.

There's a REASON we say:

File parent = new File (file path);

File child = new File (parent, "aaa.txt");

Rather than

FileSystem fs = FileSystem.getDefaultFileSystem ();

File parent = fs.getFile (file path);

File child = fs.getFile (parent, "aaa.txt");

The former is simply easier and nicer to deal with.

Another point to keep in mind is that anything that can be done with interfaces can be done with sub classing - the only penalty is possibly unused variables in the base class.

For reference, the latest mailing list discussion on this topic started Nov. 30, 2000 with "Interfaces", and continued with "Interface-based JDOM" and "ANNOUNCE: JDOMPlus". It would help to review this discussion before bringing this topic up on the mailing list.

This issue has been discussed several times on the JDOM mailing list, with several people on both sides. In general, many people feel that a class-based API is better when sub classing is not needed, while an interface-based API is better when sub classing is needed. However, either system can be used in either case.

Jason Hunter summarizes the arguments against an interface-based API for JDOM:

Think about java.io.File as an analogy.

There's a reason we say:

File parent = new File (file path);

File child = new File (parent, "aaa.txt");

Rather than

FileSystem fs = FileSystem.getDefaultFileSystem ();

File parent = fs.getFile (file path);

File child = fs.getFile (parent, "aaa.txt");

The former is simply easier and nicer to deal with.

Another point to keep in mind is that anything that can be done with interfaces can be done with sub classing - the only penalty is possibly unused variables in the base class.

For reference, the latest mailing list discussion on this topic started Nov. 30, 2000 with "Interfaces", and continued with "Interface-based JDOM" and "Announce: JDOMPlus". It would help to review this discussion before bringing this topic up on the mailing list.



Discussion

No Comment Found