#1796 Services vs Static Classes

SlimerDude Tue 28 Feb 2012

When should I use one over the other?

Given

const class Sour : Service {
  Void apple() {}
  static Void banana() {}
}

What's the advantage of saying

Sour.banana

over

(Service.find(Sour#) as Sour).apple

Both static classes and Services have to be const, so both have to store state in Actor.locals (or an Actor).

I have 3, um, main classes that my flux app Views hook into. They're currently Services and I was wondering if they should stay that way or flip to being static??

Cheers.

brian Tue 28 Feb 2012

Well its a good question. In general I think of a service as a pluggable interface that performs some service. It has some characteristics that static methods don't have:

  • its pluggable with multiple implementations
  • you can have multiple services per type
  • it has a life cycle, install/start/stop/uninstall
  • it is usually configured at runtime and gives you late binding
  • it is optional, the service might not be installed for you use

Consider the WispService. Your web service isn't just something you would launch from a static initializer. Rather it is typically controlled and setup during the main of your daemon process. In fact this is how almost all my mains work - they setup a bunch of services, then AbstractMain.runServices loop. Flux and UI stuff tends to be different though.

SlimerDude Tue 28 Feb 2012

Okay cool, so no technical reasons then - just semantic ones. I wasn't sure if I'd overlooked anything.

Hey Brain, by the way, thanks for answering all my questions - I know I've been rattling off a fair few of late!

Login or Signup to reply.