PHP Factory Model use cases and analysis

This time to bring you the PHP factory model use cases and analysis, the PHP factory model use cases and analysis of the points of attention, the following is the actual case, together to see.

The factory model (Factory design pattern), as a model of creation, follows the open-closed principle, closed for modification, and open to expansion. The factory approach (Factory method) mode is to create "something". For a factory method pattern, the "thing" to be created is a product, and there is no binding between the product and the class that created it. In fact, in order to maintain this loose coupling, the customer makes a request through a factory. The requested product is then created by the factory. It can also be considered in a different way, using the factory method pattern, the requestor only makes the request, not the specific product creation.

The work of the factory

Build a factory interface first

factory.php

<?phpabstract class factory{//abstract method for creating objects protected abstract function createproduct (); The method calls the Createproduct method to return a product object. Public Function Start () {   return $this->createproduct ();}}

startmethod returns a product that invokes a createProduct method to complete the operation of the product. So the concrete implementation of the createproduct is to build and return a product object that is implemented by the products interface.

For example, products have a common approach getProperties() , the following is the corresponding product interface

product.php

<?php//Product Interface Interface product{Public function getProperties ();}

Next, we will build two factories, text factory textfactory and image factory Phptofactory

textfactory.php

<?phpinclude_once (' factory.php '); include_once (' textproduct.php '); class Textfactory extends factory{protected function Createproduct () {  $product = new Textproduct ();  return $product->getproperties (); }}

photofactory.php

<?phpinclude_once (' factory.php '); include_once (' photoproduct.php '); class Photofactory extends factory{protected function Createproduct () {  $product = new Photoproduct ();  return $product->getproperties (); }}

As you can see, in the implementation of the Factory method, the GetProperties method introduces polymorphism (polymorphism), which will return "text" or "image" using this method. The same one getProperties() has multiple (poly) different patterns (morphs), which is polymorphic. In this case, one of the forms returns the text, and the other returns the image.

You can put anything you want in the properties implementation, and the factory method design will create the object and return it to the client.

The following is the implementation of two products

textproduct.php

<?phpinclude_once (' product.php '); class Textproduct implements product{Public Function getProperties () {  Return "Here is the text product"; }}

photoproduct.php

<?phpinclude_once (' product.php '); class Photoproduct implements product{//This is the way the product has public function getProperties ( {  return "Here is the image product";}}

These two products implement an abstract approach in the product interface getProperties() ,

Customer (client)

We do not want customers to make product requests directly. In fact, we want customers to make requests through the factory factory interface. This way, if we add products or factories later, customers can make the same request to get more types of products without destroying the application:

client.php

<?phpinclude_once (' photofactory.php '); include_once (' textfactory.php '); class client{public function construct () {  $this->somephotoobject = new Photofactory ();  echo $this->somephotoobject->start (). ' <br/> ';  $this->sometextobject = new Textfactory ();  echo $this->sometextobject->start (). ' <br/> '; }} $worker = new Client ();

Run client.php and get the following results

Here is the image product
Here is the text product

Note: The client object does not make a request directly to the product, but is requested through the factory. It is important that the customer does not realize the product characteristic, but leaves the product realization to embody.

Adjust the product

The true value of design patterns is not to increase the speed of operations, but to speed up development.

If the demand changes now, need to make changes to the image products, only need to modify the corresponding product Photoproduct GetProperties method can be

Object changes look simple but the method of product getProperties() still maintains the same interface, requesting the factory to return a Property object

Add new products and parametric requests

The question is, if you want to add more images and text descriptions, is it necessary to add a new specific factory class each time you add a new area? This means adding a new plant and product to each new area. So, we introduced the parametric plant design pattern

One of the main differences between the parametric plant design pattern and the general plant design pattern is that the customer contains references to the factory and the product. In a parameterized request, the client class must specify the product, not the product factory. createProduct()the parameters in the operation are passed to a product by the customer, so the customer must point out the specific product it wants. However, this request is still sent through the factory interface factory. Therefore, although the customer contains a product reference, the customer is still separated from the product through factory.

One factory multiple products (parametric chemical plant method)

For most requests, the parametric chemical plant method is simpler because the customer only needs to process a specific factory. The factory method operation has a parameter that indicates the product that needs to be created. In the original design, each product has its own factory, do not need another transmission parameters; Product implementations depend on each product-specific plant.

New Factory interface

factory.php

<?phpabstract class factory{//abstract method for creating objects protected abstract function createproduct (Product $product); The method returns a Product object by the FactoryMethod method. Public function Start ($product) {   return $this->createproduct ($product);}}

As you can see in this new factory interface, create() and start() both require a parameter that specifies a product object, rather than a specific implementation of the product interface, you can accept a specific instance of any product.

Factory specific implementation

The concrete creator class Commonfactory createProduct() is implemented as follows

commonfactory.php

<?phpinclude_once (' factory.php '); include_once (' product.php '); class Commonfactory extends factory{protected function createproduct (Product $product) {  return $product->getproperties ();}}

This class calls the product's method GetProperties to return the products to the customer.

Product

Specific product changes will not change the original products interface, or the original code

<?php//Product Interface Interface product{Public function getProperties ();}

For example, there is now a pen product penproduct

penproduct.php

<?phpinclude_once (' product.php '); class Penproduct implements product{Public Function getProperties () {  return "Pen product"; }}

Customer clent (with parameters)

<?phpinclude_once (' commonfactory.php '); include_once (' penproduct.php '); class client{public function construct () {  $commonFactory = new Commonfactory ();  Echo $commonFactory->start (New Penproduct ()); }} $worker = new Client ();

Post-run output

Pen Products

If you develop a new product later, you only need to create the corresponding product class, and then the customer specify the desired new product, you can return the customer needs.

Summarize:

Product Change: interface unchanged

One of the great benefits of using design patterns is that you can easily make changes to your classes without destroying larger programs. The secret to making changes easily is to keep the interface intact and change the content.

Believe that you have read the case of this article you have mastered the method, more exciting please pay attention to the PHP Chinese network other related articles!

Recommended reading:

PHP Single Responsibility principle (SRP) use case resolution

PHP implementation of the red envelope amount split algorithm case detailed