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 2821 by tim, Thu Jun 8 06:39:37 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 Singleton design pattern implementation(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}
164 < The Factory Method pattern is a creational pattern which deals with
165 < the problem of creating objects without specifying the exact class
166 < of object that will be created. Factory Method solves this problem
167 < by defining a separate method for creating the objects, which
168 < subclasses can then override to specify the derived type of product
169 < 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 > \begin{lstlisting}[float,caption={[].},label={appendixScheme:factoryDeclaration}]
170 >  class IntegratorCreator;
171 >  class IntegratorFactory {
172 >    public:
173 >      typedef std::map<std::string, IntegratorCreator*> CreatorMapType;
174 >
175 >      /**
176 >       * Registers a creator with a type identifier
177 >       * @return true if registration is successful, otherwise return false
178 >       * @id the identification of the concrete object
179 >       * @creator the object responsible to create the concrete object
180 >       */
181 >      bool registerIntegrator(IntegratorCreator* creator);
182 >
183 >      /**
184 >       * Looks up the type identifier in the internal map. If it is found, it invokes the
185 >       * 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);
191 >
192 >    private:
193 >      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;
200 >  }
201  
202 +  Integrator* IntegratorFactory::createIntegrator(const std::string& id, SimInfo* info) {
203 +    CreatorMapType::iterator i = creatorMap_.find(id);
204 +    if (i != creatorMap_.end()) {
205 +      //invoke functor to create object
206 +      return (i->second)->create(info);
207 +    } else {
208 +      return NULL;
209 +    }
210 +  }
211 + \end{lstlisting}
212 +
213 + \begin{lstlisting}[float,caption={[].},label={appendixScheme:integratorCreator}]
214 +
215 +  class IntegratorCreator {
216 +  public:
217 +    IntegratorCreator(const std::string& ident) : ident_(ident) {}
218 +    virtual ~IntegratorCreator() {}
219 +    const std::string& getIdent() const { return ident_; }
220 +
221 +    virtual Integrator* create(SimInfo* info) const = 0;
222 +
223 +  private:
224 +    std::string ident_;
225 +  };
226 +
227 +  template<class ConcreteIntegrator>
228 +  class IntegratorBuilder : public IntegratorCreator {
229 +  public:
230 +    IntegratorBuilder(const std::string& ident) : IntegratorCreator(ident) {}
231 +    virtual  Integrator* create(SimInfo* info) const {return new ConcreteIntegrator(info);}
232 +  };
233 + \end{lstlisting}
234 +
235   \subsection{\label{appendixSection:visitorPattern}Visitor}
236 +
237   The purpose of the Visitor Pattern is to encapsulate an operation
238   that you want to perform on the elements of a data structure. In
239   this way, you can change the operation being performed on a
240 < structure without the need of changing the classes of the elements
241 < that you are operating on.
240 > structure without the need of changing the class heirarchy of the
241 > elements that you are operating on.
242  
243 + \begin{lstlisting}[float,caption={[].},label={appendixScheme:visitor}]
244 +  class BaseVisitor{
245 +    public:
246 +      virtual void visit(Atom* atom);
247 +      virtual void visit(DirectionalAtom* datom);
248 +      virtual void visit(RigidBody* rb);
249 +  };
250 + \end{lstlisting}
251 + \begin{lstlisting}[float,caption={[].},label={appendixScheme:element}]
252 +  class StuntDouble {
253 +    public:
254 +      virtual void accept(BaseVisitor* v) = 0;
255 +  };
256 +
257 +  class Atom: public StuntDouble {
258 +    public:
259 +      virtual void accept{BaseVisitor* v*} {v->visit(this);}
260 +  };
261 +
262 +  class DirectionalAtom: public Atom {
263 +    public:
264 +      virtual void accept{BaseVisitor* v*} {v->visit(this);}
265 +  };
266 +
267 +  class RigidBody: public StuntDouble {
268 +    public:
269 +      virtual void accept{BaseVisitor* v*} {v->visit(this);}
270 +  };
271 +
272 + \end{lstlisting}
273   \section{\label{appendixSection:concepts}Concepts}
274  
275   OOPSE manipulates both traditional atoms as well as some objects
# Line 502 | Line 635 | Dump2XYZ can transform an OOPSE dump file into a xyz f
635  
636   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
637  
638 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
639 < be opened by other molecular dynamics viewers such as Jmol and
640 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
641 < follows:
638 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
639 > which can be opened by other molecular dynamics viewers such as Jmol
640 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
641 > as follows:
642  
643  
644   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 669 | The options available for Hydro are as follows:
669   \end{longtable}
670  
671   \subsection{\label{appendixSection:hydrodynamics}Hydro}
672 < The options available for Hydro are as follows:
672 >
673 > {\tt Hydro} can calculate resistance and diffusion tensors at the
674 > center of resistance. Both tensors at the center of diffusion can
675 > also be reported from the program, as well as the coordinates for
676 > the beads which are used to approximate the arbitrary shapes. The
677 > options available for Hydro are as follows:
678   \begin{longtable}[c]{|EFG|}
679   \caption{Hydrodynamics Command-line Options}
680   \\ \hline

Diff Legend

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