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 2821 by tim, Thu Jun 8 06:39:37 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 166 | Line 168 | implemented by delegating the creation operation to th
168   with the problem of creating objects without specifying the exact
169   class of object that will be created. Factory Method is typically
170   implemented by delegating the creation operation to the subclasses.
169 – \begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclaration}]
170 –  class IntegratorCreator;
171 –  class IntegratorFactory {
172 –    public:
173 –      typedef std::map<std::string, IntegratorCreator*> CreatorMapType;
171  
172 <      /**
173 <       * Registers a creator with a type identifier
174 <       * @return true if registration is successful, otherwise return false
175 <       * @id the identification of the concrete object
176 <       * @creator the object responsible to create the concrete object
180 <       */
181 <      bool registerIntegrator(IntegratorCreator* creator);
172 > Registers a creator with a type identifier. Looks up the type
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={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
177  
178 <      /**
179 <       * Looks up the type identifier in the internal map. If it is found, it invokes the
180 <       * corresponding creator for the type identifier and returns its result.
186 <       * @return a pointer of the concrete object, return NULL if no creator is registed for
187 <       * creating this concrete object
188 <       * @param id the identification of the concrete object
189 <       */
190 <      Integrator* createIntegrator(const std::string& id, SimInfo* info);
178 > class IntegratorFactory {
179 >  public:
180 >    typedef std::map<string, IntegratorCreator*> CreatorMapType;
181  
182 <    private:
183 <      CreatorMapType creatorMap_;
184 <  };
182 >    bool registerIntegrator(IntegratorCreator* creator);
183 >
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}]
198 <  bool IntegratorFactory::unregisterIntegrator(const std::string& id) {
199 <    return creatorMap_.erase(id) == 1;
200 <  }
192 > \begin{lstlisting}[float,caption={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}]
193  
194 <  Integrator* IntegratorFactory::createIntegrator(const std::string& id, SimInfo* info) {
195 <    CreatorMapType::iterator i = creatorMap_.find(id);
196 <    if (i != creatorMap_.end()) {
197 <      //invoke functor to create object
198 <      return (i->second)->create(info);
199 <    } else {
200 <      return NULL;
201 <    }
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) {}
218 <    virtual ~IntegratorCreator() {}
219 <    const std::string& getIdent() const { return ident_; }
214 >    IntegratorCreator(const string& ident) : ident_(ident) {}
215  
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) {}
228 <    virtual  Integrator* create(SimInfo* info) const {return new ConcreteIntegrator(info);}
229 <  };
227 >    IntegratorBuilder(const string& ident) : IntegratorCreator(ident) {}
228 >    virtual  Integrator* create(SimInfo* info) const {
229 >      return new ConcreteIntegrator(info);
230 >    }
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}
251 – \begin{lstlisting}[float,caption={[].},label={appendixScheme:element}]
252 –  class StuntDouble {
253 –    public:
254 –      virtual void accept(BaseVisitor* v) = 0;
255 –  };
263  
264 <  class Atom: public StuntDouble {
258 <    public:
259 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
260 <  };
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 294 | 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
299 < own names which are specified in the {\tt .md} file. In contrast,
300 < RigidBodies are denoted by their membership and index inside a
301 < particular molecule: [MoleculeName]\_RB\_[index] (the contents
302 < inside the brackets depend on the specifics of the simulation). The
303 < names of rigid bodies are generated automatically. For example, the
304 < 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