Case Study of Writing the Extensible Visitor Pattern

From APIDesign

Have You Ever Wondered...?

Do you wonder whether knowledge of proper design patterns makes you good API designer? Yes and no. Of course knowing regular design patterns simplifies communication, understanding, etc. However there are hidden catches. Not every design pattern belongs among APIDesignPatterns - it may not be ready for evolution. For example the well known Visitor pattern is really not evolvable easily as analysed by Chapter 18.

Tripple Dispatch

The Chapter 18 discusses various approaches to implement visitor in an evolvable API. The learning path itself is important, but to stress the important point, here is the code for the final solution of the expression problem:

does not exists: visitor.clientprovider.v1

Visitors written using this style are easily extensible, by adding new expression types as shown in version 2.0:

does not exists: visitor.clientprovider.v2

This is the most flexible solution. It uses form of tripple dispatch - e.g. the final visit method is defined by the expression type, version of the expression language and implementation of the visitor interface:

does not exists: visitor.clientprovider.dispatch.v3.l2

This solution to the expression problem is another realization of the general principle to separate ClientAPI from ProviderAPI.