In Part 1 of Cairngorm Abstractions I discussed the common patterns which can be utilized in a design to simplify the implementation of concrete Cairngorm Commands and Responders. Applying such patterns can be leveraged to help facilitate code reuse and provide a maintainable, scalable architecture, as, in doing so the design will ultimately ensure reuse as well as remove redundancy.
In this post I will describe the same benefits which can be gained by defining common abstractions of Business Delegates.
Business Delegate Abstractions
A Business Delegate should provide an interface against the service to which it references. This can be viewed as a one-to-one relationship whereas the operations and signatures defined by a Service, beit an HTTPService, WebService, RemoteObject, DataService etc. would dictate the Business Delegate’s API.
However, a rather common mistake I often find is that many times Business Delegates are defined in the context of the use case which invokes them, rather than the service from which they provide an interface against.
Correcting this is quite simple: refactor the current implementation to follow the one-to-one relationship model between a Service and Business Delegate.
So for instance, if your applications service layer specifies a “UserService”, your design should essentially have only one Business Delegate API for that Service. All of the operations provided by the “UserService” would be defined by an “IUserServiceDelegate” interface which would enforce the contract between the “UserService” and concrete Delegate implementations, regardless of their underlying service mechanism.
In this manner clients (delegate instances) can be defined as the abstraction (IUserServiceDelegate) and obtain references to concrete Business Delegate instances via a Delegate Factory, and as such remain completely transparent of their underlying service implementation.
This could be implemented as follows:
1 2 3 4 5 | var delegate:IUserServiceDelegate; delegate = DelegateFactory.createUserServiceDelegate( responder ); // invoke delegate ... |
Abstract Delegates
Perhaps the most common design improvement which can be made to improve the implementation and maintainability of Business Delegates is to define proper abstractions which provide an implementation which is common amongst all Business Delegates. Additionally, in doing so you will remove a significant amount of redundancy from your design.
For example, if you compare any two Business Delegates and find they have practically the exact same implementation, that is an obvious sign that a common abstraction should be defined.
Consider the following Business Delegate implementation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | public class SomeDelegate { private var _service:RemoteObject; private var _responder:IResponder; public function SomeDelegate(responder:IResponder) { _service = ServiceLocator.getInstance(). getRemoteObject( Services.LOGIN_SERIVCE ); _responder = responder; } public function methodA(arg1:String, arg2:int) : void { var call:AsyncToken = _service.methodA( arg1, arg2); call.addResponder( _responder ); } public function methodB(arg:Boolean) : void { var call:AsyncToken = _service.methodB( arg ); call.addResponder( _responder ); } public function methodC() : void { var call:AsyncToken = _service.methodC(); call.addResponder( _responder ); } ... } |
The above example may look familiar, and when given just a bit of thought as to it’s design it becomes apparent that there is quite a bit of redundancy as every method essentially contains the same implementation code. That is, an AsyncToken is created, referencing the operation to invoke against the service, and a reference to the responder is added to the token.
The overall design would benefit much more by refactoring the commonality implemented across all Business Delegate methods to an abstraction, which in it’s simplest form could be defined as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | public class AbstractRemoteObjectDelegate { protected var service:RemoteObject; protected var responder:IResponder; public function AbstractRemoteObjectDelegate(serviceId:String, responder:IResponder) { this.service = ServiceLocator. getInstance().getRemoteObject( serviceId ); this.responder = responder; } protected function invoke(methodName:String, ...args) : void { var operation:Operation = service[ methodName ]; operation.arguments = args; var call:AsyncToken = operation.send(); call.addResponder( responder ); } } |
By defining a basic abstraction, the original implementation could then be refactored to the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | public class SomeDelegate extends AbstractRemoteObjectDelegate { public function SomeDelegate(responder:IResponder) { super( Services.LOGIN_SERIVCE, responder ); } public function methodA(arg1:String, arg2:int) : void { invoke( "methodA", arg1, arg2 ); } public function methodB(arg:Boolean) : void { invoke( "methodB", arg ); } public function methodC() : void { invoke( "methodC" ); } } |
The same basic abstractions could easily be defined for HTTPService, WebService and DataService specific Business Delegates (in fact I have a library of Cairngorm extensions which provides them; planning on releasing these soon). Pulling up common implementation code to higher level abstract types also simplifies writing tests against concrete Business Delegates as the abstraction itself would need only to be tested once.
There are many more Business Delegate abstractions I would recommend in addition to what I have outlined here, in particular configuring Delegate Factories via an IoC Container such as SAS, however I would first suggest taking a good look at your current design before adding additional layers of abstraction, and the most appropriate place to start would be to define abstractions which encapsulate commonality, promote reuse and remove redundancy.
Great series on abstraction Eric
Any plans on a new cairngen with these changes in part 1 / part 2 and your IResponder post?