DOCSLIB.ORG

Genericity, Extensibility and Type-Safety in the Visitor Pattern

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Genericity, Extensibility and Type-Safety in the Visitor Pattern Genericity, extensibility and type-safety in the V pattern Bruno Cesar´ dos Santos Oliveira Wolfson College Oxford University Computing Laboratory Submitted for the degree of Doctor of Philosophy Abstract A software component is, in a general sense, a piece of software that can be safely reused and flexibly adapted by some other piece of software. The safety can be ensured by a type system that guarantees the right usage of the component; the flexibility stems from the fact that components are parametrizable over different aspects affecting their behaviours. Component-oriented program- ming (COP), a programming style where software would be built out of several independent com- ponents, has for a long time eluded the software industry. Several reasons have been raised over time, but one that is consistently pointed out is the inadequacy of existing programming languages for the development of software components. Generic Programming (GP) usually manifests itself as a kind of parametrization. By abstracting from the differences of what would otherwise be separate but otherwise similar specific programs, one can develop a single unified generic program. Instantiating the parameter in various ways retrieves the various specific programs (and ideally some new ones too). Instances of GP include the generics (parametrization by types) mechanism as found in recent versions Java and C# and Datatype-Generic Programming (DGP) (parametrization by shape). Both mechanisms allow novel ways to parametrize programs that can largely increase the flexibility of programs. Software components and GP, and in particular DGP, are clearly related: GP and DGP provide novel ways to parametrize software, while software components benefit from parametrization in order to be flexible. However, DGP and COP have mostly been studied in isolation, with the former being a research topic among some functional programming communities and the latter being mostly studied within the object-oriented communities. In this thesis we will argue for the importance of the parametrization mechanisms provided by GP, and in particular DGP, in COP. We will defend that many design patterns can be captured as software components when using such kinds of parametrization. As evidence for this we will, using DGP techniques, develop a component library for the V pattern that is generic (i.e. can be used on several concrete visitors); extensible (i.e. concrete visitors may be extended); and i Abstract ii type-safe (i.e. its usage is statically type checked). A second aspect of this thesis concerns the adaptation of functional DGP techniques to object-oriented languages. We argue that parametriza- tion by datatypes should be replaced by parametrization by visitors, since visitors can be viewed as encodings of datatypes and, through those encodings, the functional techniques naturally translate into an OO setting. ii Acknowledgements I would like to thank Jeremy Gibbons, my supervisor, for two different reasons. Firstly, for being an excellent supervisor, for giving me a very interesting project to work on, for helping me during my first stages of research (when I felt unconfident about my research and abilities), and for always being willing to help me with technical (and bureaucratic) problems. Secondly, for giving me the opportunity to study in Britain and in the beautiful and inspiring city of Oxford, which has greatly helped me on the development of both my personal and professional skills. I cannot forget Jos´e Nuno Oliveira for introducing me to the beauty of functional programming with his always inter- esting lectures and for motivating me into coming to Oxford. Ralf Hinze provided great inspiration for my work and taught me a lot about generic programming. He and Andres L¨oh were excellent hosts during my one month visit to Bonn, which proved very fruitful in terms of research. Mike Spivey took me as his student during Jeremy’s sabbatical and provided important feedback during my confirmation of status. Richard Bird and Oege de Moor were very helpful in making me fo- cus on a research direction during my transfer examination. The Friday meetings of the Problem Solving Club provided a relaxed environment to discuss research problems and to get feedback about my own research. The meetings of the Datatype-Generic Programming project gave me the opportunity to present progress on my research and to get feedback regularly, and also provided a constant flow of new ideas. The attic crowd (which included, among others, Daniel Goodman, Christopher Aycock, Rui Zhang, Jolie de Miranda, Edward Smith, and Zoltan Miklos) provided an entertaining working environment. Wolfson College and the many friends I made there did an excellent job in my social integration at Oxford. My girlfriend Warnchudee Chalitaporn, who I met at Wolfson, gave me a lot of support and was very patient during my DPhil. Finally, my family, and especially my mother, have always motivated me and gave me the conditions to pursue higher education. iii Table of Contents 1 Introduction 1 1.1 SoftwareComponentsandReuse. ..... 2 1.2 Component-OrientedProgramming . ...... 3 1.3 DesignPatterns:ASignofWeakness? . ....... 4 1.4 Datatype-GenericProgramming . ...... 5 1.5 AcasestudyontheV Pattern.......................... 6 1.5.1 TheV:AValuableAbstraction . 7 1.5.2 TheScalaOption............................... 8 1.6 OverviewoftheThesis ............................. ... 10 1.7 RelatedWork ..................................... 11 1.7.1 Encodings of Datatypes and the V Pattern............... 11 1.7.2 DesignPatternsandComponents . ... 12 1.7.3 DesignPatternsandFunctionalProgramming . ........ 14 1.7.4 FunctionalDGP ............................... 16 1.7.5 TheExpressionProblem . 19 2 Preliminaries 22 2.1 TheScalaProgrammingLanguage . ..... 22 2.1.1 ExpressionsandDefinitions . ... 23 2.1.2 ClassesandObjects. .. .. .. .. .. .. .. .. 25 2.1.3 TraitsandMixins............................... 27 2.1.4 GenericTypesandMethods . 28 2.1.5 AbstractTypes ................................ 29 2.1.6 ImplicitParameters. .. 32 2.1.7 Higher-kindedTypes . 33 2.2 ScalaasaDGPlanguage ............................. .. 34 2.2.1 EncodingType-ConstructorPolymorphism . ....... 34 2.2.2 ALittleDGPLibrary............................. 35 2.3 Vs and Cs ............................... 36 2.3.1 TheC Pattern ............................ 36 iv TABLE OF CONTENTS v 2.3.2 TheV Pattern.............................. 38 2.4 FunctionalNotation.............................. .... 42 3 Visitors as Encodings of Datatypes 44 3.1 Introduction.................................... .. 44 3.2 Internal or External Vs:ADesignChoice .. .. .. .. .. 47 3.3 InternalVisitorsandtheChurchEncoding . .......... 48 3.3.1 EncodingDataTypesintheLambdaCalculus . ...... 48 3.3.2 TheChurchEncodinginScala . .. 49 3.4 ExternalVisitorsandtheParigotEncoding . ........... 50 3.4.1 LimitationsofChurchEncodings . .... 50 3.4.2 ParigotEncodingsintheLambdaCalculus . ...... 51 3.4.3 TheParigotEncodinginScala . ... 51 3.5 Generic Visitors: Two Dimensions of Parametrization . .............. 52 3.5.1 Abstractingovertheshape . ... 52 3.5.2 Abstractingoverthedecompositionstrategy . .......... 54 3.6 TheV PatternasaLibrary ........................... 56 3.6.1 DefiningtheLibrary ............................. 56 3.6.2 UsingtheLibrary............................... 59 3.7 Syntactic Sugar for VsinScala......................... 61 3.7.1 ExtendingtheLibrary . 62 3.7.2 UsingtheExtendedLibrary . .. 63 3.7.3 ComparisonwithFunctionalProgramming . ...... 65 3.8 ExpressivenessoftheVisitorLibrary . .......... 66 3.8.1 ParametricDatatypes. .. 66 3.8.2 MutuallyRecursiveDatatypes . .... 67 3.8.3 ExistentiallyQuantifiedDatatypes . ....... 68 3.8.4 ParamorphicVisitors . .. 69 3.9 Discussion...................................... 71 4 Visitor-Generic Programming 73 4.1 Introduction.................................... .. 73 4.2 EncodingSumsandProductsinScala . ...... 75 4.3 Generic Programming with Vs......................... 77 4.3.1 GenericsfortheMassesinScala . .... 77 4.3.2 RepresentationsofVisitors . ..... 80 4.3.3 DefiningGenericFunctions . .. 82 4.3.4 ReuseviaInheritance. .. 83 4.3.5 LocalRedefinition .............................. 84 4.4 GMandIndexedVs............................... 85 v TABLE OF CONTENTS vi 4.4.1 IndexedVisitors ............................... 85 4.4.2 AVisitorLibraryforIndexedVisitors . ....... 86 4.4.3 GMasanInstanceoftheVisitorLibrary. ...... 88 4.5 AVisitorforaFamilyBasedonSumsofProducts . ......... 91 4.5.1 AV BasedonSumsofProducts . 91 4.5.2 CreatingNewDatatypes . 93 4.5.3 FunctorialRepresentations . ..... 95 4.5.4 Separating Recursion from Generic Programming . ......... 96 4.6 Example: Generic Serialization and Deserialization . ............... 98 4.6.1 Serialization ................................. 98 4.6.2 Deserialization ............................... 100 4.7 Discussion...................................... 101 5 Extensible Visitors and Generic Functions 104 5.1 Introduction.................................... 104 5.2 GenericFunctionsandTheExpressionProblem . .......... 107 5.2.1 TheExtensibilityProblemofVisitors . ....... 108 5.3 ExtensibilityinInternalVisitors . .......... 109 5.3.1 SimpleExtensibleVisitors . 109 5.3.2 ExtendingGenericFunctionswithExtraCases . ........ 110 5.3.3 ExtensibleRepresentations. .. 112 5.4 Example: AnExtensibleGenericPrettyPrinter . ...........113 5.4.1 AGenericPrettyPrinter . 113 5.4.2 PrettyPrintingTrees . 115 5.4.3 PrettyPrintingLists . 117 5.5 ExtensibilityonVisitorsofanyKind . ........
Load more

Recommended publications
  • 1 Design Pattern for Open Class (DRAFT) 2 Abstract Factory
    1 Design Pattern for Open Class (DRAFT) Tanaka Akira <[email protected]> A design pattern describes a software architecture which is reusable and exten- sible. [GoF] is the book containing 23 design patterns for OOP languages like C++ and Java. [GoF] describes several trade offs of the patterns. In C++ and Java, a class is defined by only one module. However, there are languages which can define a class by two or more modules: Cecil, MultiJava, AspectJ, MixJuice, CLOS, Ruby, etc. Such class is called "open class" because it is extensible by modules implemented later [Chambers]. For languages with open class, more extensible and/or simpler design patterns exists. We studied design patterns with open class for each GoF design patterns. In this paper, we describe two patterns: the Abstract Factory pattern and the Visitor pattern. 2 Abstract Factory The Abstract Factory pattern is a design pattern for separating class names from the code which generates the object group of related classes for making them configurable. Following figure is the class diagram of the Abstract Factory pattern. Since the example described in [GoF] uses only one concrete factory for each binaries, the required concrete factory is selected statically. The example builds two binaries for Motif and Presentation Manager from a single source code. Two concrete factories are exist for Motif and Presentation Manager. When a binary is built, it is selected which concrete factory is linked. Such static selection can be implemented with the fewer number of classes by open class as following modules. • The module which defines Window and ScrollBar class and their methods which is independent to window systems.
    [Show full text]
  • Safety Properties Liveness Properties
    Computer security Goal: prevent bad things from happening PLDI’06 Tutorial T1: Clients not paying for services Enforcing and Expressing Security Critical service unavailable with Programming Languages Confidential information leaked Important information damaged System used to violate laws (e.g., copyright) Andrew Myers Conventional security mechanisms aren’t Cornell University up to the challenge http://www.cs.cornell.edu/andru PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 2 Harder & more important Language-based security In the ’70s, computing systems were isolated. Conventional security: program is black box software updates done infrequently by an experienced Encryption administrator. Firewalls you trusted the (few) programs you ran. System calls/privileged mode physical access was required. Process-level privilege and permissions-based access control crashes and outages didn’t cost billions. The Internet has changed all of this. Prevents addressing important security issues: Downloaded and mobile code we depend upon the infrastructure for everyday services you have no idea what programs do. Buffer overruns and other safety problems software is constantly updated – sometimes without your knowledge Extensible systems or consent. Application-level security policies a hacker in the Philippines is as close as your neighbor. System-level security validation everything is executable (e.g., web pages, email). Languages and compilers to the rescue! PLDI Tutorial: Enforcing
    [Show full text]
  • Cyclone: a Type-Safe Dialect of C∗
    Cyclone: A Type-Safe Dialect of C∗ Dan Grossman Michael Hicks Trevor Jim Greg Morrisett If any bug has achieved celebrity status, it is the • In C, an array of structs will be laid out contigu- buffer overflow. It made front-page news as early ously in memory, which is good for cache locality. as 1987, as the enabler of the Morris worm, the first In Java, the decision of how to lay out an array worm to spread through the Internet. In recent years, of objects is made by the compiler, and probably attacks exploiting buffer overflows have become more has indirections. frequent, and more virulent. This year, for exam- ple, the Witty worm was released to the wild less • C has data types that match hardware data than 48 hours after a buffer overflow vulnerability types and operations. Java abstracts from the was publicly announced; in 45 minutes, it infected hardware (“write once, run anywhere”). the entire world-wide population of 12,000 machines running the vulnerable programs. • C has manual memory management, whereas Notably, buffer overflows are a problem only for the Java has garbage collection. Garbage collec- C and C++ languages—Java and other “safe” lan- tion is safe and convenient, but places little con- guages have built-in protection against them. More- trol over performance in the hands of the pro- over, buffer overflows appear in C programs written grammer, and indeed encourages an allocation- by expert programmers who are security concious— intensive style. programs such as OpenSSH, Kerberos, and the com- In short, C programmers can see the costs of their mercial intrusion detection programs that were the programs simply by looking at them, and they can target of Witty.
    [Show full text]
  • Cs164: Introduction to Programming Languages and Compilers
    Lecture 19 Flow Analysis flow analysis in prolog; applications of flow analysis Ras Bodik Hack Your Language! CS164: Introduction to Programming Ali and Mangpo Languages and Compilers, Spring 2013 UC Berkeley 1 Today Static program analysis what it computes and how are its results used Points-to analysis analysis for understanding flow of pointer values Andersen’s algorithm approximation of programs: how and why Andersen’s algorithm in Prolog points-to analysis expressed via just four deduction rules Andersen’s algorithm via CYK parsing (optional) expressed as CYK parsing of a graph representing the pgm Static Analysis of Programs definition and motivation 3 Static program analysis Computes program properties used by a range of clients: compiler optimizers, static debuggers, security audit tools, IDEs, … Static analysis == at compile time – that is, prior to seeing the actual input ==> analysis answer must be correct for all possible inputs Sample program properties: does variable x has a constant value (for all inputs)? does foo() return a table (whenever called, on all inputs)? 4 Client 1: Program Optimization Optimize program by finding constant subexpressions Ex: replace x[i] with x[1] if we know that i is always 1. This optimizations saves the address computation. This analysis is called constant propagation i = 2 … i = i+2 … if (…) { …} … x[i] = x[i-1] 5 Client 2: Find security vulnerabilities One specific analysis: find broken sanitization In a web server program, as whether a value can flow from POST (untrusted source) to the SQL interpreter (trusted sink) without passing through the cgi.escape() sanitizer? This is taint analysis.
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Tree Visitors in Clojure Update the Java Visitor Pattern with Functional Zippers
    Tree visitors in Clojure Update the Java Visitor pattern with functional zippers Skill Level: Intermediate Alex Miller ([email protected]) Senior Engineer Revelytix 20 Sep 2011 JVM language explorer Alex Miller has recently discovered the benefits of implementing the Visitor pattern using Clojure, a functional Lisp variant for the Java Virtual Machine. In this article, he revisits the Visitor pattern, first demonstrating its use in traversing tree data in Java programs, then rewriting it with the addition of Clojure's functional zippers. I’ve used trees of domain objects in my Java applications for many years. More recently, I’ve been using them in Clojure. In each case, I've found that the Visitor pattern is a reliable tool for manipulating trees of data. But there are differences in how the pattern works in a functional versus object-oriented language, and in the results it yields. About Clojure Clojure is a dynamic and functional programming language variant of Lisp, written specifically for the JVM. Learn more about Clojure on developerWorks: •"The Clojure programming language" •"Clojure and concurrency" •"Solving the Expression Problem with Clojure 1.2" •"Using CouchDB with Clojure" In this article, I revisit domain trees and the Visitor pattern for the Java language, Tree visitors in Clojure Trademarks © Copyright IBM Corporation 2011 Page 1 of 27 developerWorks® ibm.com/developerWorks then walk through several visitor implementations using Clojure. Being a functional language, Clojure brings new tricks to data query and manipulation. In particular, I've found that integrating functional zippers into the Visitor pattern yields efficiency benefits, which I explore.
    [Show full text]
  • An Operational Semantics and Type Safety Proof for Multiple Inheritance in C++
    An Operational Semantics and Type Safety Proof for Multiple Inheritance in C++ Daniel Wasserrab Tobias Nipkow Gregor Snelting Frank Tip Universitat¨ Passau Technische Universitat¨ Universitat¨ Passau IBM T.J. Watson Research [email protected] Munchen¨ [email protected] Center passau.de [email protected] passau.de [email protected] Abstract pected type, or end with an exception. The semantics and proof are formalized and machine-checked using the Isabelle/HOL theorem We present an operational semantics and type safety proof for 1 multiple inheritance in C++. The semantics models the behaviour prover [15] and are available online . of method calls, field accesses, and two forms of casts in C++ class One of the main sources of complexity in C++ is a complex hierarchies exactly, and the type safety proof was formalized and form of multiple inheritance, in which a combination of shared machine-checked in Isabelle/HOL. Our semantics enables one, for (“virtual”) and repeated (“nonvirtual”) inheritance is permitted. Be- the first time, to understand the behaviour of operations on C++ cause of this complexity, the behaviour of operations on C++ class class hierarchies without referring to implementation-level artifacts hierarchies has traditionally been defined informally [29], and in such as virtual function tables. Moreover, it can—as the semantics terms of implementation-level constructs such as v-tables. We are is executable—act as a reference for compilers, and it can form only aware of a few formal treatments—and of no operational the basis for more advanced correctness proofs of, e.g., automated semantics—for C++-like languages with shared and repeated mul- program transformations.
    [Show full text]
  • G22.2110-003 Programming Languages - Fall 2012 Week 14 - Part 1
    G22.2110-003 Programming Languages - Fall 2012 Week 14 - Part 1 Thomas Wies New York University Review Last lecture I Exceptions Outline Today: I Generic Programming Sources for today's lecture: I PLP, ch. 8.4 I Programming in Scala, ch. 19, 20.6 Generic programming Subroutines provide a way to abstract over values. Generic programming lets us abstract over types. Examples: I A sorting algorithm has the same structure, regardless of the types being sorted I Stack primitives have the same semantics, regardless of the objects stored on the stack. One common use: I algorithms on containers: updating, iteration, search Language models: I C: macros (textual substitution) or unsafe casts I Ada: generic units and instantiations I C++, Java, C#, Scala: generics (also called templates) I ML: parametric polymorphism, functors Parameterizing software components Construct Parameter(s): array bounds, element type subprogram values (arguments) Ada generic package values, types, packages Ada generic subprogram values, types C++ class template values, types C++ function template values, types Java generic classes Scala generic types (and implicit values) ML function values (including other functions) ML type constructor types ML functor values, types, structures Templates in C++ template <typename T> class Array { public : explicit Array (size_t); // constructor T& operator[] (size_t); // subscript operator ... // other operations private : ... // a size and a pointer to an array }; Array<int> V1(100); // instantiation Array<int> V2; // use default constructor
    [Show full text]
  • Chapter 8 Automation Using Powershell
    Chapter 8 Automation Using PowerShell Virtual Machine Manager is one of the first Microsoft software products to fully adopt Windows PowerShell and offer its users a complete management interface tailored for script- ing. From the first release of VMM 2007, the Virtual Machine Manager Administrator Console was written on top of Windows PowerShell, utilizing the many cmdlets that VMM offers. This approach made VMM very extensible and partner friendly and allows customers to accomplish anything that VMM offers in the Administrator Console via scripts and automation. Windows PowerShell is also the only public application programming interface (API) that VMM offers, giving both developers and administrators a single point of reference for managing VMM. Writing scripts that interface with VMM, Hyper-V, or Virtual Server can be made very easy using Windows PowerShell’s support for WMI, .NET, and COM. In this chapter, you will learn to: ◆ Describe the main benefits that PowerShell offers for VMM ◆ Use the VMM PowerShell cmdlets ◆ Create scheduled PowerShell scripts VMM and Windows PowerShell System Center Virtual Machine Manager (VMM) 2007, the first release of VMM, was one of the first products to develop its entire graphical user interface (the VMM Administrator Con- sole) on top of Windows PowerShell (previously known as Monad). This approach proved very advantageous for customers that wanted all of the VMM functionality to be available through some form of an API. The VMM team made early bets on Windows PowerShell as its public management interface, and they have not been disappointed with the results. With its consis- tent grammar, the great integration with .NET, and the abundance of cmdlets, PowerShell is quickly becoming the management interface of choice for enterprise applications.
    [Show full text]
  • Object-Oriented Desgin Visitor Pattern George Blankenship 1
    Object-Oriented Desgin Visitor Pattern CSCI 253 Object Oriented Design: Visitor Pattern George Blankenship Visitor Pattern George Blankenship 1 Overview Creational Patterns Structural Patterns Behavioral Patterns Singleton Composite Chain of Respons. Abstract factory Façade Command Factory Method Proxy Interpreter Prototype Flyweight Iterator Builder Mediator Adapter Memento Bridge Observer Decorator State Strategy Template Method Visitor Pattern George Blankenship Visitor 2 The Elements of a Design Pattern • A pattern name • The problem that the pattern solves – Including conditions for the pattern to be applicable • The solution to the problem brought by the pattern – The elements (classes-objects) involved, their roles, responsibilities, relationships and collaborations – Not a particular concrete design or implementation • The consequences of applying the pattern – Time and space trade off – Language and implementation issues – Effects on flexibility, extensibility, portability Visitor Pattern George Blankenship 3 George Blankenship 1 Object-Oriented Desgin Visitor Pattern The Visitor Pattern: The Problem Represents an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates • many distinct and unrelated operations need to be performed on objects in an object structure an you want to avoid “polluting” their classes with these operations • the classes defining the object structure rarely change but you often want to define new operations over the structure Visitor Pattern George Blankenship 4 Visitor Example • The root of the structure accepts a visitor: root.accept( visitor ) • The root and every child object in the structure have a an accept method: void accept( visitor ) { visitor.visit( this ); for each child of mine child.accept( visitor ) next } • In short order our visitor gets a visit() call from each object in the collection.
    [Show full text]
  • Advanced-Java.Pdf
    Advanced java i Advanced java Advanced java ii Contents 1 How to create and destroy objects 1 1.1 Introduction......................................................1 1.2 Instance Construction.................................................1 1.2.1 Implicit (Generated) Constructor.......................................1 1.2.2 Constructors without Arguments.......................................1 1.2.3 Constructors with Arguments........................................2 1.2.4 Initialization Blocks.............................................2 1.2.5 Construction guarantee............................................3 1.2.6 Visibility...................................................4 1.2.7 Garbage collection..............................................4 1.2.8 Finalizers...................................................5 1.3 Static initialization..................................................5 1.4 Construction Patterns.................................................5 1.4.1 Singleton...................................................6 1.4.2 Utility/Helper Class.............................................7 1.4.3 Factory....................................................7 1.4.4 Dependency Injection............................................8 1.5 Download the Source Code..............................................9 1.6 What’s next......................................................9 2 Using methods common to all objects 10 2.1 Introduction...................................................... 10 2.2 Methods equals and hashCode...........................................
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]