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 2829 by tim, Thu Jun 8 20:24:39 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.
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{lstlisting}[float,caption={[].},label={appendixScheme:visitor}]
247 <  class BaseVisitor{
248 <    public:
249 <      virtual void visit(Atom* atom);
250 <      virtual void visit(DirectionalAtom* datom);
251 <      virtual void visit(RigidBody* rb);
252 <  };
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 +
294   \section{\label{appendixSection:concepts}Concepts}
295  
296   OOPSE manipulates both traditional atoms as well as some objects
297   that {\it behave like atoms}.  These objects can be rigid
298   collections of atoms or atoms which have orientational degrees of
299 < freedom.  Here is a diagram of the class heirarchy:
300 <
301 < %\begin{figure}
302 < %\centering
303 < %\includegraphics[width=3in]{heirarchy.eps}
304 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
305 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
306 < %selection syntax allows the user to select any of the objects that
307 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
308 < %\end{figure}
309 <
299 > freedom.  A diagram of the class heirarchy is illustrated in
300 > Fig.~\ref{oopseFig:heirarchy}. Every Molecule, Atom and
301 > DirectionalAtom in {\sc OOPSE} have their own names which are
302 > specified in the {\tt .md} file. In contrast, RigidBodies are
303 > denoted by their membership and index inside a particular molecule:
304 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
305 > on the specifics of the simulation). The names of rigid bodies are
306 > generated automatically. For example, the name of the first rigid
307 > body in a DMPC molecule is DMPC\_RB\_0.
308 > \begin{figure}
309 > \centering
310 > \includegraphics[width=\linewidth]{heirarchy.eps}
311 > \caption[Class heirarchy for StuntDoubles in {\sc OOPSE}]{ The class
312 > heirarchy of StuntDoubles in {\sc OOPSE}.
313   \begin{itemize}
314   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
315   integrators and minimizers.
# Line 289 | Line 318 | DirectionalAtom}s which behaves as a single unit.
318   \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
319   DirectionalAtom}s which behaves as a single unit.
320   \end{itemize}
321 <
322 < Every Molecule, Atom and DirectionalAtom in {\sc OOPSE} have their
294 < own names which are specified in the {\tt .md} file. In contrast,
295 < RigidBodies are denoted by their membership and index inside a
296 < particular molecule: [MoleculeName]\_RB\_[index] (the contents
297 < inside the brackets depend on the specifics of the simulation). The
298 < names of rigid bodies are generated automatically. For example, the
299 < name of the first rigid body in a DMPC molecule is DMPC\_RB\_0.
321 > } \label{oopseFig:heirarchy}
322 > \end{figure}
323  
324   \section{\label{appendixSection:syntax}Syntax of the Select Command}
325  

Diff Legend

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