Ticket #1183 (closed task: fixed)

Opened 8 years ago

Last modified 7 years ago

Finish splitting service interfaces & implementations

Reported by: curtis Owned by: curtis
Priority: minor Milestone: imagej2-b4-plugins
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 7 years ago by curtis

IOService has been split in 8bebbe2a. UIService has been split in 44ce883b.

comment:2 Changed 7 years ago by curtis

  • Blocking 1209 added

comment:3 Changed 7 years ago by curtis

  • Blocking 1323 added

comment:4 Changed 7 years ago by curtis

  • Blocking 1209 removed
  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4

comment:5 Changed 7 years ago by curtis

  • Status changed from new to closed
  • Resolution set to fixed

More service interface/implementation splits:

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"!

Note: See TracTickets for help on using tickets.