I have a collection of cooperative classes whose behaviors are interdependent upon one another. But I wish to keep them loosely coupled, so I've created appropriate interfaces.
I want to determine an appropriate pattern to instantiate specific implementations of these objects.
Here's an outline of their interdependencies:
IService : IDisposable
: listens for messages; exposes aListen
method which:- calls
IMessageClient.GetNextMessage
iteratively - invokes a (delegate which creates a?) new
IMessageHandler
instance in a new thread for each message - up to
NumberOfThreads
concurrent threads
- calls
IServiceMonitor<IService>
: monitors the service:- exposes
Start
method which invokes theIService.Listen()
- exposes
Stop
method which disposesIService
- exposes
Pause
andResume
methods which respectively zero or reset theIService.NumberOfThreads
- calls
CreateRemoteConfigClient()
to get a client every 90 seconds, thenIRemoteConfigClient.GetConfig
- notifies any configuration changes to
IMessageClient
,IService
, and any subsequentIMessageHandler
- exposes
IMessageClient : IDisposable
; exposesGetNextMessage
which:- long polls a message queue for the next request
IMessageHandler : IDisposable
; exposesHandleMessage
which:- does something with the message, requesting on the way further
IXyzClient
s from theIFactory
to access other services
- does something with the message, requesting on the way further
IRemoteConfigClient : IDisposable
; exposesGetConfig
which:- retrieves any remote overrides of the current configuration state
This has led me to create:
IFactory
; with the following members:CreateMonitor
: returns a newIServiceMonitor<IService>
GetService
: returns theIService
created to accompany the most recentIServiceMonitor
, or a newIService
- NB: a Service should be able to be obtained without a Monitor having been created
CreateMessageClient
: returns a newIMessageClient
- Either:
CreateMessageHandler
: returns anew IMessageHandler
MessageHandlerDelegate
: creates anew IMessageHandler
and invokesHandleMessage
CreateRemoteConfigClient
: returns anew IRemoteConfigClient
Implementations of the core interfaces accept the IFactory
in their constructors.
This is so that:
IService
can callCreateMessageClient()
to get a singleIMessageClient
which it willDispose
when it's doneIServiceMonitor
can callGetService()
to allow it to coordinate and monitor theIService
IMessageHandler
can report its progress back viaIMessageClient
IFactory
, of course, started out ostensibly as an implementation of the Factory pattern, then it began to lean more towards a Builder pattern, but in reality none of those feel right.
I'm Create
-ing some objects, Get
-ting others, and certain things, like the fact that a subsequent call to CreateMonitor
will modify the result of GetService
, just feel wrong.
What's the right naming convention for a class which co-ordinates all these others, and IS there an actual pattern that can be followed, am I over-engineering, or am I over-analyzing?!
IService
,IClient
, whatever. Normally the sort of architecture you've described is reserved for extremely large Java programs.