wip on state pattern

report.tex

@@ -46,7 +46,7 @@
 \pagenumbering{arabic}
 
 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
 analyzing them}
 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}
-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 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
-\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
 \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.
 
 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.
 
 \section{Analysis Implementation}
 
 We use
-\href{https://users.encs.concordia.ca/~nikolaos/pattern\_detection.html}{\textit{Pattern4}}
-as a pattern detection tool. This tool needs compiled \texttt{.class} files in
-order to perform analysis. Therefore, as \texttt{jackson-core} is a standard
-Maven project, we compile the sources using the command \texttt{mvn clean
-compile}. The \texttt{pom.xml} of the library specifies Java 1.6 as a
+\href{https://users.encs.concordia.ca/~nikolaos/pattern\_detection.html}{\textit{Pattern4J}}
+as a pattern detection tool. This tool needs compiled \textit{.class} files in
+order to perform analysis. Therefore, as \textit{jackson-core} is a standard
+Maven project, we compile the sources using the command \textit{mvn clean
+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
 instead, as it is the previous LTS version.
 
 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}
 
@@ -128,7 +128,7 @@ initialized by client code.
 \end{description}
 
 \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}
 \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
   of the \textbf{JsonFactory} class, although other modules may add additional
   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
   \textbf{TokenStreamFactory} to allow slight changes in the serialization and
     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
     the scope of this module. And as mentioned previously, this abstract factory
     is also likely to be extended by concrete implementations in other
@@ -151,7 +151,7 @@ initialized by client code.
 \subsection{Builder Pattern}
 
 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
 other patterns, e.g. the observer pattern). A manual search in the source code
 produced the following results:
@@ -161,16 +161,16 @@ produced the following results:
   previously, this class allows to alter slightly the serialization and
     deserialization rules used to build outputtting \textbf{JsonFactory}
     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
     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
     to build;
     \marginpar[right text]{\color{white}\url{https://youtu.be/72b2nH-kdbU}}
 \item[JsonFactoryBuilder] an concrete factory implementation of 
   \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}
     objects. This is not a strict implementation of the builder pattern per se
     (as Java arrays do not have a ``real'' constructor),
@@ -194,7 +194,7 @@ TBD
 None found
 
 \subsection{Facade Pattern}
-TBD -- \textit{Pattern4} does not detect this pattern
+TBD -- \textit{Pattern4J} does not detect this pattern
 
 \subsection{Proxy Pattern}
 None found
@@ -210,33 +210,46 @@ None found
 None found
 
 \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
 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,
 the state pattern chooses the concrete strategy to use through the state of the
 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}
 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
-rich interfaces while maintaining behavioural flexibility.  \textit{Pattern4}
+rich interfaces while maintaining behavioural flexibility.  \textit{Pattern4J}
 correctly detects several instances of the pattern, namely
 \textbf{JsonStreamContext}, \textbf{JsonGenerator}, \textbf{type.ResolvedType},
 \textbf{JsonParser}, \textbf{base.ParserBase}, \textbf{base.GeneratorBase},
 \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
 (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
 \textbf{base.ParserBase}:
 
-\begin{lstlisting}[caption=Template method \texttt{void close()} and step
-methods \texttt{void \_closeInput()} and \texttt{void \_releaseBuffers()} in
+\begin{lstlisting}[caption=Template method \textit{void close()} and step
+methods \textit{void \_closeInput()} and \textit{void \_releaseBuffers()} in
 \textbf{base.ParserBase}., language=java]
 @Override public void close() throws IOException {
     if (!_closed) {
@@ -262,8 +275,8 @@ protected void _releaseBuffers() throws IOException {
 \end{lstlisting}
 
 Here the pattern is slightly modified by providing a default implementation of
-\texttt{void \_releaseBuffers()}. In this case, child classes occasionally
-override the method with a body first calling \texttt{super()} and then adding
+\textit{void \_releaseBuffers()}. In this case, child classes occasionally
+override the method with a body first calling \textit{super()} and then adding
 additional buffer release code after.
 
 \subsection{Visitor Pattern}