In this methodology, all the functionality is encapsulated into reusable classes (called as service classes), typically, non-visual custom classes. When an object needs certain functionality, let the object request the service from the service class. For the sake of example, we have a DataWindow user object in which we want to provide all the required functionality.
Fat DataWindow User Object
In the traditional way, what we have done is, we would have defined the methods in the DataWindow user object it self. At run-time what happens? A fat object that needs more resources. Why the object is fat? Because, we have defined all potentially required methods in the object it self.
DataWindow
User Object - Services
In the service-oriented methodology, what we are doing is, define all functionality separately, one object for each functionality, i.e., one class for sorting, one for filtering, one for find & replace and so on. When the DataWindow needs a functionality, say, sorting, it requests the service from the sort service. That means we instantiate only those service classes that are required. In technical terms this is called delegation and in consultant terminology it’s called as out-sourcing. In this example, DataWindow is delegating the work to different services. It’s something like a client/server model. The client ( DataWindow user object ) requests server ( service class ) for the service. The server (service class) does the actual work that is requested by client ( DataWindow user object). In this methodology, we use events at the client ( DataWindow user object ) to route the requests to the appropriate service class. This approach has its own merits & de-merits. The advantages over weigh the disadvantages.
Disadvantages:
 |
There is some overhead of routing the requests to the proper service class and getting the service done |
|
Needs a lot more designing than normal Object-Orientation |
|
The Developer-user of this class library needs more learning and experience to understand and implement this approach. |
Advantages:
|
Thinner ancestor classes |
|
More reusable objects |
|
Can provide reusable characteristics to non-inheritable objects such as application object. |
|
Functionality is fully encapsulated |
|
Allows you to give the same functionality that is possible with multiple inheritance without using multiple inheritance |