| Service Oriented
Class Libraries 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 |
|
