Simple library
From APIDesign
| (6 intermediate revisions not shown.) | |||
| 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 | + | Of course, there may be some attempts to re-implement these [[simple library|simple libraries]] (like [[GNU Classpath]] or [[Harmony]] show), but those are usually licensing driven efforts, not purely technical ones. |
| + | |||
| + | Especially when the [[simple library]] is available as [[open source]]. It is much easier to contribute back than to fork. If there is some flaw in the library, it seems easier to create an [[API Patch]] and donate it back to the [[simple library]] owners. In general, there is little to no reason to re-implement [[simple library]] [[API]]s. | ||
Current revision
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 simple libraries (like GNU Classpath or Harmony show), but those are usually licensing driven efforts, not purely technical ones.
Especially when the simple library is available as open source. It is much easier to contribute back than to fork. If there is some flaw in the library, it seems easier to create an API Patch and donate it back to the simple library owners. In general, there is little to no reason to re-implement simple library APIs.
Follow
