<< Chapter < Page Chapter >> Page >
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.

1. decoupling algorithms from data structures

Recall the current formulation of the immutable list structure using the composite pattern.

 

Each time we want to compute something new, we apply the interpreter pattern add appropriate methods to IList and implement those methods in MTList and NEList.  This process of extending the capability of the list structure is error-prone at best and cannot be carried out if one does not own the source code for this structure. Any method added to the system can access the private fields of MTList and NEList and modify them at will.  In particular, the code can change _fist and _rest of NEList breaking the invariant immutable property the system is supposed to represent. The system so designed is inherently fragile, cumbersome, rigid, and limited.  We end up with a forever changing IList that includes a multitude of unrelated methods.

These design flaws come of the lack of delineation between the intrinsic and primitive behavior of the structure itself and the more complex behavior needed for a specific application. The failure to decouple primitive and non-primitive operations also causes reusability and extensibility problems. The weakness in bundling a data structure with a predefined set of operations is that it presents a static non-extensible interface to the client that cannot handle unforeseen future requirements. Reusability and extensibility are more than just aesthetic issues; in the real world, they are driven by powerful practical and economic considerations. Computer science students should be conditioned to design code with the knowledge that it will be modified many times. In particular is the need for the ability to add features after the software has been delivered.  Therefore one must seek to decouple the data structures from the algorithms (or operations) that manipulate it.  Before we present an object-oriented approach to address this issue, let's first eat!

Get Jobilize Job Search Mobile App in your pocket Now!

Get it on Google Play Download on the App Store Now




Source:  OpenStax, Principles of object-oriented programming. OpenStax CNX. May 10, 2013 Download for free at http://legacy.cnx.org/content/col10213/1.37
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Principles of object-oriented programming' conversation and receive update notifications?

Ask