1. Introduction
Life has been so much easier
since Science invented Magic.
— Marge Simpson

In this thesis, we evaluate software design patterns from a programming language and practical point of view in an Object—Oriented (OO) environment. We investigate how language paradigms in Java 6 [Gosling05] affect the application of all the "Gang of Four" (GoF) [Gamma95] design patterns. The investigation focuses on how the practical use, not the construction, of language features can affect the design pattern implementations. This chapter presents the motivation for undertaking this project, as well as the goals we want to achieve. We outline the work performed during this thesis, both theoretical and practical, and we conclude this introductory chapter with an extensive summary of the content presented in this thesis.

1.1.  Motivation
Designing and developing complex software systems is not, and has never been, an easy task. On the contrary, the process is often very time consuming and requires interaction between many different people, skills, and roles, internally and externally. Many, often contradictory, factors must be addressed in the design process and at different levels, such as the need for maintainability versus quick delivery, flexibility versus speed, etc. The domain may offer tools, notations, principles, and methods to guide the development process, but they cannot shield against bad design decisions made by humans, and they may not even be standardised. For example, there is a lack of consensus on how to approach OO development, and several OO methods exist, each offering their take on how to design OO systems. The Unified Modelling Language (UML) [UML05] is commonly used to model the design, words like "class" and "object" denote commonly accepted concepts, and Gamma et al. suggest favouring object composition over inheritance [Gamma95, p.20]. However, this modus operandi is by no means a guarantee for good and durable designs. Experience helps, but careful decisions and meticulous work are always required. Therefore, and worst of all, the entire process tends to be error prone, not forgetting costly. The larger and more complex the system is, the worse these factors seem to become at an escalating rate.

Even the most complex systems are built by using smaller "parts", influencing the overall design directly or indirectly. A part can be anything from an entire sub—system to a specific component, native to the language or otherwise, that requires the need for a specific design. Such parts may in turn be built using even smaller parts and so forth and need to communicate to function as a whole. The key to any viable design is to identify the relevant parts, their functionality, and their interaction, but this is not a trivial matter. The OO approach attempts to manage the system complexity by abstracting out knowledge and encapsulating it within interacting objects [WirfsBrock90, p.5]. Hence, a part can be viewed as a single object (or rather its type) or a collection of interacting objects delivering a specific functionality. If we view a part as a design problem to be solved, regardless of the approach chosen, it is likely that others have already solved a similar problem in a satisfactory manner. If we can utilise this knowledge, the quality of the system may be improved. One approach to identify reoccurring design problems and their well—proven solutions is to use software design patterns. A design pattern is an abstraction of practical experience and empirical knowledge, but it is also a description of the problem it addresses and a solution to it [Alexander77; Lea93]. While the design pattern provides a canonical solution to the described problem, human interaction and interpretation is required to apply the solution in different contexts. Software design patterns are commonly associated with, but not limited to, OO environments. Patterns are uniquely named and written in a consistent format that allows designers, developers, and others to communicate using a common vocabulary. Related patterns are grouped in collections, or ideally languages. Design patterns can facilitate the entire design and development process because they express ideas and solutions founded in experience traditional methodologies cannot. They communicate architectural ideas in a consistent high—level language.

Nevertheless, design patterns must be applied with caution. Design patterns are neither completely static, nor completely dynamic in nature. To apply a design pattern, a problem similar to the one addressed by the pattern must have been identified in some context. Patterns are not reusable components, but guidelines on how to solve a given problem. This is an important fact, but based on our experience, one that is often forgotten in real life situations. As with any design discipline, the human factor is important because choices and interpretations must be made to adapt the pattern to a given situation. On the other hand, the environment or context may dictate behaviour that must be adhered to, and thus cannot be changed. The solution must be implemented for each context, perhaps differently and perhaps using different programming languages, but a given environment may also present standard implementations of a given pattern for easy reuse, depending on the pattern complexity. Patterns can be misunderstood, misused, not used at all, or convey incorrect information at the time of writing and/or at the time of application. While design patterns can lead to sound designs, they cannot offer any guarantees [Vlissides97, i.5]. The true benefit is only realised if a given collection of design patterns is used on a regular basis in a specific domain and context. The continued use will motivate a better understanding of how the patterns work and possibly evolve in the given context. In a practical sense, design patterns that repeatedly have been applied successfully are in our view equivalent to "teaching" or "Best Practices" for the domain in question, according to the philosophical approach offered by "Best Practices" based around continuous learning and continual improvement (see also [Vlissides97, i.6]). Qua this reasoning, we have used a number of design patterns extensively in our OO designs, but have experienced that regular practical usage in a given context is closely tied to the programming language used to implement a given pattern.

The motivation for this project is to gain a better understanding on how to use design patterns from a practical point of view in OO environments, specifically how the use of language features can influence the pattern application. To make this concrete, we investigate the "Gang of Four" design patterns using Java 6 as the programming language. In our view, "design patterns" as a concept is indeed a helpful tool. However, the choice is not whether or not to use "design patterns" in the design process, but which concrete patterns to use, if any. Design patterns as a practical tool are meaningless unless specific design patterns are known, because otherwise the knowledge cannot be utilised. A pattern can describe anything, but only specific patterns can solve a given problem. By virtue of our job, we wish to evaluate the "Gang of Four" patterns because we have used several of them extensively, but critically, in the design and development of large and quite complex Internet applications. The "Gang of Four" patterns are a collection of twenty—three design patterns described in the "Design Patterns" book [Gamma95]; by April 2005, the book was in its 32nd printing! The "Gang of Four" patterns describe communicating objects and classes that are customised to solve a general design problem in a particular context [Gamma95, p.3] in OO environments. The experience gained while working with these patterns over the years has shown us that they can be a valuable aid in shaping the design of successful applications, but we have also noted several issues that warrant a closer look. The "Gang of Four" patterns are well over a decade old, and seem to be targeted primarily for C++ [Stroustrup91] environments with rather dense and stringent descriptions on how to implement them. We have used them in different environments, using languages supporting other, or missing, features compared to those addressed in the pattern descriptions. We have also experienced problematic issues, such as concurrency related issues; for example, how thread—safe initialisation in the Singleton [Gamma95, p.127] pattern is ensured. Many of these issues are practical in nature, and seem related to how design patterns and a given programming language interact. Continuing with the Singleton example, Java has built—in support for synchronisation, which could solve the initialisation problem, but there are also other ways to solve the problem in Java. Unfortunately, because of time and money, real—life projects seldom allow in—depth investigations on such issues. The aim of this project is to remedy this by offering a subjective, but comprehensive, evaluation of the "Gang of Four" patterns implemented in Java 6. The result of the evaluation will give us a better understanding on how the practical use of certain language features may affect the evaluated design patterns. This is relevant as the "Gang of Four" patterns are frequently used in real—life systems, and so is Java, but Java 6 furthermore offers a range of versatile features that will be interesting to apply in the pattern implementations. As the evaluation centres on features found in Java 6, most observations will be relevant for Java only. It may be possible that some can be generalised to similar languages.

1.2.  Goals
The primary objective of this Master's Thesis is for the undersigned to obtain a Master's Degree in Computer Science from the University of Copenhagen, Denmark.

This thesis represents a project with a formal workload of 30 ECTS. The purpose of the project is to evaluate practical application of the "Gang of Four" design patterns using Java 6 and present the findings in this thesis. The premise is to investigate how the use of Java 6 features may affect pattern application. By doing so, we hope to gain valuable experience that will enable us to understand and use design patterns better in "real—life situations", not just when applied in Java, but also in situations where the choice of programming language has already been made. The work includes theoretical and practical aspects.

The primary objective is achieved, if the project is approved based on this thesis. To fulfil the purpose of the project, we define the following sub—goals to be addressed in the project and in this thesis:

  1. Theory and Background — Present an introduction to and a discussion about the theory deemed necessary to understand topics covered by the evaluation. This will include OO; patterns in general with focus on software design patterns, especially the "Gang of Four" design patterns; clarification on how concepts and themes described by Gamma et al. relate to Java 6; and a discussion on related work and topics.
  2. Evaluation Approach — Define a simple, but reasonably structured approach on how to perform an evaluation of the "Gang of Four" patterns, where the choice of language will act as a catalyst for the evaluation. The approach must describe the overall evaluation set—up; how to focus the evaluation; and how to describe the specific criteria used to perform the various investigations. As the evaluation is subjective, this will enable others to judge the premise, execution, and result of the evaluation as well as perform a similar evaluation using a different language catalyst.
  3. Implementation — Within the realm of the defined approach, implement and evaluate the "Gang of Four" design patterns using Java 6.
  4. Evaluation — Present the evaluation outcome and comment on the findings separately for each evaluated pattern and by juxtaposing the individual evaluations.

A secondary objective is the intention that this thesis can aid others, especially colleagues at work and like—minded, to reflect about software design patterns in general, but in particular in relation to the "Gang of Four" patterns implemented in Java 6. Whether or not this objective is achieved will not be evaluated, but this thesis and the implementations will be made publicly available for those interested.

1.2.1.  Demarcations
This thesis will not cover:

1.3.  Thesis Summary
In this thesis, we present a subjective evaluation of the "Gang of Four" design patterns implemented in Java 6. The evaluation centres on how the use of specific language features may affect the pattern application. To make a reasonably structured evaluation across the different patterns using a given language as the catalyst, we address issues related to the implementation described by Gamma et al. in the Implementation and Sample Code elements in the "Gang of Four" pattern descriptions. If possible, we provide an example on how equivalent functionality can be implemented in Java 6, or explain why it cannot. We summarise our findings, and identify traits common to several patterns. Additionally, we present a thorough introduction to the background theory required to understand the "Gang of Four" patterns and the concepts they build on, such as OO development and pattern theory. We also discuss several articles related to application of the "Gang of Four" patterns in various different languages, both dynamic and static languages, and where deemed relevant compare the results to the outcome of this evaluation.

This thesis is divided into two parts, excluding the introduction and overall conclusion. The first part presents theory and background (chapters 2 – 4). The second part concerns the implementation and practical evaluation (chapters 5 – 9). In principle, each part can be read independently, but part one provides a solid foundation on related topics before the evaluation is undertaken in part two. Most of the theory presented in this thesis can be found in numerous other places in the literature as well, but we apply a practical viewpoint that focuses on the "Gang of Four" patterns and Java 6. By including, discussing, and focusing on various aspects of it here, we maintain an important perspective on points relevant to the evaluation.

1.3.1.  Part One — Theory and Background
This part begins with an introduction to OO development. Focus is on how design patterns, particularly the "Gang of Four" patterns and the concepts they express, can aid the process and how they relate to Java 6. Pattern theory and the relation to software patterns are described and selected studies on related work are examined.

Chapter 2 — The "Gang of Four" patterns are design patterns targeting design problems related to OO. To understand the inner workings of the "Gang of Four" patterns, the OO methodology forming their foundation must be understood. Its importance is emphasized by Gamma et al. as the entire first chapter in [Gamma95] is dedicated to the OO concepts and themes that form the basis of the design patterns presented. Hence, chapter 2 gives an introductory, but focused, presentation to these issues, but goes even further and connects concepts, themes, Java 6, and usage of design patterns in the overall development life—cycle of OO systems. As explained in section 2.1, there is no formal consensus on the concepts that describe fundamental OO behaviour, but the themes and concepts described by Gamma et al. seem to be commonly accepted. This is illustrated by juxtaposing the concepts against a recent survey by Armstrong [Armstrong06] that investigates 239 texts on OO theory to try to identify the fundamental concepts inherent to OO. Because of this wide acceptance and considering how ubiquitous applicable the abstractions described in "Gang of Four" patterns have proven to be, the choice of OO method to guide the development process becomes less important. In many respects, as reasoned in section 2.2, we see design patterns as orthogonal to OO methods, because the objects and knowledge they represent are independent of which method produced the (initial) context to which a pattern can be applied. Regardless of the OO method used, the software lifecycle normally includes phases such as OO analysis (OOA), OO design (OOD), and OO programming (OOP), or implementation, perhaps re—iterated as needed as the design evolves. Section 2.4 explains that the analysis phase determines what is to be built, often in form of a conceptual model, and the design phase how it should be built, as pointed out in section 2.5. Design patterns are primarily used during the design phase, often modelled using UML as described in section 2.3, but also in the implementation phase as the patterns must be adapted to and implemented in the chosen language. As rationalised in section 2.6, the design and implementation phases are where the choice of language really becomes important, because it determines how the design is executed; what is possible, what is not, and ultimately how well the implementation reflects the desired concepts and themes.

Chapter 3 — Chapter 3 presents general pattern theory based on the ideas set forth by Christopher Alexander within the field of architecture, but also relates the theory to software design patterns, and in particular to the "Gang of Four" patterns. The "Gang of Four" design patterns are "just" one collection of software design patterns, and in order to understand software design patterns as a concept, at least the basic principles of Christopher Alexander's work on patterns and pattern languages must be known. This is necessary because software design patterns in general build on the basic ideas set forth by Alexander, in particular the "Gang of Four" patterns evaluated here [Gamma95, p.2]. Simplified greatly, a pattern is an abstraction of practical experience and basic knowledge on how to solve a given problem, described in a consistent format so it can be adapted for reuse in similar contexts. Section 3.1 contains an introduction to Alexander's work, describing the history and theory behind patterns and pattern languages; the information is mainly based on [Appleton00] and [Lea93], subsidiary on [Alexander77]. Many of Alexander's ideas are admittedly abstract, but computer science was not only reasonably quick to adapt several of his ideas, but also to introduce original pattern related concepts as explained in section 3.2. According to Alexander, a pattern must ideally possess certain properties to ensure the quality of the pattern and thus the quality of the (reusable) solution it generates, for example Abstraction, Composibility, and Encapsulation. Many of these properties have similar meaning to desirable constructs in OO, which could explain why software patterns first became popular within this domain. A class, for example, is an abstraction with encapsulated responsibilities that can be used as a component by other classes. Pattern qualities are explained in section 3.3, but a pattern must furthermore balance opposing forces, or constraints, within its context to reach a balance that implicitly will be present in the pattern and its application [Appleton00]. This implies, as elaborated in section 3.4, that a pattern may represent trade—offs between various forces, for example flexibility versus speed of an OO application. For a pattern to be useful, it must concisely communicate both the problem it tries to solve and the solution to it, including expressing the desired qualities and account for the forces at play. It does this by partitioning the description in various descriptive elements, such as Name, Intent, Consequences, Implementation, Sample Code, etc., but this is no trivial matter as the notion of patterns can be applied in various contexts. Section 3.5 describes common pattern formats used to describe patterns; in particularly the format used to describe the "Gang of Four" design patterns, where C++ and Smalltalk are used to illustrate key pattern points. This format is used extensively in the evaluation, in particular the Implementation and Sample Code elements as they pertain to the implementation and evaluation. Still, the lack of a formalised concept of a design pattern has long been a vigorously debated issue within the pattern community. It goes to the very core of understanding, or agreeing on, what software design patterns are. This is discussed in section 3.6. Formalism is closely related to tool support for pattern mining, understanding, and application, and can therefore aid the implementation, but also limit the degree of freedom inherent in pattern descriptions. Section 3.7 describes how patterns can be grouped in collections, or ideally languages, where individual patterns may be interrelated in various cooperative ways. All twenty—three "Gang of Four" patterns are finally presented, including an illustration of how they may intricately connect and cooperate in numerous ways. The Gamma at el. classification scheme is also presented, which classifies patterns according to scope (Class, Object) and purpose (Creational, Structural, Behavioural). Section 3.8 describes how patterns can evolve, from discovery to ordinary usage to possibly becoming part of the language itself. Pattern collections may also evolve over time. Finally, section 3.9 discusses the practical application of patterns.

Chapter 4 — The final chapter in the first part of this thesis is chapter 4, which discuss selected studies on related work. All revolve around the "Gang of Four" pattern application in a given language. Compared to chapter 2 and 3, the chapter is much more technical and practical. It is discussed how specific languages via their paradigms and features affect individual "Gang of Four" patterns. As explained in section 4.1, different languages have different support for various pattern abstractions. According to Norvig [Norvig96, p.7], patterns can be classified based on their (language) implementation level as Invisible, Informal, or Formal, where only the latter corresponds to pattern application as described by Alexander, i.e. anew from "scratch" for each context. The former two rely on built—in language support and/or components, respectively. The level of support can greatly influence the pattern application in the given language, and Java is no different. Several dynamic and primarily functional languages have been shown to provide simpler pattern implementations compared to the canonical "Gang of Four" implementations. Articles describing three such language studies are examined in section 4.2, concerning Common Lisp, Dylan, and Scheme. The primary conclusion drawn from these studies is that dynamic features such as reflection, first—class types, multiple—dispatch, and higher—order functions have a positive impact on nearly all of the "Gang of Four" patterns [Norvig96, p.10; Sullivan02a, p.43]. This is interesting because even though Java is neither functional, nor dynamic, it supports reflection, closures, generics, and dynamic proxies, which possibly could be used to achieve similar implementations. As section 4.3 reveals, the "Gang of Four" patterns have been applied in several earlier Java versions, at least, but we have not found similar studies of all "Gang of Four" patterns in Java 5 or 6. Studies of AspectJ and Eiffel implementations are also discussed in section 4.3. AspectJ uses Aspect Oriented Programming (AOP) features to allow Java to exhibit very dynamic features, such as open classes and support for method combination (advice). Utilising such features, the study claims that seventeen of the twenty—three implementations exhibit modularity improvements in terms of better code locality, reusability, composibility, and (un)pluggability [Hannemann02, p.1]. This is interesting, because Java by itself can simulate many of the features found in AspectJ, though requiring some work. The Eiffel studies are similar in that many of the features can also be found or simulated in Java 6, but also because of the success rate in fully or partly componentizing two—thirds of the "Gang of Four" patterns [Meyer06, p.3]. Interesting. Section 4.4 provides a comparison of the features examined in the aforementioned studies, comparing them to features found in Java 6 that can be used in the practical evaluation. It also tries to identify common traits of individual patterns as well as per pattern classification, e.g. scope (Class, Object) and purpose (Creational, Structural, Behavioural).

1.3.2.  Part Two — Evaluation
The second part concerns the practical evaluation, which consists of individual pattern implementations as well as a comparative evaluation of all implementations and features used, to identify common traits and issues.

Chapter 5 — Chapter 5 defines a simple evaluation approach that can be used to investigate how well a given language expresses all pattern functionality described in the "Gang of Four" Implementation and Sample Code elements, and then applies it to define the evaluation goals used in this thesis. For others to judge the evaluation, its premise must be known. As described in section 5.1, the focus is practical and experimental as these elements focus implementation and language issues. Next, the evaluation approach is defined in section 5.2. It requires a detailed and a comparative evaluation. The detailed evaluation concerns the actual pattern implementation and participant usage, and describes the pattern implementations using familiar "Gang of Four" pattern elements, albeit in more detail. The comparative evaluation juxtaposes the individual observations and feature usage to identify common traits and issues. Section 5.3 uses the defined approach to establish the evaluation goals. The overall goal is to provide a realistic, but subjective, evaluation that may help understand how the "Gang of Four" patterns and Java 6 can cooperate. The focus is practical and technical, from the perspective of a practising designer and/or developer. Three broad categories of Java 6 features are examined: core language features (types, generics, closures, etc.), reflection (class literals, dynamic proxies, annotations, etc.), and special language mechanisms (synchronisation, serialization, cloning, etc.). The comparative evaluation will also analyse "Gang of Four" pattern relationships described by Gamma et al. compared to those actually expressed in the implementations. It also classifies the level of support individual patterns have in Java 6 within the realm of the evaluation performed.

Chapter 6 — Chapter 6 is dedicated to the practical aspects related to the implementation in Java 6. Section 6.1 outlines the technical set—up, such as the exact Java version and IDE used. Eclipse 3.3 is the primary IDE, but Sun's NetBeans 5.5.1 is used for comparison. Eclipse uses its own compiler implementation, whereas NetBeans uses the official compiler. No plug—ins of any kind are required to run the evaluation code or tests. All individual pattern implementations operate, directly or indirectly, on a set of model classes to imitate a larger "application" compared to what could be achieved by isolated pattern implementations alone. Individual implementations or parts thereof can thus more easily be used in other pattern implementations, expressing many of the pattern relationships described by Gamma et al. Section 6.2 explains how the implementations are modelled using UML Class diagrams. The diagrams are a big part of the detailed evaluation because they meticulously illustrate pattern participants, including attributes and operations. In section 6.3, the basic design for the overall evaluation is described, also illustrated in UML. Next, section 6.4 presents an overview of the developed source code, divided into relevant packages for each pattern implementation. Several Meta packages containing functionality such as model classes, loggers, reflection and general utilities have also been developed. To ensure that others can confirm the pattern behaviour in the implementations provided in this thesis, an absolute minimal "test framework" has been developed as explained in section 6.5. Each pattern implementation supplies a test class to illustrate the functionality. This is not a replacement for JUnit testing, but merely to report developed class usage via system out or file loggers. Complete source code, JavaDoc, and UML class diagrams are available from the thesis website.

Chapter 7 — The first part of the evaluation is the comparative evaluation in chapter 7. The comparative evaluation offers a thorough analysis of which Java 6 features are used to implement which patterns. Section 7.1 presents all identified pattern x feature mappings in table 7.1, high—lighting the most interesting entries, which are also summarised separately in section 9.2. The features investigated are those established in chapter 5, categorised as core language features, reflection, or special language mechanisms. Each feature has a dedicated sub—section that explains its usage across all patterns, identifying possible common traits and alternatives, as well as a small conclusion to its usefulness with regards to help expressing "Gang of Four" pattern functionality. Numerous program listings are used to illustrate pattern functionality. The evaluation shows that the pattern implementations benefit from Java's mixture of static and dynamic features. As the last thing, section 7.1 presents observations from the pattern implementations on how to translate C++ features into Java 6 features relevant to several patterns. Next, section 7.2 compares the pattern relationships expressed in the evaluation to the "Gang of Four" described relationships identified in section 3.7. The expressed relationships are subjective based on the evaluation design rather than language features, but help illustrate how versatile the "Gang of Four" patters are. To conclude the comparative evaluation, section 7.3 classifies the patterns according to their implementation level as described by Norvig, explained in section 4.1.

Chapter 8 — Chapter 8 presents the individual pattern implementations. Section 8.1, 8.2, and 8.3 present the evaluations of Creational, Structural, and Behavioural patterns, respectively. Each pattern investigation is presented as required by the evaluation approach defined in chapter 5. The detailed evaluation shows that practically all pattern functionality described in the Implementation and Sample Code elements of the "Gang of Four" design patterns can be implemented or simulated in Java 6, including Meta information not used directly in the canonical implementations. The implementations express the concepts described in chapter 2 and 3.

Chapter 9 — The results of the comparative and detailed evaluations are summarised and presented in chapter 9. While chapter 7 and 8 provide summaries and conclusions where appropriate, chapter 9 comments on the evaluation as a whole, presents high—lights, and puts the evaluation and its results in perspective. Section 9.1 determines the level of compliance between the implementations and the "Gang of Four" concepts, themes, and pattern descriptions. Section 9.2 concludes that Java's core language features promote robustness, pattern intent, and reusability, and form the base of all the pattern implementations. Combined with reflection and annotations, this offers alternative and flexible pattern implementations. Next, section 9.3 presents the high—lights identified during the evaluation that utilises the Java 6 features in the manner just described. High—lights include generic factories in Abstract Factory and Factory Method, guarded types in Memento, annotated observers in Observer, dynamic proxies in Proxy and State, and enumerations in Singleton (Singleton—as—Single—Constant idiom). We end the evaluation conclusions with an evaluation of the defined evaluation approach itself in section 9.4. We conclude that the evaluation approach offers a way to investigate and judge how well a given language can express the "Gang of Four" functionality expressed in the Implementation and Sample Code elements, but we do not draw any conclusions as to whether the language catalyst should be used in a given scenario, here Java 6. The evaluation serves as a tool from which experience can be drawn.

Following part two, chapter 10 contains an overall conclusion to this thesis and the work performed. Section 10.1 explains the perspective in which this thesis and its conclusions must be understood: from a practical and experimental point of view, explanatory in nature. The initial goals have all been achieved and the specific results and contributions made by this thesis are listed in section 10.2. Primary contributions include the detailed evaluation in chapter 8, which shows that practically all pattern functionality described in the Implementation and Sample Code elements of the "Gang of Four" patterns can be implemented or simulated in Java 6, as well as the pattern and Java 6 functionality high—lights from section 9.2. Before we conclude this thesis with a final remark in section 10.4, an outlook on possible future work is provided in section 10.3.

1.3.3.  Work Performed
The work performed during the project and presented in this thesis has been both theoretical and practical, with emphasis on the latter. The amount of hours put into the project has been substantial; the time spent reading, writing, experimenting, shouting, and programming is hard to put into words, but has been spent nonetheless.

1.3.3.1.  Theoretical
The theoretical aspect covers the research, books and articles read, not forgetting the summation and discussion of the relevant material presented in this thesis. Making clear demarcations proved no easy task because, in our view, everybody within the field of computer science seem to have an opinion on software design patterns, perhaps because of the apparent lack of a common understanding and formal methodology. Much new material had to be covered, understood, and some of it paraphrased for this thesis; and some material that was expected could not be found. All this initially came as a bit of surprise; while design patterns are easy to use, ordinary use normally does not warrant in—depth scrutiny, research, and evaluation based on scientific theories. As this thesis concludes, the use of design patterns is very much a practical discipline. Due to the shift in focus of this thesis, much early research and work unfortunately had to be discarded, but this process also caused much improved (practical) focus and structure in the thesis. [Rode07a] is the final work description.

The bibliography contains the list of references used in this thesis. Pivotal among them are [Gamma95], [Lea93; Lea00], [Appleton00], [PPR], [Buschmann96], and [WirfsBrock90] for the theory and background; [Norvig96], [Sullivan02a; Sullivan02b], [Hannemann02], and [Arnout06; Meyer06] for the related work; and [Stroustrup91], [Gosling05], and [Bloch01] for the implementation and evaluation. The choice to use the "Gang of Four" patterns was made because of experience and their widespread use. The (re—) reading of the [Gamma95] book gave us much new insight into the workings of several familiar "Gang of Four" design patterns. The book is very dense and covers a lot of information, some of which can easily be missed on casual reading. This is one of the reasons why the evaluation investigates all functionality described in the Implementation and Sample Code elements, and not just the canonical implementations.

1.3.3.2.  Practical
The practical part covers everything related to the evaluation and implementation(s). It took substantial effort to figure out how to conduct a meaningful evaluation of design patterns. An evaluation only makes sense if the premise for the evaluation can be viewed and judged by others, so they themselves can conduct a similar evaluation, or at least judge the outcome in the proper context. Because of the shift in focus, we deemphasised a formalised evaluation approach compared to the practical work performed in the evaluation. Unfortunately, this was not done until after we had developed a semi—formal approach, which was then completely discarded. On the plus side is that this gave the entire project an aura of realism because unlike the "Gang of Four" patterns, software projects and systems rarely get things right on the first try.

The choice to use Java 6 was because of personal experience with Java, but also because we know of no other study analysing the use of Java 6, or 5 for that matter, as the language to implement the "Gang of Four" patterns. Experience is essential in a project like this; the "tricks of the trade" cannot be utilised otherwise and implementations may become trivial. The overall implementation has produced over 300 Java source files, yielding 400+ compiled class files (including enumerations and inner classes). The design, implementation, test, and documentation took longer than expected, as always. We feel it is important to establish that the pattern implementations are not trivial shells unless explicitly warranted by the design, but realistic and sometimes quite complex. Because of the scale of the implementations, the evaluations also took quite some time. In reality, the theoretical and practical work performed exceeds 30 ECTS, though in part because of the shift in focus. This indicates that the thesis scope is perhaps too wide and/or too ambitious, but done is done.