Servant (design pattern)

Servant is a design pattern for situations where we want to offer some functionality to a group of classes without defining that functionality in each of them. Servant is a class, whose instance (or even just class) offers methods, which takes care of a desired service, while objects for which (or with whom) the servant does something, takes as parameters.

Description and simple example

Servant is used for providing some behavior to group of classes. Instead of defining that behavior in each class (also when we cannot factor out this behavior in the common parent class), it is defined once in servant.

For example we have a few classes representing geometric objects (rectangle, ellipse, and triangle). We can draw these objects on some canvas. When we need to provide a “move” method for these objects we could implement this method in each class, or we can define an interface they implement and then offer the “move” functionality in a servant. An interface is defined to ensure that serviced classes have methods, that servant needs to provide desired behavior. If we continue in our example, we define an Interface “IMovable” specifying that, every class implementing this interface needs to implement method “getPosition” and “setPosition”. First method gets the position of object on canvas and second one sets position of object and draws it on canvas. Then we define a servant class “MoveServant”, which has two methods “moveTo(IMovable movedObject, Position where)” and moveby(IMovable movedObject, int dx, int dy). Servant class can now move every object, which implements the IMovable and we have that “moving” code in only one class, applying “Separation of concerns” rule.

Two ways of implementation

There are two ways how to implement this design pattern.

User knows the servant (he doesn’t have to know the serviced classes then) a he sends messages with his requests right to servant instances, while he passes serviced instances as parameters.
Serviced instances knows servant and user sends them messages with his requests (user doesn’t have to know servant then). Serviced instances then sends messages to instances of servant, asking for service.

The serviced classes (geometric objects from our example) don’t know about servant, but they implement the “IServiced” interface. The user class just calls the method of servant and passes serviced objects as parameters. This situation is shown on figure 1.

User uses servant to achieve some functionality and passes the serviced objects as parameters.

On figure 2 is shown opposite situation, where user don’t know about servant class and calls directly serviced classes. Serviced classes then asks servant themselves to achieve desired functionality.

User requests operations from serviced instances, which then asks servant to do it for them.

How to implement Servant

Analyze what behavior servant should take care of. State what methods servant will define and what these methods will need from serviced parameter. By other words, what serviced instance must provide, so that servants methods can achieve their goals.

Analyze what abilities serviced classes must have, so they can be properly serviced.

We define an interface, which will enforce implementation of declared methods.

Define an interface specifying requested behavior of serviced objects. If some instance wants to be served by servant, it must implement this interface.

Define (or acquire somehow) specified servant (his class).

Implement defined interface with serviced classes.

Example

This simple example shows the situation described above. This example is only illustrative and will not offer any actual drawing of geometric objects, nor specifying how they look like.

// Servant class, offering its functionality to classes implementing
// IMovable Interface
public class MoveServant{
    // Method, which will move IMovable implementing class to position where
    public void moveTo(IMovable serviced, Position where){
        // Do some other stuff to ensure it moves smoothly and nicely, this is the place to offer the functionality
        serviced.setPosition(where);
    }
    // Method, which will move IMovable implementing class by dx and dy
    public void moveBy(IMovable serviced, int dx, int dy){
        // this is the place to offer the functionality
        dx += serviced.getPosition().xPosition;
        dy += serviced.getPosition().yPosition;
        serviced.setPosition(new Position(dx, dy));
    }
}

// Interface specifying what serviced classes needs to implement, to be
// serviced by servant.
public interface IMovable{
    public void setPosition(Position p);
    public Position getPosition();
}

// One of geometric classes
public class Triangle implements IMovable{
    // Position of the geometric object on some canvas
    private Position p;
    // Method, which returns position of geometric object
    public void setPosition(Position p){
        this.p = p;
    }
    // Method, which sets position of geometric object
    public Position getPosition(){
        return this.p;
    }
}

// One of geometric classes
public class Ellipse implements IMovable{
    // Position of the geometric object on some canvas
    private Position p;
    // Method, which returns position of geometric object
    public void setPosition(Position p){
        this.p = p;
    }
    // Method, which sets position of geometric object
    public Position getPosition(){
        return this.p;
    }
}

// One of geometric classes
public class Rectangle implements IMovable{
    // Position of the geometric object on some canvas
    private Position p;
    // Method, which returns position of geometric object
    public void setPosition(Position p){
        this.p = p;
    }
    // Method, which sets position of geometric object
    public Position getPosition(){
        return this.p;
    }
}

// Just a very simple container class for position.
public class Position{
    public int xPosition;
    public int yPosition;
    public Position(int dx, int dy){
        xPosition = dx;
        yPosition = dy;
    }
}

Similar design pattern: Command

Design patterns Command and Servant are indeed very similar and implementation is often virtually the same. Difference between them is the approach to the problem, which programmer chose.

In case of pattern Servant we have some objects, to which we want offer, some functionality. So we create class, whose instances offer that requested functionality and which defines an interface, which serviced objects must implement. Serviced instances are then passed as parameters to the servant.

In case of pattern Command we have some objects that we want to modify with some functionality (we want to add something to them). So we define an interface, which classes with desired functionality must implement. Instances of those classes are then passed to original objects as parameters of their methods.

Even though design patterns Command and Servant are similar it doesn’t mean it’s always like that. There are a number of situations where use of design pattern Command doesn’t relate to with design pattern Servant. In these situations we usually need to pass to called methods just reference to another method, which she will need in accomplishing her goal. Because we can’t pass reference to method in many languages (Java), we have to pass object implementing interface which declares signature of passed method.

Resources

Pecinovský, Rudolf (2006). Let’s Modify the Objects First Approach into Design Patterns First (PDF). Eleventh Annual Conference on Innovation and Technology in Computer Science Education, University of Bologna. {{cite conference}}: External link in |conferenceurl= (help); Unknown parameter |coauthors= ignored (|author= suggested) (help); Unknown parameter |conferenceurl= ignored (|conference-url= suggested) (help); Unknown parameter |month= ignored (help)