Simple library
From APIDesign
| Line 1: | Line 1: | ||
Some libraries, let's name them [[simple library|simple libraries]], have just one implementation. The designer that defines what the [[API]] should do also implements it. Obviously, the [[proximity]] between the [[API]] and the [[ProviderAPI|provider of the implementation]] is almost zero - it is the same person or the same team. | Some libraries, let's name them [[simple library|simple libraries]], have just one implementation. The designer that defines what the [[API]] should do also implements it. Obviously, the [[proximity]] between the [[API]] and the [[ProviderAPI|provider of the implementation]] is almost zero - it is the same person or the same team. | ||
| - | Simple [[library|libraries]] are usually self contained. They | + | Simple [[library|libraries]] are usually self contained. They combine the [[API]] specification together with the implementation. There is no reason, no way to plug into the library and change the way it behaves (for other [[ClientAPI|clients of its API]]). Examples of such [[simple library]] include most of '''java.util''' package (with classes like {{JDK|java/util|ArrayList}} or {{JDK|java/util|Collections}})), or other utility classes like {{JDK|java/lang|Math}} class. |
Of course, there may be some attempts to re-implement these libraries (like GNU Classpath or Harmony), but those are often licensing driven efforts, not purely technical ones. Especially when they are available as open source. If there is some flaw in the library, then it is better to contribute patches back (see [[Teamwork]] chapter of the [[TheAPIBook]]) then fork and maintain such fork. In general, there is little to no reason to re-implement such libraries. | Of course, there may be some attempts to re-implement these libraries (like GNU Classpath or Harmony), but those are often licensing driven efforts, not purely technical ones. Especially when they are available as open source. If there is some flaw in the library, then it is better to contribute patches back (see [[Teamwork]] chapter of the [[TheAPIBook]]) then fork and maintain such fork. In general, there is little to no reason to re-implement such libraries. | ||
Revision as of 18:36, 8 May 2012
Some libraries, let's name them simple libraries, have just one implementation. The designer that defines what the API should do also implements it. Obviously, the proximity between the API and the provider of the implementation is almost zero - it is the same person or the same team.
Simple libraries are usually self contained. They combine the API specification together with the implementation. There is no reason, no way to plug into the library and change the way it behaves (for other clients of its API). Examples of such simple library include most of java.util package (with classes like ArrayList or Collections)), or other utility classes like Math class.
Of course, there may be some attempts to re-implement these libraries (like GNU Classpath or Harmony), but those are often licensing driven efforts, not purely technical ones. Especially when they are available as open source. If there is some flaw in the library, then it is better to contribute patches back (see Teamwork chapter of the TheAPIBook) then fork and maintain such fork. In general, there is little to no reason to re-implement such libraries.
Follow
