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 2816 by tim, Wed Jun 7 19:51:57 2006 UTC vs.
Revision 2827 by tim, Thu Jun 8 20:05:53 2006 UTC

# Line 118 | Line 118 | The Singleton pattern ensures that only one instance o
118   OOPSE}.
119  
120   \subsection{\label{appendixSection:singleton}Singleton}
121 < The Singleton pattern ensures that only one instance of a class is
122 < created. All objects that use an instance of that class use the same
123 < instance.
121 > The Singleton pattern not only provides a mechanism to restrict
122 > instantiation of a class to one object, but also provides a global
123 > point of access to the object. Currently implemented as a global
124 > variable, the logging utility which reports error and warning
125 > messages to the console in {\sc OOPSE} is a good candidate for
126 > applying the Singleton pattern to avoid the global namespace
127 > pollution.Although the singleton pattern can be implemented in
128 > various ways  to account for different aspects of the software
129 > designs, such as lifespan control \textit{etc}, we only use the
130 > static data approach in {\sc OOPSE}. {\tt IntegratorFactory} class
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 + };
142 +
143 + \end{lstlisting}
144 + The corresponding implementation is
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 +
149 + IntegratorFactory* getInstance() {
150 +  if (instance_ == NULL){
151 +    instance_ = new IntegratorFactory;
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
159 + member function {\tt getInstance} serves as the only entry of access
160 + to {\tt IntegratorFactory}, this approach fulfills the basic
161 + requirement, a single instance. Another consequence of this approach
162 + is the automatic destruction since static data are destroyed upon
163 + program termination.
164 +
165   \subsection{\label{appendixSection:factoryMethod}Factory Method}
126 – The Factory Method pattern is a creational pattern which deals with
127 – the problem of creating objects without specifying the exact class
128 – of object that will be created. Factory Method solves this problem
129 – by defining a separate method for creating the objects, which
130 – subclasses can then override to specify the derived type of product
131 – that will be created.
166  
167 + Categoried as a creational pattern, the Factory Method pattern deals
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.
171 +
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 + class IntegratorFactory {
179 +  public:
180 +    typedef std::map<string, IntegratorCreator*> CreatorMapType;
181 +
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={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}]
193 +
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={[The implementation of Factory pattern (III)].},label={appendixScheme:integratorCreator}]
211 +
212 + class IntegratorCreator {
213 +  public:
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 +    string ident_;
222 + };
223 +
224 + template<class ConcreteIntegrator>
225 + class IntegratorBuilder : public IntegratorCreator {
226 +  public:
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 classes of the elements
240 < 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{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}
263 >
264 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
265 >
266 > class StuntDouble {
267 >  public:
268 >    virtual void accept(BaseVisitor* v) = 0;
269 > };
270 >
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   OOPSE manipulates both traditional atoms as well as some objects
# Line 144 | Line 297 | freedom.  Here is a diagram of the class heirarchy:
297   collections of atoms or atoms which have orientational degrees of
298   freedom.  Here is a diagram of the class heirarchy:
299  
300 < %\begin{figure}
301 < %\centering
302 < %\includegraphics[width=3in]{heirarchy.eps}
303 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
304 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
152 < %selection syntax allows the user to select any of the objects that
153 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
154 < %\end{figure}
155 <
300 > \begin{figure}
301 > \centering
302 > \includegraphics[width=3in]{heirarchy.eps}
303 > \caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ The
304 > class heirarchy of StuntDoubles in {\sc oopse}-3.0.
305   \begin{itemize}
306   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
307   integrators and minimizers.
# Line 160 | Line 309 | DirectionalAtom}s which behaves as a single unit.
309   \item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
310   \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
311   DirectionalAtom}s which behaves as a single unit.
312 < \end{itemize}
312 > \end{itemize}} \label{oopseFig:heirarchy}
313 > \end{figure}
314  
315   Every Molecule, Atom and DirectionalAtom in {\sc OOPSE} have their
316   own names which are specified in the {\tt .md} file. In contrast,
# Line 502 | Line 652 | Dump2XYZ can transform an OOPSE dump file into a xyz f
652  
653   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
654  
655 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
656 < be opened by other molecular dynamics viewers such as Jmol and
657 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
658 < follows:
655 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
656 > which can be opened by other molecular dynamics viewers such as Jmol
657 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
658 > as follows:
659  
660  
661   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 686 | The options available for Hydro are as follows:
686   \end{longtable}
687  
688   \subsection{\label{appendixSection:hydrodynamics}Hydro}
689 < The options available for Hydro are as follows:
689 >
690 > {\tt Hydro} can calculate resistance and diffusion tensors at the
691 > center of resistance. Both tensors at the center of diffusion can
692 > also be reported from the program, as well as the coordinates for
693 > the beads which are used to approximate the arbitrary shapes. The
694 > options available for Hydro are as follows:
695   \begin{longtable}[c]{|EFG|}
696   \caption{Hydrodynamics Command-line Options}
697   \\ \hline

Diff Legend

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