Last active
December 29, 2021 16:38
-
-
Save AmrMekkawy/be4af29a92b44e83d200a2ccf7f0f26c to your computer and use it in GitHub Desktop.
Factory Method Design Pattern - Conceptual Example in PHP
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<?php | |
# Source: https://refactoring.guru/design-patterns/factory-method/php/example#example-0 | |
namespace RefactoringGuru\FactoryMethod\Conceptual; | |
/** | |
* The Creator class declares the factory method that is supposed to return an | |
* object of a Product class. The Creator's subclasses usually provide the | |
* implementation of this method. | |
*/ | |
abstract class Creator | |
{ | |
/** | |
* Note that the Creator may also provide some default implementation of the | |
* factory method. | |
*/ | |
abstract public function factoryMethod(): Product; | |
/** | |
* Also note that, despite its name, the Creator's primary responsibility is | |
* not creating products. Usually, it contains some core business logic that | |
* relies on Product objects, returned by the factory method. Subclasses can | |
* indirectly change that business logic by overriding the factory method | |
* and returning a different type of product from it. | |
*/ | |
public function someOperation(): string | |
{ | |
// Call the factory method to create a Product object. | |
$product = $this->factoryMethod(); | |
// Now, use the product. | |
$result = "Creator: The same creator's code has just worked with " . | |
$product->operation(); | |
return $result; | |
} | |
} | |
/** | |
* Concrete Creators override the factory method in order to change the | |
* resulting product's type. | |
*/ | |
class ConcreteCreator1 extends Creator | |
{ | |
/** | |
* Note that the signature of the method still uses the abstract product | |
* type, even though the concrete product is actually returned from the | |
* method. This way the Creator can stay independent of concrete product | |
* classes. | |
*/ | |
public function factoryMethod(): Product | |
{ | |
return new ConcreteProduct1(); | |
} | |
} | |
class ConcreteCreator2 extends Creator | |
{ | |
public function factoryMethod(): Product | |
{ | |
return new ConcreteProduct2(); | |
} | |
} | |
/** | |
* The Product interface declares the operations that all concrete products must | |
* implement. | |
*/ | |
interface Product | |
{ | |
public function operation(): string; | |
} | |
/** | |
* Concrete Products provide various implementations of the Product interface. | |
*/ | |
class ConcreteProduct1 implements Product | |
{ | |
public function operation(): string | |
{ | |
return "{Result of the ConcreteProduct1}"; | |
} | |
} | |
class ConcreteProduct2 implements Product | |
{ | |
public function operation(): string | |
{ | |
return "{Result of the ConcreteProduct2}"; | |
} | |
} | |
/** | |
* The client code works with an instance of a concrete creator, albeit through | |
* its base interface. As long as the client keeps working with the creator via | |
* the base interface, you can pass it any creator's subclass. | |
*/ | |
function clientCode(Creator $creator) | |
{ | |
// ... | |
echo "Client: I'm not aware of the creator's class, but it still works.\n" | |
. $creator->someOperation(); | |
// ... | |
} | |
/** | |
* The Application picks a creator's type depending on the configuration or | |
* environment. | |
*/ | |
echo "App: Launched with the ConcreteCreator1.\n"; | |
clientCode(new ConcreteCreator1()); | |
echo "\n\n"; | |
echo "App: Launched with the ConcreteCreator2.\n"; | |
clientCode(new ConcreteCreator2()); | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment