| 1 |
|
\chapter{\label{chapt:appendix}APPENDIX} |
| 2 |
|
|
| 3 |
+ |
Designing object-oriented software is hard, and designing reusable |
| 4 |
+ |
object-oriented scientific software is even harder. Absence of |
| 5 |
+ |
applying modern software development practices is the bottleneck of |
| 6 |
+ |
Scientific Computing community\cite{wilson}. For instance, in the |
| 7 |
+ |
last 20 years , there are quite a few MD packages that were |
| 8 |
+ |
developed to solve common MD problems and perform robust simulations |
| 9 |
+ |
. However, many of the codes are legacy programs that are either |
| 10 |
+ |
poorly organized or extremely complex. Usually, these packages were |
| 11 |
+ |
contributed by scientists without official computer science |
| 12 |
+ |
training. The development of most MD applications are lack of strong |
| 13 |
+ |
coordination to enforce design and programming guidelines. Moreover, |
| 14 |
+ |
most MD programs also suffer from missing design and implement |
| 15 |
+ |
documents which is crucial to the maintenance and extensibility. |
| 16 |
+ |
|
| 17 |
|
\section{\label{appendixSection:desginPattern}Design Pattern} |
| 18 |
|
|
| 19 |
+ |
Design patterns are optimal solutions to commonly-occurring problems |
| 20 |
+ |
in software design. Although originated as an architectural concept |
| 21 |
+ |
for buildings and towns by Christopher Alexander \cite{alexander}, |
| 22 |
+ |
software patterns first became popular with the wide acceptance of |
| 23 |
+ |
the book, Design Patterns: Elements of Reusable Object-Oriented |
| 24 |
+ |
Software \cite{gamma94}. Patterns reflect the experience, knowledge |
| 25 |
+ |
and insights of developers who have successfully used these patterns |
| 26 |
+ |
in their own work. Patterns are reusable. They provide a ready-made |
| 27 |
+ |
solution that can be adapted to different problems as necessary. |
| 28 |
+ |
Pattern are expressive. they provide a common vocabulary of |
| 29 |
+ |
solutions that can express large solutions succinctly. |
| 30 |
|
|
| 31 |
< |
\subsection{\label{appendixSection:visitorPattern}Visitor Pattern} |
| 31 |
> |
Patterns are usually described using a format that includes the |
| 32 |
> |
following information: |
| 33 |
> |
\begin{enumerate} |
| 34 |
> |
\item The \emph{name} that is commonly used for the pattern. Good pattern names form a vocabulary for |
| 35 |
> |
discussing conceptual abstractions. a pattern may have more than one commonly used or recognizable name |
| 36 |
> |
in the literature. In this case it is common practice to document these nicknames or synonyms under |
| 37 |
> |
the heading of \emph{Aliases} or \emph{Also Known As}. |
| 38 |
> |
\item The \emph{motivation} or \emph{context} that this pattern applies |
| 39 |
> |
to. Sometimes, it will include some prerequisites that should be satisfied before deciding to use a pattern |
| 40 |
> |
\item The \emph{solution} to the problem that the pattern |
| 41 |
> |
addresses. It describes how to construct the necessary work products. The description may include |
| 42 |
> |
pictures, diagrams and prose which identify the pattern's structure, its participants, and their |
| 43 |
> |
collaborations, to show how the problem is solved. |
| 44 |
> |
\item The \emph{consequences} of using the given solution to solve a |
| 45 |
> |
problem, both positive and negative. |
| 46 |
> |
\end{enumerate} |
| 47 |
|
|
| 48 |
< |
\subsection{\label{appendixSection:templatePattern}Template Pattern} |
| 48 |
> |
As one of the latest advanced techniques emerged from |
| 49 |
> |
object-oriented community, design patterns were applied in some of |
| 50 |
> |
the modern scientific software applications, such as JMol, OOPSE |
| 51 |
> |
\cite{Meineke05} and PROTOMOL \cite{Matthey05} \textit{etc}. |
| 52 |
|
|
| 53 |
< |
\subsection{\label{appendixSection:factoryPattern}Factory Pattern} |
| 53 |
> |
\subsection{\label{appendixSection:singleton}Singleton} |
| 54 |
> |
The Singleton pattern ensures that only one instance of a class is |
| 55 |
> |
created. All objects that use an instance of that class use the same |
| 56 |
> |
instance. |
| 57 |
|
|
| 58 |
< |
\section{\label{appendixSection:hierarchy}Hierarchy} |
| 58 |
> |
\subsection{\label{appendixSection:factoryMethod}Factory Method} |
| 59 |
> |
The Factory Method pattern is a creational pattern which deals with |
| 60 |
> |
the problem of creating objects without specifying the exact class |
| 61 |
> |
of object that will be created. Factory Method solves this problem |
| 62 |
> |
by defining a separate method for creating the objects, which |
| 63 |
> |
subclasses can then override to specify the derived type of product |
| 64 |
> |
that will be created. |
| 65 |
|
|
| 14 |
– |
\section{\label{appendixSection:selectionSyntax}Selection Syntax} |
| 66 |
|
|
| 67 |
< |
\section{\label{appendixSection:hydrodynamics}Hydrodynamics} |
| 67 |
> |
\subsection{\label{appendixSection:visitorPattern}Visitor} |
| 68 |
> |
The purpose of the Visitor Pattern is to encapsulate an operation |
| 69 |
> |
that you want to perform on the elements of a data structure. In |
| 70 |
> |
this way, you can change the operation being performed on a |
| 71 |
> |
structure without the need of changing the classes of the elements |
| 72 |
> |
that you are operating on. |
| 73 |
|
|
| 74 |
+ |
|
| 75 |
+ |
\subsection{\label{appendixSection:templateMethod}Template Method} |
| 76 |
+ |
|
| 77 |
|
\section{\label{appendixSection:analysisFramework}Analysis Framework} |
| 78 |
|
|
| 79 |
< |
\subsection{\label{appendixSection:staticProps}Factory Properties} |
| 79 |
> |
\section{\label{appendixSection:hierarchy}Hierarchy} |
| 80 |
|
|
| 81 |
+ |
\subsection{\label{appendixSection:selectionSyntax}Selection Syntax} |
| 82 |
+ |
|
| 83 |
+ |
\subsection{\label{appendixSection:hydrodynamics}Hydrodynamics} |
| 84 |
+ |
|
| 85 |
+ |
\subsection{\label{appendixSection:staticProps}Static Properties} |
| 86 |
+ |
|
| 87 |
|
\subsection{\label{appendixSection:dynamicProps}Dynamics Properties} |
