The Clean Architecture in php

class
Document
{
public function
createPage
() {
return new
Page();
}
}
In this example, we have a simple
createPage()
method on
Document
which returns a new page.
However, if we want to be able to create multiple different types of documents, we could make
this an abstract class:
abstract class
AbstractDocument
{
public function
render
() {
$this
->
addPage
(
1
,
$this
->
createPage
());
}
public function
addPage
(
1
, AbstractPage) {
// ...
}
abstract public function
createPage
();
}
Now if we wanted to create a
ResumeDocument
and a
PortfolioDocument
:
class
ResumeDocument
extends
AbstractDocument {
public function
createPage
() {
return new
ResumePage();
}
}
class
PortfolioDocument
extends
AbstractDocument {
public function
createPage
() {
return new
PortfolioPage();
}
}
Of course, we need those subordinate objects being created by the factory methods:
interface
PageInterface {}
class
ResumePage
implements
PageInterface {}
class
PortfolioPage
implements
PageInterface {}
The benefit of using a factory method like this is that it allows us to keep the bulk of our common
functionality within the
AbstractDocument
class, as it’s inherent to both
ResumeDocument
and

---

Design Patterns, A Primer
22
PortfolioDocument
, but not have
AbstractDocument
reliant on the actual concrete document
it’s working with.
Whenever
AbstractDocument
needs to generate a new page for whatever concrete it’s part of, it
simply calls
createDocument()
and gets one.
The factory pattern works best when a class doesn’t know which type of objects it is working
with and needs to create.
Abstract Factory Pattern
According to the Gang of Four, the intent of the Abstract Factory Pattern is to:
Provide an interface for creating families of related or dependent objects without
specifying their concrete classes.
With the Abstract Factory pattern, we’re interested in devising a solution to handle the creation
of multiple different related objects, when the type of objects that need to be created isn’t known.
The Abstract Factory Pattern typically has several different players:
1. Client Code, which is an object or code that needs to use the factory to create other objects
2. Object Interface, which defines the structure of the actual objects to be created
3. Concrete Objects, which implement the Object Interface with specific implementation
details
4. An Abstract Factory, which declares an interface to define how objects (Object Interfaces)
should be created
5. Concrete Factories, which implement the Abstract Factory interface and create specific
types of objects (Concrete Objects)
Let’s say we are writing some code to generate various different makes and models of cars, but
we want the code to be adaptable to anything we throw at it.
Let’s say we have a
Building
class that is responsible for generating a specific car manufacturer’s
line. This is our Client Code: