--- trunk/tengDissertation/Appendix.tex 2006/06/08 07:27:56 2822 +++ trunk/tengDissertation/Appendix.tex 2006/06/08 20:10:36 2828 @@ -131,17 +131,18 @@ is declared as is declared as \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] Declaration of {\tt IntegratorFactory} class.},label={appendixScheme:singletonDeclaration}] - class IntegratorFactory { - public: - static IntegratorFactory* getInstance(); +class IntegratorFactory { + public: + static IntegratorFactory* getInstance(); protected: IntegratorFactory(); private: static IntegratorFactory* instance_; - }; +}; + \end{lstlisting} The corresponding implementation is -\begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}] +\begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}] IntegratorFactory::instance_ = NULL; @@ -151,6 +152,7 @@ IntegratorFactory* getInstance() { } return instance_; } + \end{lstlisting} Since constructor is declared as {\tt protected}, a client can not instantiate {\tt IntegratorFactory} directly. Moreover, since the @@ -171,115 +173,139 @@ result. identifier in the internal map. If it is found, it invokes the corresponding creator for the type identifier and returns its result. -\begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclaration}] - class IntegratorCreator; - class IntegratorFactory { - public: - typedef std::map CreatorMapType; +\begin{lstlisting}[float,caption={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}] - bool registerIntegrator(IntegratorCreator* creator); +class IntegratorFactory { + public: + typedef std::map CreatorMapType; - Integrator* createIntegrator(const std::string& id, SimInfo* info); + bool registerIntegrator(IntegratorCreator* creator); - private: - CreatorMapType creatorMap_; - }; + Integrator* createIntegrator(const string& id, SimInfo* info); + + private: + CreatorMapType creatorMap_; +}; + \end{lstlisting} -\begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclarationImplementation}] - bool IntegratorFactory::unregisterIntegrator(const std::string& id) { - return creatorMap_.erase(id) == 1; - } +\begin{lstlisting}[float,caption={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}] - Integrator* - IntegratorFactory::createIntegrator(const std::string& id, SimInfo* info) { - CreatorMapType::iterator i = creatorMap_.find(id); - if (i != creatorMap_.end()) { - //invoke functor to create object - return (i->second)->create(info); - } else { - return NULL; - } +bool IntegratorFactory::unregisterIntegrator(const string& id) { + return creatorMap_.erase(id) == 1; +} + +Integrator* IntegratorFactory::createIntegrator(const string& id, + SimInfo* info) { + CreatorMapType::iterator i = creatorMap_.find(id); + if (i != creatorMap_.end()) { + return (i->second)->create(info); + } else { + return NULL; } +} + \end{lstlisting} -\begin{lstlisting}[float,caption={[].},label={appendixScheme:integratorCreator}] +\begin{lstlisting}[float,caption={[The implementation of Factory pattern (III)].},label={appendixScheme:integratorCreator}] - class IntegratorCreator { +class IntegratorCreator { public: - IntegratorCreator(const std::string& ident) : ident_(ident) {} + IntegratorCreator(const string& ident) : ident_(ident) {} - const std::string& getIdent() const { return ident_; } + const string& getIdent() const { return ident_; } virtual Integrator* create(SimInfo* info) const = 0; private: - std::string ident_; - }; + string ident_; +}; - template - class IntegratorBuilder : public IntegratorCreator { +template +class IntegratorBuilder : public IntegratorCreator { public: - IntegratorBuilder(const std::string& ident) : IntegratorCreator(ident) {} + IntegratorBuilder(const string& ident) : IntegratorCreator(ident) {} virtual Integrator* create(SimInfo* info) const { return new ConcreteIntegrator(info); } - }; +}; \end{lstlisting} \subsection{\label{appendixSection:visitorPattern}Visitor} The purpose of the Visitor Pattern is to encapsulate an operation -that you want to perform on the elements of a data structure. In -this way, you can change the operation being performed on a -structure without the need of changing the class heirarchy of the -elements that you are operating on. - -\begin{lstlisting}[float,caption={[].},label={appendixScheme:visitor}] - class BaseVisitor{ - public: - virtual void visit(Atom* atom); - virtual void visit(DirectionalAtom* datom); - virtual void visit(RigidBody* rb); - }; +that you want to perform on the elements. The operation being +performed on a structure can be switched without changing the +interfaces of the elements. In other words, one can add virtual +functions into a set of classes without modifying their interfaces. +The UML class diagram of Visitor patten is shown in +Fig.~\ref{appendixFig:visitorUML}. {\tt Dump2XYZ} program in +Sec.~\ref{appendixSection:Dump2XYZ} uses Visitor pattern +extensively. + +\begin{figure} +\centering +\includegraphics[width=\linewidth]{visitor.eps} +\caption[The architecture of {\sc OOPSE}] {Overview of the structure +of {\sc OOPSE}} \label{appendixFig:visitorUML} +\end{figure} + +\begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}] + +class BaseVisitor{ + public: + virtual void visit(Atom* atom); + virtual void visit(DirectionalAtom* datom); + virtual void visit(RigidBody* rb); +}; + \end{lstlisting} -\begin{lstlisting}[float,caption={[].},label={appendixScheme:element}] - class StuntDouble { - public: - virtual void accept(BaseVisitor* v) = 0; - }; - class Atom: public StuntDouble { - public: - virtual void accept{BaseVisitor* v*} {v->visit(this);} - }; +\begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}] - class DirectionalAtom: public Atom { - public: - virtual void accept{BaseVisitor* v*} {v->visit(this);} - }; +class StuntDouble { + public: + virtual void accept(BaseVisitor* v) = 0; +}; - class RigidBody: public StuntDouble { - public: - virtual void accept{BaseVisitor* v*} {v->visit(this);} - }; +class Atom: public StuntDouble { + public: + virtual void accept{BaseVisitor* v*} { + v->visit(this); + } +}; + +class DirectionalAtom: public Atom { + public: + virtual void accept{BaseVisitor* v*} { + v->visit(this); + } +}; + +class RigidBody: public StuntDouble { + public: + virtual void accept{BaseVisitor* v*} { + v->visit(this); + } +}; \end{lstlisting} \section{\label{appendixSection:concepts}Concepts} +\begin{figure} +\centering +\includegraphics[width=\linewidth]{heirarchy.eps} +\caption[Class heirarchy for StuntDoubles in {\sc OOPSE}]{ The class +heirarchy of StuntDoubles in {\sc OOPSE}.} +\label{oopseFig:heirarchy} +\end{figure} + OOPSE manipulates both traditional atoms as well as some objects that {\it behave like atoms}. These objects can be rigid collections of atoms or atoms which have orientational degrees of -freedom. Here is a diagram of the class heirarchy: +freedom. A diagram of the class heirarchy is illustrated in +Fig.~\ref{oopseFig:heirarchy}. -%\begin{figure} -%\centering -%\includegraphics[width=3in]{heirarchy.eps} -%\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\ -%The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The -%selection syntax allows the user to select any of the objects that -%are descended from a StuntDouble.} \label{oopseFig:heirarchy} -%\end{figure} \begin{itemize} \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the