wip on state pattern

This commit is contained in:
Claudio Maggioni 2022-10-19 14:33:44 +02:00
parent 69017acbb5
commit cd44440bbf
3 changed files with 40 additions and 27 deletions

Binary file not shown.

Binary file not shown.

View file

@ -46,7 +46,7 @@
\pagenumbering{arabic} \pagenumbering{arabic}
We need to find a project that is a single unit in terms of compilation We need to find a project that is a single unit in terms of compilation
modules\footnote{A problem for Pattern4J as compiled \texttt{.class} files are modules\footnote{A problem for Pattern4J as compiled \textit{.class} files are
distributed across several directories and would have to be merged manually for distributed across several directories and would have to be merged manually for
analyzing them} analyzing them}
self contained and with as little external dependencies as possible to ease the self contained and with as little external dependencies as possible to ease the
@ -71,11 +71,11 @@ We considered the following GitHub repositories:
\subsection {The Jackson Core Library} \subsection {The Jackson Core Library}
As already mentioned, \texttt{Jackson} is a library that offers serialization As already mentioned, \textit{Jackson} is a library that offers serialization
and deseralization capabilities in JSON format. The library is highly extensible and deseralization capabilities in JSON format. The library is highly extensible
and customizable through a robust but flexible API and module suite that allows and customizable through a robust but flexible API and module suite that allows
to change the serialization and deserialization rules, or in the case of the to change the serialization and deserialization rules, or in the case of the
\texttt{jackson-dataformat-xml} module, to allow to target XML instead of JSON. \textit{jackson-dataformat-xml} module, to allow to target XML instead of JSON.
The chosen repository contains only the \textit{core} module of Jackson. The The chosen repository contains only the \textit{core} module of Jackson. The
\textit{core} module implements the necessary library abstractions and \textit{core} module implements the necessary library abstractions and
@ -84,22 +84,22 @@ interfaces to allow other modules to be plugged-in. Additionally, the
with the JSON format. with the JSON format.
We chose to analyze version 2.13.4 of the module (i.e.\ the code We chose to analyze version 2.13.4 of the module (i.e.\ the code
under the git tag \texttt{jackson-core-2.13.4}) because it is the latest stable under the git tag \textit{jackson-core-2.13.4}) because it is the latest stable
version available at the time of writing. version available at the time of writing.
\section{Analysis Implementation} \section{Analysis Implementation}
We use We use
\href{https://users.encs.concordia.ca/~nikolaos/pattern\_detection.html}{\textit{Pattern4}} \href{https://users.encs.concordia.ca/~nikolaos/pattern\_detection.html}{\textit{Pattern4J}}
as a pattern detection tool. This tool needs compiled \texttt{.class} files in as a pattern detection tool. This tool needs compiled \textit{.class} files in
order to perform analysis. Therefore, as \texttt{jackson-core} is a standard order to perform analysis. Therefore, as \textit{jackson-core} is a standard
Maven project, we compile the sources using the command \texttt{mvn clean Maven project, we compile the sources using the command \textit{mvn clean
compile}. The \texttt{pom.xml} of the library specifies Java 1.6 as a compile}. The \textit{pom.xml} of the library specifies Java 1.6 as a
compilation target, which is not supported by JDK 17 or above. We used JDK 11 compilation target, which is not supported by JDK 17 or above. We used JDK 11
instead, as it is the previous LTS version. instead, as it is the previous LTS version.
An XML dump of the \textit{Pattern4j} analysis results are included in the An XML dump of the \textit{Pattern4j} analysis results are included in the
submission as the file \texttt{analysis.xml}. submission as the file \textit{analysis.xml}.
\section{Structural Patterns} \section{Structural Patterns}
@ -128,7 +128,7 @@ initialized by client code.
\end{description} \end{description}
\subsection{Abstract Factory Pattern} \subsection{Abstract Factory Pattern}
\textit{Pattern4} detects only two instances of the abstract factory pattern: \textit{Pattern4J} detects only two instances of the abstract factory pattern:
\begin{description} \begin{description}
\item[TokenStreamFactory] which indeed is a factory for \textbf{JsonParser} and \item[TokenStreamFactory] which indeed is a factory for \textbf{JsonParser} and
@ -137,11 +137,11 @@ initialized by client code.
arguments. A concrete implementation of this factory is included in the form arguments. A concrete implementation of this factory is included in the form
of the \textbf{JsonFactory} class, although other modules may add additional of the \textbf{JsonFactory} class, although other modules may add additional
implementations to cater for different encodings (like the implementations to cater for different encodings (like the
\texttt{jackson-dataformat-xml} module for XML); \textit{jackson-dataformat-xml} module for XML);
\item[TSFBuilder] which is also a factory for concrete implementations of \item[TSFBuilder] which is also a factory for concrete implementations of
\textbf{TokenStreamFactory} to allow slight changes in the serialization and \textbf{TokenStreamFactory} to allow slight changes in the serialization and
deserialization rules (e.g. changing the quote character used in JSON keys deserialization rules (e.g. changing the quote character used in JSON keys
from \texttt{"} to \texttt{'}). Like \textbf{TokenStreamFactory}, this class from \textit{"} to \textit{'}). Like \textbf{TokenStreamFactory}, this class
is only implemented by one class, namely \textbf{JsonFactoryBuilder}, whitin is only implemented by one class, namely \textbf{JsonFactoryBuilder}, whitin
the scope of this module. And as mentioned previously, this abstract factory the scope of this module. And as mentioned previously, this abstract factory
is also likely to be extended by concrete implementations in other is also likely to be extended by concrete implementations in other
@ -151,7 +151,7 @@ initialized by client code.
\subsection{Builder Pattern} \subsection{Builder Pattern}
The builder pattern does not seem to be analyzed by The builder pattern does not seem to be analyzed by
\textit{Pattern4}, as the analysis output does not mention the pattern, even \textit{Pattern4J}, as the analysis output does not mention the pattern, even
just to report that no instances of it have been found (as it is the case with just to report that no instances of it have been found (as it is the case with
other patterns, e.g. the observer pattern). A manual search in the source code other patterns, e.g. the observer pattern). A manual search in the source code
produced the following results: produced the following results:
@ -161,16 +161,16 @@ produced the following results:
previously, this class allows to alter slightly the serialization and previously, this class allows to alter slightly the serialization and
deserialization rules used to build outputtting \textbf{JsonFactory} deserialization rules used to build outputtting \textbf{JsonFactory}
objects. Each rule is represented by an object or enum instance implementing objects. Each rule is represented by an object or enum instance implementing
the \textbf{util.JacksonFeature} interface. \texttt{TSFBuilder} then the \textbf{util.JacksonFeature} interface. \textit{TSFBuilder} then
provides several overloaded methods to enable and disable features provides several overloaded methods to enable and disable features
represented by the interface. Enabled features are stored in several represented by the interface. Enabled features are stored in several
bitmask \texttt{protected int} fields, which are then directly accessed by bitmask \textit{protected int} fields, which are then directly accessed by
the constructor of the \textbf{TokenStreamFactory} concrete implementation the constructor of the \textbf{TokenStreamFactory} concrete implementation
to build; to build;
\marginpar[right text]{\color{white}\url{https://youtu.be/72b2nH-kdbU}} \marginpar[right text]{\color{white}\url{https://youtu.be/72b2nH-kdbU}}
\item[JsonFactoryBuilder] an concrete factory implementation of \item[JsonFactoryBuilder] an concrete factory implementation of
\textbf{TSFBuilder} that builds \textbf{JsonFactory} instances; \textbf{TSFBuilder} that builds \textbf{JsonFactory} instances;
\item[util.ByteArrayBuilder] provides facilities to build \texttt{byte[]} objects \item[util.ByteArrayBuilder] provides facilities to build \textit{byte[]} objects
of varying length, akin to \textbf{StringBuilder} building \textbf{String} of varying length, akin to \textbf{StringBuilder} building \textbf{String}
objects. This is not a strict implementation of the builder pattern per se objects. This is not a strict implementation of the builder pattern per se
(as Java arrays do not have a ``real'' constructor), (as Java arrays do not have a ``real'' constructor),
@ -194,7 +194,7 @@ TBD
None found None found
\subsection{Facade Pattern} \subsection{Facade Pattern}
TBD -- \textit{Pattern4} does not detect this pattern TBD -- \textit{Pattern4J} does not detect this pattern
\subsection{Proxy Pattern} \subsection{Proxy Pattern}
None found None found
@ -210,33 +210,46 @@ None found
None found None found
\subsection{State Pattern} \subsection{State Pattern}
Among the design patterns \textit{Pattern4} detects, the state pattern is Among the design patterns \textit{Pattern4J} detects, the state pattern is
detected in 5 classes. The state pattern is a variation of the strategy pattern detected in 5 classes. The state pattern is a variation of the strategy pattern
where the concrete strategy used by the matching context is determined by the where the concrete strategy used by the matching context is determined by the
state of a finite state machine the context class implements. In other words, state of a finite state machine the context class implements. In other words,
the state pattern chooses the concrete strategy to use through the state of the the state pattern chooses the concrete strategy to use through the state of the
context. context.
util.DefaultPrettyPrinter delegate pattern maybe, but no state \begin{description}
\item[util.DefaultPrettyPrinter] false positive, strategy pattern;
\item[JsonFactory] false positive, \textit{InputDecorator \_inputDecorator},
\textit{OutputDecorator \_outputDecorator}, \textit{SerializedString
\_rootValueSeparator} are strategy instances (more
specifically a way to pre-process input before Jackson parses it, labeled as
``decorator'' by Jackson developers but not really a decorator pattern
application since InputDecorator is not a subclass of any component to
decorate);
\item[json.WriterBasedJsonGenerator] false positive,
\textit{SerializableString \_currentEscape} is a simple \textit{String}-like
object that gets updated based on the parsing state.
\item[util.DefaultPrettyPrinter] ??? WIP
\end{description}
TBD instances and examples WIP instances and examples
\subsection{Template Method Pattern} \subsection{Template Method Pattern}
Due to the extendibility of Jackson, it is of no surprise that the template Due to the extendibility of Jackson, it is of no surprise that the template
method pattern is used extensively to create a class hierarchy that provides method pattern is used extensively to create a class hierarchy that provides
rich interfaces while maintaining behavioural flexibility. \textit{Pattern4} rich interfaces while maintaining behavioural flexibility. \textit{Pattern4J}
correctly detects several instances of the pattern, namely correctly detects several instances of the pattern, namely
\textbf{JsonStreamContext}, \textbf{JsonGenerator}, \textbf{type.ResolvedType}, \textbf{JsonStreamContext}, \textbf{JsonGenerator}, \textbf{type.ResolvedType},
\textbf{JsonParser}, \textbf{base.ParserBase}, \textbf{base.GeneratorBase}, \textbf{JsonParser}, \textbf{base.ParserBase}, \textbf{base.GeneratorBase},
\textbf{base.ParserMinimalBase}. All these classes implement several concrete \textbf{base.ParserMinimalBase}. All these classes implement several concrete
\texttt{public} methods throwgh the use of \texttt{protected abstract} methods. \textit{public} methods throwgh the use of \textit{protected abstract} methods.
Although the concrete (i.e.\ the template) methods are usually not vary complex Although the concrete (i.e.\ the template) methods are usually not vary complex
(as the pattern example shown in class), they still follow the principles of the (as the pattern example shown in class), they still follow the principles of the
template method pattern. We show as an example some template methods found in template method pattern. We show as an example some template methods found in
\textbf{base.ParserBase}: \textbf{base.ParserBase}:
\begin{lstlisting}[caption=Template method \texttt{void close()} and step \begin{lstlisting}[caption=Template method \textit{void close()} and step
methods \texttt{void \_closeInput()} and \texttt{void \_releaseBuffers()} in methods \textit{void \_closeInput()} and \textit{void \_releaseBuffers()} in
\textbf{base.ParserBase}., language=java] \textbf{base.ParserBase}., language=java]
@Override public void close() throws IOException { @Override public void close() throws IOException {
if (!_closed) { if (!_closed) {
@ -262,8 +275,8 @@ protected void _releaseBuffers() throws IOException {
\end{lstlisting} \end{lstlisting}
Here the pattern is slightly modified by providing a default implementation of Here the pattern is slightly modified by providing a default implementation of
\texttt{void \_releaseBuffers()}. In this case, child classes occasionally \textit{void \_releaseBuffers()}. In this case, child classes occasionally
override the method with a body first calling \texttt{super()} and then adding override the method with a body first calling \textit{super()} and then adding
additional buffer release code after. additional buffer release code after.
\subsection{Visitor Pattern} \subsection{Visitor Pattern}