Ticket #1183 (closed task: fixed)
Opened 2012-05-16T10:41:37-05:00
Last modified 2012-09-04T16:51:10-05:00
Finish splitting service interfaces & implementations
| Reported by: | curtis | Owned by: | curtis |
|---|---|---|---|
| Priority: | minor | Milestone: |
|
| Component: | Core | Version: | |
| Severity: | minor | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1323 |
Description
Many services now have separate interface and default implementation classes, to make it as easy as possible for developers to override the behavior of each service's public API. There are still a few services that have not been split, though. These services should be similarly split in two.
In particular, splitting IOService would eliminate the annoying T generic parameter from the IOService interface (maintaining it only for the DefaultIOService implementation until we complete work on the imgopener-generics branch), and hence eliminate warnings on "raw" usage of IOService in various plugins such as OpenImage.
Change History
comment:1 Changed 2012-06-16T01:28:09-05:00 by curtis
comment:4 Changed 2012-07-12T09:50:14-05:00 by curtis
- Blocking 1209 removed
- Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4
comment:5 Changed 2012-09-04T16:51:10-05:00 by curtis
- Status changed from new to closed
- Resolution set to fixed
More service interface/implementation splits:
- WidgetService
- SamplerService
- LegacyService
- UploaderService
- WindowService (formerly WindowMenuService)
- RecentFileService
- EventHistory
With that, all the core services have an associated interface. The only exceptions are:
- Services in the imagej.core.commands subtree.
- Services in UI-specific projects (e.g., JHotDrawService).
So I'm going to call this one "good enough"!
IOService has been split in 8bebbe2a. UIService has been split in 44ce883b.