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

Diff Legend

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