quantlib的非循环访问者模式分析

类：cashflows类，都是一些函数函数：bps函数中声明：BPSCalculator calc(discountCurve,npvDate);BPSCalculator类的定义是：class BPSCalculator:public AcyclicVisitor,public Visitor<CashFlow>,public Visitor<Coupon>{public:BPSCalculator(const YieldTermStructure&termStructure,const Date&npvDate):termStructure_(termStructure),npvDate_(npvDate),result_(0.0){}void visit(Coupon&c){result_+=c.accrualPeriod()*c.nominal()*termStructure_.discount(c.date());}void visit(CashFlow&){}Real result()const{if(npvDate_==Date())return result_;elsereturn result_/termStructure_.discount(npvDate_);}private:const YieldTermStructure&termStructure_;Date npvDate_;Real result_;};BPSCalculator类分析，有3个积累，是一个“非循环访问者”，表明它可以作为一个访问者，有一个visit方法，执行一些具体的（针对它访问的元素）操作。

接受一个被访问的要素，在这里可能是“CashFlow”或其派生类Coupon。

继承链：cashflow->coupon->FixedRateCoupon，他们都有一个accept方法，接受一个AcyclicVisitor访问者类对象，这些函数分别是执行一些转化操作，如果转化成功，就执行AcyclicVisitor的visit函数。

代码如下：inline void CashFlow::accept(AcyclicVisitor&v){Visitor<CashFlow>*v1=dynamic_cast<Visitor<CashFlow>*>(&v);if(v1!=0)v1->visit(*this);elseEvent::accept(v);}void Coupon::accept(AcyclicVisitor&v){Visitor<Coupon>*v1=dynamic_cast<Visitor<Coupon>*>(&v);if(v1!=0)v1->visit(*this);elseCashFlow::accept(v);}inline void FixedRateCoupon::accept(AcyclicVisitor&v){Visitor<FixedRateCoupon>*v1=dynamic_cast<Visitor<FixedRateCoupon>*>(&v);if(v1!=0)v1->visit(*this);elseCoupon::accept(v);}最后有2点注意：1。

注意AcyclicVisitor&v，之所以可以dynamic_cast成Visitor<FixedRateCoupon>或Visitor<Coupon>或Visitor<CashFlow>，这是由于AcyclicVisitor的子类BPSCalculator，有多个基类，包括Visitor<CashFlow>和Visitor<Coupon>。

2。

元素的accept主要就是执行访问者的visit函数，所以对元素的具体操作，应该在“访问者的visit函数”中完成。

客户端的代码是：Real CashFlows::bps(const Leg&cashflows,const YieldTermStructure&discountCurve,Date settlementDate,const Date&npvDate,Natural exDividendDays){if(settlementDate==Date())settlementDate=discountCurve.referenceDate();BPSCalculator calc(discountCurve,npvDate);for(Size i=0;i<cashflows.size();++i){if(!cashflows[i]->hasOccurred(settlementDate+exDividendDays))cashflows[i]->accept(calc);}return basisPoint_*calc.result();}Acyclic Visitor(v1.0)Robert C. MartinObject Mentorrmartin@I NTENTAllow new functions to be added to existing class hierarchies without affecting those hierarchies, and without creating the troublesome dependency cycles that are inherent to the GOF1 V ISITORM OTIVATIONProcedural software can be written in such a way that new functions can be added to existing data structures without affecting those data structures. Object oriented software can be written such that new data structures can be used by existing functions without affecting those functions. In this regard they are the inverse of each other. Adding new data types without affecting existing functions is at the heart of many of the benefits of OO. Yet there are times when we really want to add a new function to an existing set of classes without changing those classes. The V ISITOR2 pattern provides a means to accomplish this goal.However, the V ISITOR pattern, when used in static languages like C++, Java, or Eiffel, causes a cycle in the source code dependency structure. (See Figure 1 and the legend at the end of this paper.) A source code dependency means that the source code of one module must refer to (via #include, or import, or some other mechanism) the source code of another module.1.“Gang of Four” : Gamma, Helm, Vlissides, and Johnson. The four authors of Design Patterns Elements of Reusable Object Oriented Soft-ware, Gamma, et. al. Addison Wesley, 19952.Design Patterns Elements of Reusable Object Oriented Software, Gamma, et. al. Addison Wesley, 1995 p. 331The dependency cycle in this case is as follows:• The base class of the visited hierarchy ( Element) depends upon the base class of the corresponding visitor hier-archy ( Visitor ). • The Visitor base class has member functions for each of the derivatives of the Element base class. Thus the Visitor class depends upon each derivative of Element .• Of course, each derivative of Element depends upon Element .Thus we have a cycle of dependencies that causes Element to transitively depend upon all its derivatives.This knot of dependencies can cause significant troubles for the programmer who must maintain the code which con-tains them. Any time a new derivative of Element is created, the Visitor class must also be changed. Since El-ement depends upon Visitor , every module that depends upon Element must be recompiled. This means that every derivative of Element , and possibly every user of every derivative of Element, must also be recompiled.Where possible, this dependency cycle should be mitigated by using forward declarations . That is, in many cases the Element base class can forward declare the Visitor base class, and the Visitor base class can forward declare the derivatives of Element . This creates a much weaker source code dependency that Lakos 3 refers to as a name only dependency. Although weaker, this is still a dependency cycle and still causes many of the problems mentioned in the last paragraph. Specifically, even when name only dependencies are used as much as possible, every time a new de-rivative of Element is created, all the existing derivatives of Element must be recompiled 4 .Partial VisitationAnother disadvantage to the dependency cycle created by the Visitor pattern is the need to address every derivative of Element in every derivative of Visitor. Often, there are hierarchies for which visitation is only required for certain de-rivatives of Element. For example, consider a modem hierarchy (See Figure 2).Here we see a very compelling use for V ISITOR . We have a typical hierarchy of Modem classes with one derivative for each modem manufacturer. We also see a hierarchy of visitors for the Modem hierarchy. In this example, there is one visitor that adds the ability to configure a modem for Unix; and another that adds the ability to configure a modem for DOS. Clearly, we do not want to add these functions directly to the Modem hierarchy. There is no end to such func-tions! The last thing we want is for every user of Modem to be recompiled every time a new operating system is re-leased. Indeed, we don’t want Modem to know anything at all about operating systems. Thus, we use V ISITOR to add the configuration function to the Modem hierarchy without affecting that hierarchy.However, V ISITOR forces us to write a function for the cross product of all Modem derivatives and all ModemVisi-tor 3.Large Scale C++ Software Design , John Lakos, Addison Wesley, 1996. p249.4.See: “What’s wrong with recompiling?”, in the Notes section.system. However, what if we never use Hayes modems with Unix? V ISITOR will still force us to write a function to do it! We could, of course, print an error from the function in the Visitor base class, and then allow that function to be inherited, but we still have to write that function. Now consider a much larger hierarchy, one in which the cross product of Elementderivatives and Visitor deriv-atives is sparsely populated. The V ISITOR pattern may become inconvenient in such a hierarchy because every visitor depends upon every derivative of Element . Any time a new derivative of Element is added all derivatives, even derivatives which do not require visitor functions, must be recompiled. We would prefer to write only the functions that need writing and keep them independent from all the other derivatives of Element .Here we see how the dependency cycle can be broken. Rather than put pure virtual functions into the ModemVisitor each derivative of Modem . These classes, HayesVisitor and ZoomVisitor , provide a pure virtual Visit func-tion for HayesModem and ZoomModem respectively. Finally we inherit all three of these classes into the Config-ureDOSModemVisitor . Note that this class has exactly the same functions that it had in Figure 2. Moreover, they are implemented in exactly the same way.The Accept function in the derivatives ofModem use dynamic_cast to cast across the visitor hierarchy from ModemVisitor cross cast. It is one of the great benefits of dynamic_cast that it can safely cast to any class anywhere in the inheritance structure of the object it operates on.Now what happens if we never use Hayes modems with Unix? The ConfigureUnixModemVisitor class willsimply not inherit from HayesVisitor. Any attempt to use a Hayes modem with Unix will cause the dynamic_cast in HayesModem::Accept function to fail, thus detecting the error at that point.There are no dependency cycles anywhere in this structure. New Modem derivatives have no affect on existing modem visitors unless those visitors must implement their functions for those derivatives. New Modem derivatives can be add-ed at any time without affecting the users of Modem, the derivatives of Modem, or the users of the derivatives of Mo-dem. The need for massive recompilation is completely eliminated.A PPLICABILITYThis pattern can be used anywhere the V ISITOR pattern can be used:•When you need to add a new function to an existing hierarchy without the need to alter or affect that hierarchy. •When there are functions that operate upon a hierarchy, but which do not belong in the hierarchy itself. e.g. the ConfigureForDOS / ConfigureForUnix / ConfigureForX issue.•When you need to perform very different operations on an object depending upon its type.This pattern should be preferred over V ISITOR under the following circumstances:•When the visited class hierarchy will be frequently extended with new derivatives of the Element class.•When the recompilation, relinking, retesting or redistribution of the derivatives of Element is very expensive. S TRUCTURE(See Figure 4.)P ARTICIPANTS•Element. The base class of the hierarchy which needs to be visited. Visitors will operate upon the classes within this structure. If you are using visitor to add functions to a hierarchy, this is the base class of that hierarchy•E1, E2, ... The concrete derivatives of Element that require visiting. If you are using visitor to add functions to a hierarchy, you will write one function for each of these concrete derivatives.•Visitor. A degenerate base class. This class has no member functions at all. It sole purpose is as a place holder in the type structure. It is the type of the argument that is taken by the Accept method of Element. Since the derivatives of Element use this argument in a dynamic_cast expression, Visitor must have at least one virtual function -- typically the destructor.•E1Visitor, E2Visitor, ... The abstract visitors that correspond to each of the concrete derivatives of Element.There is a one to one relationship between these classes. Each concrete derivative of Element will have a corre-sponding abstract visitor. The abstract visitor class will have one pure virtual Visit method that takes a refer-ence to the concrete Element derivative.•VisitForF. This is the actual visitor class. It derives from Visitor so that it can be passed to the Accept func-tion of Element. It also derives from each of the abstract visitors that correspond to the concrete classes that this visitor will visit. There is no need for the visitor to derive from all the abstract visitor classes; it only needs to derive from the ones for which it will implement Visit functions.C OLLABORATIONS1.The process begins when a user wishes to apply one of the visitors to an object in the Element hierarchy. The user does not know which of the concrete derivatives of Element it actually has; instead is simply has a reference (or a pointer) to an Element.2.The user creates the visitor object. (e.g. VisitForF in Figure 4) The visitor object represents the function that the user would like to invoke upon the Element.3.The user sends the Accept message to the Element and passes the visitor object as a reference to a Visitor.4.The Accept method of the concrete derivative of Element uses dynamic_cast to cast the Visitor object to the appropriate abstract visitor class (e.g. E1Visitor from Figure 4).5.If the dynamic_cast succeeds, then the Visit message is sent to the visitor object using the interface of the abstract visitor class. The concrete derivative of Element is passed along with the Visit message.6.The actual visitor object executes the Visit method.C ONSEQUENCESThe consequences of this pattern are the same as those for V ISITOR with the following additions:+All dependency cycles are eliminated. Derivatives of Element do not depend upon each other. Recompilation is minimized.+Partial visitation is natural and does not require additional code or overhead.-dynamic_castcan be expensive in terms of runtime efficiency. Moreover, its efficiency may vary as the class hierarchy changes. Thus, A CYCLIC V ISITOR may be inappropriate in very tight real time applications where run time performance must be predictable-Some compilers don’t support dynamic_cast.-Some languages don’t support dynamic type resolution, and/or multiple inheritance.-In C++, the Visitor class must have at least one virtual function. Since the class is also degenerate, we typically make the destructor virtual.-Use of this pattern implies that there will be an abstract visitor class for each derivative of Element. Thus, classes tend to proliferate rapidly.S AMPLE C ODEThe following is the code for the Modem example used in Figure 3.// Visitor is a degenerate base class for all visitors.class Visitor{public:virtual ~Visitor() = 0;// The destructor is virtual, as all destructors ought to be.// it is also pure to prevent anyone from creating an// instance of Visitor. Since this class is going to be// used in a dynamic_cast expression, it must have at least// one virtual function.};class Modem{public:virtual void Accept(Visitor&) const = 0;};class HayesModem;class HayesModemVisitor{public:virtual void Visit(HayesModem&) const = 0;};class HayesModem : public Modem{public:virtual void Accept(Visitor& v) const;};void HayesModem::Accept(Visitor& v) const{if (HayesModemVisitor* hv = dynamic_cast<HayesModemVisitor*>(&v))hv->Visit(*this);else// AcceptError}class ZoomModem;class ZoomModemVisitor{public:virtual void Visit(ZoomModem&) const = 0;};class ZoomModem : public Modem{public:virtual void Accept(Visitor& v) const;};void ZoomModem::Accept(Visitor& v) const{if (ZoomModemVisitor* zv = dynamic_cast<ZoomModemVisitor*>(&v))zv->Visit(*this);else// AcceptError}//-------------------------// ConfigureForDOSVisitor//// This visitor configures both Hayes and Zoom modems// for DOS.//class ConfigureForDosVisitor : public Visitor, public HayesModemVisitor, public ZoomModemVisitor{public:virtual void Visit(HayesModem&); // configure Hayes for DOSvirtual void Visit(ZoomModem&); // configure Zoom for DOS};//--------------------------// ConfigureForUnixVisitor//// This visitor configures only Zoom modems for Unix//class ConfigureForUnixVisitor : public Visitor, public ZoomModemVisitor{public:virtual void Visit(ZoomModem&); // configure Zoom for Unix};K NOWN U SESWe have used this pattern in several of the projects we have consulted for. It has been used in the design of the “Mark Facility Controller” created by the Toolkit Working Group at Xerox. It has also been used in the ETS/NCARB project.5N OTESThis pattern solves a particularly nasty problem of tangled dependencies. I find this interesting in light of the fact that it depends on two such controversial features. The pattern would not be possible were it not for multiple inheritance and run time type information; both of which have been attacked as being “non-OO”.What’s wrong with recompiling?Recompiles can be very expensive for a number of reasons. First of all, they take time. When recompiles take too change in the “right” place; simply because the “right” place will force a huge recompilation. Secondly, a recompila-tion means a new object module. In this day and age of dynamically linked libraries and incremental loaders, generat-ing more object modules than necessary can be a significant disadvantage. The more DLLs that are affected by a change, the greater the problem of distributing and managing the change. Finally, a recompile means a new release of every module which needed recompiling. New releases require documentation, and testing; causing potentially huge amounts of manpower to be invested.5.see ‘publications’ at L EGENDTS26 – Positioning and Measurement Technologies and Practices IIAles Cepek and Jan PytelTS26.5 Acyclic Visitor Pattern in Formulation of Mathematical Model4/7In the case of a single model the situation is trivial, the needed virtual function is simply called based on polymorphism (and in fact, model data even need not to be passed as the parameter; observation objects can keep a pointer to it). But for N observation types and M model types we have to select from M×N possible functions. For small values of M and N it might falsely seem to be acceptable to base the solution on a cascading of if statements or on some kind of enumerations added into observation and model classes, but this way could never lead to an acceptable general design. The general object oriented solution to this problem is known as the Visitor pattern [2].2.1 Visitor PatternLinearization of observations in our discussion serves only as an example on which we try todemonstrate the technical problem. In the following text we split the linearization function into two complementary operations, conventionally named accept and visit, and introduce a new class Visitor. Resulting class hierarchies and dependencies are shown in the following figure (arrows represent inheritance, dashed arrows dependencies, and names of abstractwhere implementations of accept functions contain only a single call to the corresponding virtual visit function, for example void Distance::accept(Visitor* v) { v -> visitDist(this); }All model classes are derived from the abstract Visitor class and they implement their own virtual visit functions. In C++ dependency cycles in the source code (dashed arrows) can be eliminated using forward declarations. Abstract Observation class is the parent of all implemented observation types. In the Visitor pattern the selection of needed function is implemented as the call of two virtual functions.We used different names for various visit functions in the abstract class Visitor . These functions can be uniquely distinguished by their parameters so the usage of distinct names isTS26 – Positioning and Measurement Technologies and Practices IIAles Cepek and Jan PytelTS26.5 Acyclic Visitor Pattern in Formulation of Mathematical Model5/7just a stylistic convention and we will use only one overloaded name visit in the following text.The main problem with the visitor patter is that when adding a new observation type the Visitor class and all its derived subclasses need to be rewritten. The more, clearly not all geodetic models need to define linearization (or any other similar operation) for all observation types. This disadvantage is eliminated in a variant pattern, known as Acyclic visitor [3].2.2 Acyclic VisitorThe acyclic visitor pattern uses C++ dynamic cast mechanism to eliminate the need of definition of the visit function for a new observation type in all existing models. The basic idea is to remove pure virtual visit functions from the Visitor class and put them into individual observation-visitor abstract classes, one for each derived observation type. The Visitor class now has no functions (apart from the virtual destructor) and a model class is derived from it and from all observation-visitor classes that make sense for the given model. The model class must then implement all the relevant virtual visit functions, as depicted in the following figureThe role of observation-visitor classes (like DistanceVisitor above) is just to introduce a virtual visit function for the given observation type and thus they are ideal candidates for a single template class definition template <class Observation> class Visitor { public: virtual void visit(Observation*) = 0; };With templated observation-visitor class all accept functions are written following a simple scheme, here demonstrated on the example of a distance class void Distance::accept(Visitor* v)TS26 – Positioning and Measurement Technologies and Practices II Ales Cepek and Jan PytelTS26.5 Acyclic Visitor Pattern in Formulation of Mathematical Model FIG Working Week 2004Athens, Greece, May 22-27, 2004 6/7{if (Visitor<Distance>*dv = dynamic_cast<Visitor<Distance>*>(v)){dv -> visit(this);}else// ... error handling}If the visitor pattern is like a matrix, then acyclic visitor is like a sparse matrix [3], it implements only the relevant operations (in our case, linearization of observation types that are meaningful to the given mathematical model). Acyclic visitor adds only one runtime pointer conversion (dynamic cast) to the two calls to virtual functions from the visitor pattern. Acyclic visitor pattern as described here is based on multiple inheritance, this impose no problem with C++, but is not available in all object oriented languages. In some application areas dynamic cast might be too expensive in the terms of run time efficiency but we believe that this is not the case of geodetic applications.3. CONCLUSIONSThe main advantage of the acyclic visitor pattern is that when defining a new observation type or a new model, the existing software is not affected. This design enables highly general level of abstraction in a software implementation of the mathematical model, as formulated in [1].Based on designed patterns published in [2] and [3] the acyclic visitor pattern has been implemented in a new development branch of our free software project for adjustment of geodetic networks /software/gama.REFERENCESPetr Vanicek and Edward J. Krakiwski: Geodesy: the Concepts, North-Holland, 1986, 2nd ed., ISBN 0444 87775 4Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides: Design Patterns — Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995, ISBN 0201 63361 2Robert C. Martin: Agile Software Development — Principles, Patterns, and Practices, Prentice Hall, 2002, ISBN 0 1359 7444 5。