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 2824 by tim, Thu Jun 8 15:44:14 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 + \end{lstlisting}
143 + The corresponding implementation is
144 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
145 +
146 + IntegratorFactory::instance_ = NULL;
147 +
148 + IntegratorFactory* getInstance() {
149 +  if (instance_ == NULL){
150 +    instance_ = new IntegratorFactory;
151 +  }
152 +  return instance_;
153 + }
154 + \end{lstlisting}
155 + Since constructor is declared as {\tt protected}, a client can not
156 + instantiate {\tt IntegratorFactory} directly. Moreover, since the
157 + member function {\tt getInstance} serves as the only entry of access
158 + to {\tt IntegratorFactory}, this approach fulfills the basic
159 + requirement, a single instance. Another consequence of this approach
160 + is the automatic destruction since static data are destroyed upon
161 + program termination.
162 +
163   \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.
164  
165 + Categoried as a creational pattern, the Factory Method pattern deals
166 + with the problem of creating objects without specifying the exact
167 + class of object that will be created. Factory Method is typically
168 + implemented by delegating the creation operation to the subclasses.
169 +
170 + Registers a creator with a type identifier. Looks up the type
171 + identifier in the internal map. If it is found, it invokes the
172 + corresponding creator for the type identifier and returns its
173 + result.
174 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
175 +  class IntegratorCreator;
176 +  class IntegratorFactory {
177 +    public:
178 +      typedef std::map<string, IntegratorCreator*> CreatorMapType;
179 +
180 +      bool registerIntegrator(IntegratorCreator* creator);
181 +
182 +      Integrator* createIntegrator(const string& id, SimInfo* info);
183 +
184 +    private:
185 +      CreatorMapType creatorMap_;
186 +  };
187 + \end{lstlisting}
188 +
189 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}]
190 +  bool IntegratorFactory::unregisterIntegrator(const string& id) {
191 +    return creatorMap_.erase(id) == 1;
192 +  }
193 +
194 +  Integrator*
195 +  IntegratorFactory::createIntegrator(const string& id, SimInfo* info) {
196 +    CreatorMapType::iterator i = creatorMap_.find(id);
197 +    if (i != creatorMap_.end()) {
198 +      //invoke functor to create object
199 +      return (i->second)->create(info);
200 +    } else {
201 +      return NULL;
202 +    }
203 +  }
204 + \end{lstlisting}
205 +
206 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (III)].},label={appendixScheme:integratorCreator}]
207 +
208 +  class IntegratorCreator {
209 +  public:
210 +    IntegratorCreator(const string& ident) : ident_(ident) {}
211 +
212 +    const string& getIdent() const { return ident_; }
213 +
214 +    virtual Integrator* create(SimInfo* info) const = 0;
215 +
216 +  private:
217 +    string ident_;
218 +  };
219 +
220 +  template<class ConcreteIntegrator>
221 +  class IntegratorBuilder : public IntegratorCreator {
222 +  public:
223 +    IntegratorBuilder(const string& ident) : IntegratorCreator(ident) {}
224 +    virtual  Integrator* create(SimInfo* info) const {
225 +      return new ConcreteIntegrator(info);
226 +    }
227 +  };
228 + \end{lstlisting}
229 +
230   \subsection{\label{appendixSection:visitorPattern}Visitor}
231 +
232   The purpose of the Visitor Pattern is to encapsulate an operation
233 < that you want to perform on the elements of a data structure. In
234 < this way, you can change the operation being performed on a
235 < structure without the need of changing the classes of the elements
236 < that you are operating on.
233 > that you want to perform on the elements. The operation being
234 > performed on a structure can be switched without changing the
235 > interfaces  of the elements. In other words, one can add virtual
236 > functions into a set of classes without modifying their interfaces.
237 > The UML class diagram of Visitor patten is shown in
238 > Fig.~\ref{appendixFig:visitorUML}. {\tt Dump2XYZ} program in
239 > Sec.~\ref{appendixSection:Dump2XYZ} uses Visitor pattern
240 > extensively.
241  
242 + \begin{figure}
243 + \centering
244 + \includegraphics[width=\linewidth]{architecture.eps}
245 + \caption[The architecture of {\sc OOPSE}] {Overview of the structure
246 + of {\sc OOPSE}} \label{appendixFig:visitorUML}
247 + \end{figure}
248 +
249 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
250 +  class BaseVisitor{
251 +    public:
252 +      virtual void visit(Atom* atom);
253 +      virtual void visit(DirectionalAtom* datom);
254 +      virtual void visit(RigidBody* rb);
255 +  };
256 + \end{lstlisting}
257 +
258 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
259 +  class StuntDouble {
260 +    public:
261 +      virtual void accept(BaseVisitor* v) = 0;
262 +  };
263 +
264 +  class Atom: public StuntDouble {
265 +    public:
266 +      virtual void accept{BaseVisitor* v*} {v->visit(this);}
267 +  };
268 +
269 +  class DirectionalAtom: public Atom {
270 +    public:
271 +      virtual void accept{BaseVisitor* v*} {v->visit(this);}
272 +  };
273 +
274 +  class RigidBody: public StuntDouble {
275 +    public:
276 +      virtual void accept{BaseVisitor* v*} {v->visit(this);}
277 +  };
278 +
279 + \end{lstlisting}
280   \section{\label{appendixSection:concepts}Concepts}
281  
282   OOPSE manipulates both traditional atoms as well as some objects
# Line 502 | Line 642 | Dump2XYZ can transform an OOPSE dump file into a xyz f
642  
643   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
644  
645 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
646 < be opened by other molecular dynamics viewers such as Jmol and
647 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
648 < follows:
645 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
646 > which can be opened by other molecular dynamics viewers such as Jmol
647 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
648 > as follows:
649  
650  
651   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 676 | The options available for Hydro are as follows:
676   \end{longtable}
677  
678   \subsection{\label{appendixSection:hydrodynamics}Hydro}
679 < The options available for Hydro are as follows:
679 >
680 > {\tt Hydro} can calculate resistance and diffusion tensors at the
681 > center of resistance. Both tensors at the center of diffusion can
682 > also be reported from the program, as well as the coordinates for
683 > the beads which are used to approximate the arbitrary shapes. The
684 > options available for Hydro are as follows:
685   \begin{longtable}[c]{|EFG|}
686   \caption{Hydrodynamics Command-line Options}
687   \\ \hline

Diff Legend

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