| Visitor Design Pattern (2008) | |||||||||
Abstract | |||||||||
| Using the interpreter pattern to implement the overall behavior of a composite structure such as the list structure has one glaring drawback: it presents a static non-extensible interface to the client that cannot handle unforeseen future requirements. Each time a new behavior is needed to process the composite structure, new methods have to be added to the structure. As a result, the task of maintaining the code can quickly become unmanageable. The root of this problem comes from the lack of delineation between the intrinsic and primitive behaviors of the structure itself and its non-primitive application specific behaviors. The visitor design pattern offers a solution to this problem by decoupling these two kinds of behaviors into two separate systems of classes, hosts and visitors, that communicate with each other via only their public interfaces. Here the hosts are the composite structure with its invariant structural behaviors and the visitors are the infinitely varying algorithms that are to be performed on the structure. This approach turns a composite structure into a framework where control is inverted: one hands an algorithm to the structure to be executed instead of handing a structure to an algorithm to perform a computation. The structure is capable of carrying out any conforming algorithm, past, present, or future. Such a system of co-operating objects that is not only reusable and extensible, but also easy to understand and maintain. | |||||||||
Publication details | |||||||||
| |||||||||