Lecture
Real-time software typically manages several objects of the same type. Here we present the manager design pattern for managing multiple objects. The Manager design pattern is described using the standard pattern-definition template.
Classes like this are used to manage a set of objects of another class, which are often resources.
For example, suppose you have a pool of database connections, each represented by an object of the DBConnection class.
If your code needs to connect to the DB through the connection pool, it simply asks the DBConnection_Manager class for a new connection. Why do you need a manager class?
The Manager class will consult its list of DBConnection objects, determine whether any of them is unallocated, and return one. If all of them are allocated, it will either create one and add it to the pool (subject to the maximum number of connections allowed), or put the request in a queue, or report an error.
ALL of these functions are completely hidden from the caller - the finest details of pool management are the job of the Manager class.
This is just one specific example, but the idea is that resource management is centralized and encapsulated by the Manager class, while user code simply asks for a "resource".
The main goal here is to manage multiple objects of the same type. For example, a Terminal Manager would manage all the Terminal objects under its control. This would include creating a Terminal, deleting a Terminal, routing messages to a Terminal, and coordinating activities such as switching between two Terminals.
Consider the case where no Manager object is defined. Each Terminal object would have to know about all the other Terminal objects for the purposes of message routing and coordination. Also, without a Manager there would be no single point for creating and deleting Terminal objects.
This design pattern can be applied whenever a system needs to maintain many objects of the same or a similar type. The Manager object is responsible for keeping track of all the entities. In many cases the Manager also routes messages to individual objects.
The Manager object can manage all the entity objects by implementing standard data structures such as an array or an STL map. The idea is to have a fast way of indexing in order to get to a specific entity. This indexing capability is required for quick access to an object by the numeric identifier assigned to it. This numeric identifier is usually included in all the messages received for those objects.
The Manager object and the Managed Entities are the main actors in this design pattern. One Manager object manages multiple entity objects.
Communication between the manager and a managed object is usually carried out through the manager calling methods on individual objects. The return value of a method is used by the entity to communicate with the manager. Message routing is also achieved by calling the message handler on the entity object.
In more complex designs, the Manager and the object may communicate through local messages. In such cases, various coordination design patterns, such as parallel and sequential coordination, may be used.
The Manager object presents a clean interface for communicating with any managed objects. It also provides a centralized point for coordinating operations across multiple entity objects.
As mentioned earlier, the Manager object holds an array or STL map of all the objects under its control. The collection of entities can be maintained as pointers to the entity objects or as the entity objects themselves.
Basic example
var m: Mananger = new ManagerClass(); m.doSomething();
The code below gives an example of a terminal manager that manages Terminal objects. The example covers message routing and the creation and deletion of terminals. It also shows interaction involving several terminals (terminal switching). Also note that the methods of the terminal object communicate with the terminal manager by returning a status value.
The manager design pattern is used wherever multiple objects with the same or similar behavior need to be managed.
For example, in the case of ActionScript, such a class can be used to manage sounds, event listeners, or GUI widgets (for example, context menus).
Function design patterns, such as parallel and sequential coordination
Manager classes are a common dumping ground for code that somehow did not fit anywhere else. They also tend to be or become god classes .
Comments