105 |
|
static data approach in {\sc OOPSE}. The declaration and |
106 |
|
implementation of IntegratorFactory class are given by declared in |
107 |
|
List.~\ref{appendixScheme:singletonDeclaration} and |
108 |
< |
List.~\ref{appendixScheme:singletonImplementation} respectively. |
108 |
> |
Scheme.~\ref{appendixScheme:singletonImplementation} respectively. |
109 |
|
Since constructor is declared as protected, a client can not |
110 |
|
instantiate IntegratorFactory directly. Moreover, since the member |
111 |
|
function getInstance serves as the only entry of access to |
149 |
|
implemented by delegating the creation operation to the subclasses. |
150 |
|
Parameterized Factory pattern where factory method ( |
151 |
|
createIntegrator member function) creates products based on the |
152 |
< |
identifier (see List.~\ref{appendixScheme:factoryDeclaration}). If |
152 |
> |
identifier (see Scheme.~\ref{appendixScheme:factoryDeclaration}). If |
153 |
|
the identifier has been already registered, the factory method will |
154 |
|
invoke the corresponding creator (see |
155 |
< |
List.~\ref{appendixScheme:integratorCreator}) which utilizes the |
155 |
> |
Scheme.~\ref{appendixScheme:integratorCreator}) which utilizes the |
156 |
|
modern C++ template technique to avoid excess subclassing. |
157 |
|
|
158 |
|
\begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}] |
215 |
|
Dump2XYZ}. In order to convert an OOPSE dump file, a series of |
216 |
|
distinct operations are performed on different StuntDoubles (See the |
217 |
|
class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration |
218 |
< |
in List.~\ref{appendixScheme:element}). Since the hierarchies |
218 |
> |
in Scheme.~\ref{appendixScheme:element}). Since the hierarchies |
219 |
|
remains stable, it is easy to define a visit operation (see |
220 |
< |
List.~\ref{appendixScheme:visitor}) for each class of StuntDouble. |
220 |
> |
Scheme.~\ref{appendixScheme:visitor}) for each class of StuntDouble. |
221 |
|
Note that using Composite pattern\cite{Gamma1994}, CompositVisitor |
222 |
|
manages a priority visitor list and handles the execution of every |
223 |
|
visitor in the priority list on different StuntDoubles. |
277 |
|
virtual void visit(RigidBody* rb); |
278 |
|
}; |
279 |
|
|
280 |
– |
class SSDAtomVisitor:public BaseAtomVisitor{ public: |
281 |
– |
virtual void visit(Atom* atom); |
282 |
– |
virtual void visit(DirectionalAtom* datom); |
283 |
– |
virtual void visit(RigidBody* rb); |
284 |
– |
}; |
285 |
– |
|
280 |
|
class CompositeVisitor: public BaseVisitor { |
281 |
|
public: |
282 |
|
|
285 |
|
virtual void visit(Atom* atom) { |
286 |
|
VisitorListIterator i; |
287 |
|
BaseVisitor* curVisitor; |
288 |
< |
for(i = visitorList.begin();i != visitorList.end();++i) { |
288 |
> |
for(i = visitorScheme.begin();i != visitorScheme.end();++i) { |
289 |
|
atom->accept(*i); |
290 |
|
} |
291 |
|
} |
293 |
|
virtual void visit(DirectionalAtom* datom) { |
294 |
|
VisitorListIterator i; |
295 |
|
BaseVisitor* curVisitor; |
296 |
< |
for(i = visitorList.begin();i != visitorList.end();++i) { |
296 |
> |
for(i = visitorScheme.begin();i != visitorScheme.end();++i) { |
297 |
|
atom->accept(*i); |
298 |
|
} |
299 |
|
} |
303 |
|
std::vector<Atom*> myAtoms; |
304 |
|
std::vector<Atom*>::iterator ai; |
305 |
|
myAtoms = rb->getAtoms(); |
306 |
< |
for(i = visitorList.begin();i != visitorList.end();++i) {{ |
306 |
> |
for(i = visitorScheme.begin();i != visitorScheme.end();++i) {{ |
307 |
|
rb->accept(*i); |
308 |
|
for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){ |
309 |
|
(*ai)->accept(*i); |
315 |
|
protected: |
316 |
|
VistorListType visitorList; |
317 |
|
}; |
324 |
– |
|
318 |
|
\end{lstlisting} |
319 |
|
|
320 |
|
\section{\label{appendixSection:concepts}Concepts} |