OpenClass
From APIDesign
(New page: When dealing with objects that produce and consume generic type of unknown bounds, it is necessary to ''open'' the type before its use. One can either use an OpenMethod or...) |
|||
| Line 5: | Line 5: | ||
The '''getActive''' and ''setActive''' methods could take '''ProjectConfiguration''' class as parameter, but that would not be correct - it would allow a user of the [[API]] to take configuration from one project and try to activate it on different one. By use of ''<Configuration extends ProjectConfiguration>'' bound, this is prevented. Yet, this very complicates life of clients of this API, as following code: | The '''getActive''' and ''setActive''' methods could take '''ProjectConfiguration''' class as parameter, but that would not be correct - it would allow a user of the [[API]] to take configuration from one project and try to activate it on different one. By use of ''<Configuration extends ProjectConfiguration>'' bound, this is prevented. Yet, this very complicates life of clients of this API, as following code: | ||
| - | <source lang="java" snippet="misuse.prjconfig. | + | <source lang="java" snippet="misuse.prjconfig.correct.trivial.access"/> |
no longer compiles. Instead of it one needs to either use the [[OpenMethod]]: | no longer compiles. Instead of it one needs to either use the [[OpenMethod]]: | ||
Revision as of 14:23, 26 December 2008
When dealing with objects that produce and consume generic type of unknown bounds, it is necessary to open the type before its use. One can either use an OpenMethod or, in case the open needs to last longer than just during method execution, an OpenClass.
Imagine a generified API to access project configuration:
does not exists: misuse.prjconfig.correct
The getActive' and setActive methods could take ProjectConfiguration class as parameter, but that would not be correct - it would allow a user of the API to take configuration from one project and try to activate it on different one. By use of <Configuration extends ProjectConfiguration> bound, this is prevented. Yet, this very complicates life of clients of this API, as following code:
does not exists: misuse.prjconfig.correct.trivial.access
no longer compiles. Instead of it one needs to either use the OpenMethod:
does not exists: misuse.prjconfig.correct.openmethod
or OpenClass:
does not exists: misuse.prjconfig.correct.openclass
This is very annoying and definitely not clueless! As such exposing patterns that require OpenClass or OpenMethod to ClientAPI users is not really recommended.
On the other hand, as Singletonizer pattern shows, using this style in ProviderAPI, where the open is done once by the API infrastructure is quite OK.
Follow
