This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
An addition to API Design table of contents?
Posted by Antti Myllykoski on January 05, 2002 at 3:45 PM
the API design is a very interesting topic in SW engineering since it affects both on the high-level system design as well as on the low-level subsystem design decisions. I look forward to see how the book comes along. I browsed the current table of contents and came up with the following suggestion.
I've been working in project that develops a distributed network management system based on Java 2 Enterprise Edition (J2EE) platform. One interesting finding I've made is how the "EJB -paradigm", or the fact that we are working on the distributed client-server interaction, enforces developers think of the remote objects (mainly session EJBs) in terms of services they provide [ref. Guideline 2].
By structuring the EJB internally into Remote Interface, Remote Home Interface and the very Bean class(es), that implement the functionality, we follow implicitly the guideline to keep interface and it's implementation separate.
As the J2EE guidelines recommend, entity beans that represent typically a bundle of (persistent) data shouldn't be exposed to the remote client directly; they should merely be hidden behind Front Controller or Session Facade objects, for example. This is also a good example of the guideline to think in terms of services, not the data. The "Core J2EE Patterns, Best Practices and Design Strategies" is a great book about this subject.
I was wondering if these J2EE or distributed object design principles could introduce some useful aspects to the API Design discussion.
Just a thought...