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 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 166 | Line 169 | implemented by delegating the creation operation to th
169   with the problem of creating objects without specifying the exact
170   class of object that will be created. Factory Method is typically
171   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;
172  
173 <      /**
174 <       * Registers a creator with a type identifier
175 <       * @return true if registration is successful, otherwise return false
176 <       * @id the identification of the concrete object
177 <       * @creator the object responsible to create the concrete object
180 <       */
181 <      bool registerIntegrator(IntegratorCreator* creator);
173 > Registers a creator with a type identifier. Looks up the type
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={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
178  
179 <      /**
180 <       * Looks up the type identifier in the internal map. If it is found, it invokes the
181 <       * 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);
179 > class IntegratorFactory {
180 > public:
181 >  typedef std::map<string, IntegratorCreator*> CreatorMapType;
182  
183 <    private:
184 <      CreatorMapType creatorMap_;
194 <  };
195 < \end{lstlisting}
196 <
197 < \begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclarationImplementation}]
198 <  bool IntegratorFactory::unregisterIntegrator(const std::string& id) {
199 <    return creatorMap_.erase(id) == 1;
183 >  bool registerIntegrator(IntegratorCreator* creator) {
184 >    return creatorMap_.insert(creator->getIdent(), creator).second;
185    }
186  
187 <  Integrator* 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
206 <      return (i->second)->create(info);
207 <    } else {
208 <      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 {
216 <  public:
217 <    IntegratorCreator(const std::string& ident) : ident_(ident) {}
218 <    virtual ~IntegratorCreator() {}
219 <    const std::string& getIdent() const { return ident_; }
206 >    const string& getIdent() const { return ident_; }
207  
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 {return new ConcreteIntegrator(info);}
219 <  };
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}
251 – \begin{lstlisting}[float,caption={[].},label={appendixScheme:element}]
252 –  class StuntDouble {
253 –    public:
254 –      virtual void accept(BaseVisitor* v) = 0;
255 –  };
254  
255 <  class Atom: public StuntDouble {
258 <    public:
259 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
260 <  };
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 294 | 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
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.
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