diff --git a/Assignment01-design_patterns.pdf b/Assignment01-design_patterns.pdf new file mode 100644 index 0000000..187ebf0 Binary files /dev/null and b/Assignment01-design_patterns.pdf differ diff --git a/report.pdf b/report.pdf index 4d947dd..291e7d1 100644 Binary files a/report.pdf and b/report.pdf differ diff --git a/report.tex b/report.tex index 971276e..e4f5972 100644 --- a/report.tex +++ b/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}