decorator patter
This commit is contained in:
parent
30982cdf76
commit
fddbf895ca
2 changed files with 56 additions and 8 deletions
BIN
report.pdf
BIN
report.pdf
Binary file not shown.
62
report.tex
62
report.tex
|
@ -465,7 +465,7 @@ pattern). A manual search in the source code produced the following results:
|
|||
|
||||
\textit{Pattern4J} found many instances of the adapter pattern, however all but
|
||||
one were shown to be false positives by checking the documentation and the code
|
||||
using each allegied adaptee. The matches found are reported and commented
|
||||
using each alleged adaptee. The matches found are reported and commented
|
||||
below. Matches are shown in the \textit{[Adapter] $\leftarrow$ [Adaptee]}
|
||||
format.
|
||||
|
||||
|
@ -497,16 +497,64 @@ format.
|
|||
\end{description}
|
||||
|
||||
\subsection{TBD Decorator Pattern}
|
||||
Decorator pattern lets you dynamically change the behavior of an object at run
|
||||
Decorator pattern lets you dynamically change the behaviour of an object at run
|
||||
time by wrapping them in an object of a decorator class.
|
||||
\textit{Pattern4J} found two instances of the decorator patter,
|
||||
however we are probably in a case of ambiguity because in the documentation of the \textbf{util.JsonParserDelegate}
|
||||
is stated that the patter used is a delegation pattern.
|
||||
\begin{lstlisting}[language=java,label={lst:jsonparserdelegate}, caption={}]
|
||||
/**
|
||||
* Helper class that implements
|
||||
* <a href="http://en.wikipedia.org/wiki/Delegation_pattern">delegation pattern</a>
|
||||
* for {@link JsonParser},
|
||||
* to allow for simple overridability of basic parsing functionality.
|
||||
* The idea is that any functionality to be modified can be simply
|
||||
* overridden; and anything else will be delegated by default.
|
||||
*/
|
||||
\end{lstlisting}
|
||||
The decorator patter is similar to the delegation patter and the delegation patter is similar to the proxy patter,
|
||||
in-fact the delegation patter is also known as ''proxy chains``.
|
||||
We have a mismatch in this case because the decorato pattern uses a lot the delegation pattern to accomplish its task,
|
||||
so thats why we have a misclassification signalling the decorator pattern and not the proxy patter.
|
||||
|
||||
\begin{description}
|
||||
\item[JsonGenerator]
|
||||
TBD
|
||||
\item[JsonParser]
|
||||
TBD
|
||||
\item[util.JsonParserDelegate]
|
||||
is clearly a false positive because the developer stated explicitly the design patter used for the class.
|
||||
This class extends the \textbf{JsonParser} and fully implements the delegation patter.
|
||||
\item[util.JsonGeneratorDelegate]
|
||||
there is no clear statement by the developer if the used designed pattern is different from the one detected by the tool,
|
||||
but we can make an assumption by looking on the authors contribution to the file.
|
||||
\begin{lstlisting}[language=bash, caption={Display the number of commits on a file and sort it by the number of commits.},label=lst:gitcommand]
|
||||
git shortlog -n -s -- $filename$
|
||||
\end{lstlisting}
|
||||
Using the command presente in Listing \ref{lst:gitcommand} we can see the number of authors of a single file
|
||||
and the result is sorted by the number of commits.
|
||||
By running the command on \textbf{util.JsonParserDelegate} and \textbf{util.JsonGeneratorDelegate} we can clearly see that the top contributor to the file is the same for both the classes, the out-put of the command are presented for the classes in Listing \ref{lst:gitcommandparser} and Listing \ref{lst:gitcommandgenerator}.
|
||||
\begin{lstlisting}[caption={Command of Listing \ref{lst:gitcommand} executed on util.JsonParserDelegate class},label=lst:gitcommandparser]
|
||||
git shortlog -n -s -- JsonParserDelegate.java
|
||||
33 Tatu Saloranta
|
||||
3 Tatu
|
||||
1 Andrey Somov
|
||||
1 LokeshN
|
||||
\end{lstlisting}
|
||||
\begin{lstlisting}[caption={Command of Listing \ref{lst:gitcommand} executed on util.JsonGeneratorDelegate class}, label=lst:gitcommandgenerator]
|
||||
git shortlog -n -s -- JsonGeneratorDelegate.java
|
||||
38 Tatu Saloranta
|
||||
2 Cowtowncoder
|
||||
1 Andrey Somov
|
||||
1 Logan Widick
|
||||
1 Martin Steiger
|
||||
1 Oleksandr Poslavskyi
|
||||
1 Q.P.Liu
|
||||
1 Volkan Yaz${\i}$c${\i}$
|
||||
\end{lstlisting}
|
||||
Is more an empirical assumption, we can do a deeper analysis looking at the statistics of modified lines,
|
||||
but in general the structure of the \textbf{util.JsonGeneratorDelegate} is very similar to the one in \textbf{util.JsonParserDelegate},
|
||||
so is more probable that is a false positive.
|
||||
This class extend the \textbf{JsonGenerator} class and it is implementing the delegate patter with a modification.
|
||||
In the constructor of the class we have a boolean parameter \textit{delegateCopyMethods},
|
||||
it is used in \textbf{writeObject, writeTree, copyCurrentEvent, copyCurrentStructure} methods to signal if delegate the function call to the delegator or to the super class.
|
||||
\end{description}
|
||||
Only in Pattern4J
|
||||
|
||||
\subsection{TBD Bridge Pattern}
|
||||
TBD
|
||||
|
|
Reference in a new issue