Simple library
From APIDesign
(Difference between revisions)
| Line 1: | Line 1: | ||
| - | Some libraries, let's | + | Some libraries, let's name them as [[simple library]], 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. |
Simple [[library]] are usually self contained. They contains the [[API]] as well as the implementation. Examples include most of '''java.util''' package, or {{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 licensing driven efforts, not technical ones. In general, there is little to no reason to re-implement such libraries. | Simple [[library]] are usually self contained. They contains the [[API]] as well as the implementation. Examples include most of '''java.util''' package, or {{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 licensing driven efforts, not technical ones. In general, there is little to no reason to re-implement such libraries. | ||
Revision as of 08:44, 8 May 2012
Some libraries, let's name them as simple library, 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.
Simple library are usually self contained. They contains the API as well as the implementation. Examples include most of java.util package, or Math class. Of course, there may be some attempts to re-implement these libraries (like GNU Classpath or Harmony), but those are licensing driven efforts, not technical ones. In general, there is little to no reason to re-implement such libraries.
Follow
