Tim OBrien wrote:
--- Stephen Colebourne <[EMAIL PROTECTED]>
For example:
- HttpComponents
- WebComponents
- LibraryComponents (narrowAPI-deep)
- BaseComponents (broadAPI-shallow)
Explain that narrowAPI-deep, braodAPI-shallow
business.
BroadAPI-Shallow
The principal API of the component is broad. That is, it consists of
lots of methods.
Each of those methods is Shallow. That is, each method does relatively
little processing.
Typically, these will not have config files.
Typically, these wil not have dependencies.
For example, a static Utils class.
For example, commons-lang, commons-io.
NarrowAPI-Deep
The principal API of the component is narrow. That is, there are
relatively few methods in the whole javadoc that most users should call.
Each of those 'external' methods is Deep. That is, each external method
performs a lot of internal work to achieve its goal.
Typically, these will have config files.
Typically, these wil have dependencies.
For example, commons-jxpath, oro.
I sugest these as groupings as I believe there is a difference in skills
in creating these two types of libraries. With NarrowDeep its all about
the making that narrow API as simple to understand, yet powerful, as
possible. With BroadShallow, there is a lot of work defining the method
exactly and in naming. (Plus lots of overap in skills too...)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]