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 2828 by tim, Thu Jun 8 20:10:36 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 < \subsection{\label{appendixSection:visitorPattern}Visitor}
168 < The purpose of the Visitor Pattern is to encapsulate an operation
169 < that you want to perform on the elements of a data structure. In
170 < this way, you can change the operation being performed on a
137 < structure without the need of changing the classes of the elements
138 < that you are operating on.
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. 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 + \begin{figure}
296 + \centering
297 + \includegraphics[width=\linewidth]{heirarchy.eps}
298 + \caption[Class heirarchy for StuntDoubles in {\sc OOPSE}]{ The class
299 + heirarchy of StuntDoubles in {\sc OOPSE}.}
300 + \label{oopseFig:heirarchy}
301 + \end{figure}
302 +
303   OOPSE manipulates both traditional atoms as well as some objects
304   that {\it behave like atoms}.  These objects can be rigid
305   collections of atoms or atoms which have orientational degrees of
306 < freedom.  Here is a diagram of the class heirarchy:
306 > freedom.  A diagram of the class heirarchy is illustrated in
307 > Fig.~\ref{oopseFig:heirarchy}.
308  
147 – %\begin{figure}
148 – %\centering
149 – %\includegraphics[width=3in]{heirarchy.eps}
150 – %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
151 – %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}
309  
310   \begin{itemize}
311   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
# Line 502 | Line 656 | Dump2XYZ can transform an OOPSE dump file into a xyz f
656  
657   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
658  
659 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
660 < be opened by other molecular dynamics viewers such as Jmol and
661 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
662 < follows:
659 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
660 > which can be opened by other molecular dynamics viewers such as Jmol
661 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
662 > as follows:
663  
664  
665   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 690 | The options available for Hydro are as follows:
690   \end{longtable}
691  
692   \subsection{\label{appendixSection:hydrodynamics}Hydro}
693 < The options available for Hydro are as follows:
693 >
694 > {\tt Hydro} can calculate resistance and diffusion tensors at the
695 > center of resistance. Both tensors at the center of diffusion can
696 > also be reported from the program, as well as the coordinates for
697 > the beads which are used to approximate the arbitrary shapes. The
698 > options available for Hydro are as follows:
699   \begin{longtable}[c]{|EFG|}
700   \caption{Hydrodynamics Command-line Options}
701   \\ \hline

Diff Legend

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