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]

Reply via email to