ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/group/trunk/tengDissertation/Appendix.tex
(Generate patch)

Comparing trunk/tengDissertation/Appendix.tex (file contents):
Revision 2822 by tim, Thu Jun 8 07:27:56 2006 UTC vs.
Revision 2828 by tim, Thu Jun 8 20:10:36 2006 UTC

# Line 131 | Line 131 | is declared as
131   is declared as
132   \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] Declaration of {\tt IntegratorFactory} class.},label={appendixScheme:singletonDeclaration}]
133  
134 <  class IntegratorFactory {
135 <    public:
136 <      static IntegratorFactory* getInstance();
134 > class IntegratorFactory {
135 >  public:
136 >    static IntegratorFactory* getInstance();
137      protected:
138        IntegratorFactory();
139      private:
140        static IntegratorFactory* instance_;
141 <  };
141 > };
142 >
143   \end{lstlisting}
144   The corresponding implementation is
145 < \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
145 > \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
146  
147   IntegratorFactory::instance_ = NULL;
148  
# Line 151 | Line 152 | IntegratorFactory* getInstance() {
152    }
153    return instance_;
154   }
155 +
156   \end{lstlisting}
157   Since constructor is declared as {\tt protected}, a client can not
158   instantiate {\tt IntegratorFactory} directly. Moreover, since the
# Line 171 | Line 173 | result.
173   identifier in the internal map. If it is found, it invokes the
174   corresponding creator for the type identifier and returns its
175   result.
176 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclaration}]
175 <  class IntegratorCreator;
176 <  class IntegratorFactory {
177 <    public:
178 <      typedef std::map<std::string, IntegratorCreator*> CreatorMapType;
176 > \begin{lstlisting}[float,caption={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
177  
178 <      bool registerIntegrator(IntegratorCreator* creator);
178 > class IntegratorFactory {
179 >  public:
180 >    typedef std::map<string, IntegratorCreator*> CreatorMapType;
181  
182 <      Integrator* createIntegrator(const std::string& id, SimInfo* info);
182 >    bool registerIntegrator(IntegratorCreator* creator);
183  
184 <    private:
185 <      CreatorMapType creatorMap_;
186 <  };
184 >    Integrator* createIntegrator(const string& id, SimInfo* info);
185 >
186 >  private:
187 >    CreatorMapType creatorMap_;
188 > };
189 >
190   \end{lstlisting}
191  
192 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclarationImplementation}]
190 <  bool IntegratorFactory::unregisterIntegrator(const std::string& id) {
191 <    return creatorMap_.erase(id) == 1;
192 <  }
192 > \begin{lstlisting}[float,caption={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}]
193  
194 <  Integrator*
195 <  IntegratorFactory::createIntegrator(const std::string& id, SimInfo* info) {
196 <    CreatorMapType::iterator i = creatorMap_.find(id);
197 <    if (i != creatorMap_.end()) {
198 <      //invoke functor to create object
199 <      return (i->second)->create(info);
200 <    } else {
201 <      return NULL;
202 <    }
194 > bool IntegratorFactory::unregisterIntegrator(const string& id) {
195 >  return creatorMap_.erase(id) == 1;
196 > }
197 >
198 > Integrator* IntegratorFactory::createIntegrator(const string& id,
199 >                                                SimInfo* info) {
200 >  CreatorMapType::iterator i = creatorMap_.find(id);
201 >  if (i != creatorMap_.end()) {
202 >    return (i->second)->create(info);
203 >  } else {
204 >    return NULL;
205    }
206 + }
207 +
208   \end{lstlisting}
209  
210 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:integratorCreator}]
210 > \begin{lstlisting}[float,caption={[The implementation of Factory pattern (III)].},label={appendixScheme:integratorCreator}]
211  
212 <  class IntegratorCreator {
212 > class IntegratorCreator {
213    public:
214 <    IntegratorCreator(const std::string& ident) : ident_(ident) {}
214 >    IntegratorCreator(const string& ident) : ident_(ident) {}
215  
216 <    const std::string& getIdent() const { return ident_; }
216 >    const string& getIdent() const { return ident_; }
217  
218      virtual Integrator* create(SimInfo* info) const = 0;
219  
220    private:
221 <    std::string ident_;
222 <  };
221 >    string ident_;
222 > };
223  
224 <  template<class ConcreteIntegrator>
225 <  class IntegratorBuilder : public IntegratorCreator {
224 > template<class ConcreteIntegrator>
225 > class IntegratorBuilder : public IntegratorCreator {
226    public:
227 <    IntegratorBuilder(const std::string& ident) : IntegratorCreator(ident) {}
227 >    IntegratorBuilder(const string& ident) : IntegratorCreator(ident) {}
228      virtual  Integrator* create(SimInfo* info) const {
229        return new ConcreteIntegrator(info);
230      }
231 <  };
231 > };
232   \end{lstlisting}
233  
234   \subsection{\label{appendixSection:visitorPattern}Visitor}
235  
236   The purpose of the Visitor Pattern is to encapsulate an operation
237 < that you want to perform on the elements of a data structure. In
238 < this way, you can change the operation being performed on a
239 < structure without the need of changing the class heirarchy of the
240 < elements that you are operating on.
241 <
242 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:visitor}]
243 <  class BaseVisitor{
244 <    public:
245 <      virtual void visit(Atom* atom);
246 <      virtual void visit(DirectionalAtom* datom);
247 <      virtual void visit(RigidBody* rb);
248 <  };
237 > that you want to perform on the elements. The operation being
238 > performed on a structure can be switched without changing the
239 > interfaces  of the elements. In other words, one can add virtual
240 > functions into a set of classes without modifying their interfaces.
241 > The UML class diagram of Visitor patten is shown in
242 > Fig.~\ref{appendixFig:visitorUML}. {\tt Dump2XYZ} program in
243 > Sec.~\ref{appendixSection:Dump2XYZ} uses Visitor pattern
244 > extensively.
245 >
246 > \begin{figure}
247 > \centering
248 > \includegraphics[width=\linewidth]{visitor.eps}
249 > \caption[The architecture of {\sc OOPSE}] {Overview of the structure
250 > of {\sc OOPSE}} \label{appendixFig:visitorUML}
251 > \end{figure}
252 >
253 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
254 >
255 > class BaseVisitor{
256 >  public:
257 >    virtual void visit(Atom* atom);
258 >    virtual void visit(DirectionalAtom* datom);
259 >    virtual void visit(RigidBody* rb);
260 > };
261 >
262   \end{lstlisting}
246 – \begin{lstlisting}[float,caption={[].},label={appendixScheme:element}]
247 –  class StuntDouble {
248 –    public:
249 –      virtual void accept(BaseVisitor* v) = 0;
250 –  };
263  
264 <  class Atom: public StuntDouble {
253 <    public:
254 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
255 <  };
264 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
265  
266 <  class DirectionalAtom: public Atom {
267 <    public:
268 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
269 <  };
266 > class StuntDouble {
267 >  public:
268 >    virtual void accept(BaseVisitor* v) = 0;
269 > };
270  
271 <  class RigidBody: public StuntDouble {
272 <    public:
273 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
274 <  };
271 > class Atom: public StuntDouble {
272 >  public:
273 >    virtual void accept{BaseVisitor* v*} {
274 >      v->visit(this);
275 >    }
276 > };
277 >
278 > class DirectionalAtom: public Atom {
279 >  public:
280 >    virtual void accept{BaseVisitor* v*} {
281 >      v->visit(this);
282 >    }
283 > };
284 >
285 > class RigidBody: public StuntDouble {
286 >  public:
287 >    virtual void accept{BaseVisitor* v*} {
288 >      v->visit(this);
289 >    }
290 > };
291  
292   \end{lstlisting}
293   \section{\label{appendixSection:concepts}Concepts}
294  
295 + \begin{figure}
296 + \centering
297 + \includegraphics[width=\linewidth]{heirarchy.eps}
298 + \caption[Class heirarchy for StuntDoubles in {\sc OOPSE}]{ The class
299 + heirarchy of StuntDoubles in {\sc OOPSE}.}
300 + \label{oopseFig:heirarchy}
301 + \end{figure}
302 +
303   OOPSE manipulates both traditional atoms as well as some objects
304   that {\it behave like atoms}.  These objects can be rigid
305   collections of atoms or atoms which have orientational degrees of
306 < freedom.  Here is a diagram of the class heirarchy:
306 > freedom.  A diagram of the class heirarchy is illustrated in
307 > Fig.~\ref{oopseFig:heirarchy}.
308  
275 – %\begin{figure}
276 – %\centering
277 – %\includegraphics[width=3in]{heirarchy.eps}
278 – %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
279 – %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
280 – %selection syntax allows the user to select any of the objects that
281 – %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
282 – %\end{figure}
309  
310   \begin{itemize}
311   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines