Simple factory model of C #

Recently in the study of C #, contact with the simple factory model, just started to contact the design mode is a little bit too accustomed to ... But I think I'm starting to like it ...

(a) I understand the simple factory model.

Today's learning is object-oriented, but it takes an instantiated object to perform the operation. As we need to increase the class, we need to extract the common things, put them in an abstract class, and let these subclasses inherit the abstract class. When we call specific classes, we need to instantiate them first, and the instantiation must be specific to the class. If directly instantiated, it destroys the principle of interface-oriented, the instantiation of a specific class will be based on the parent class to select all the subclasses to instantiate, so the calculation time is greatly increased. Then we need to have a place where we can choose which class to instantiate without the need for us to know how to create and invoke the class, and this is the Simple factory model (simplicity Factory pattern). In layman's parlance, there is a special class that is responsible for creating the instance process.

(ii) graphical representation of the simple factory model:

First, this pattern has three roles:

1, the factory role: the core, responsible for the implementation of the creation of all instances of internal logic (select the branch), the interface called by the outside, create the desired object.

2. Abstract class Role: The abstract parent class of the class to be created that describes the common interface common to all instances of the class. Can be an abstract class or an interface.

3, the specific class role: The specific instance object to create. They have a common parent class.

(iii) Application of simple factory model and code implementation

In a hot summer, our school suddenly came to a group of new partners, that is, a group of vending machines, distributed in every corner of the school, including our five-storey elevator mouth. When you put a coin in a cold drink, did you ever think we could write it as a simple factory model? At least I didn't learn the design pattern last summer.

When a person wants to drink inside the drink, he does not make a drink or iced, which means that the object does not have to create their own drink objects; everyone has a hobby, come to the sale of cargo before, as long as the money to put their own point button on it. This is when we abstract out the classes of some objects. For example, the person who wants to buy a drink is a class, a variety of drinks abstract into a beverage category, each beverage includes (the United States, Sprite, milk, etc.) is the specific beverage object. The UML class diagram is as follows:

We first write this abstract class, the beverage class

    Abstract a parent class role public abstract
    class Drink {public
        abstract string drinkshow ();
    }

Then there are some specific beverage subclasses, which have a common parent beverage category. have common behaviors and attributes.

Specific role
     class: Drink 
     {
         //Get a bottle of us-year public
         override string Drinkshow () {return
              "You chose the United States of America";
         }
     }
    Class Sprite: Drink 
    {
        //Get a bottle of Sprite public
        override string Drinkshow ()
        {return
            "you have selected Sprite";
        }
    }
    class Coca-Cola: Drink 
    {
        //Get a bottle of Coca-Cola public
        override string Drinkshow ()
        {return
            "you have selected Coca-Cola";
        }
    

Then set up a vending machine factory to come out with a drink:

  Now set up a vending machine factory class public classes
    drinkfactory
    {public
        static Drink Createdrink (String type)
        {
            Drink Dri=null;
            Switch (type)
            {case
                "US-year Tatsu":
                    dri = new US-year Tatsu ();
                    break;
                Case "Sprite":
                    dri = new Sprite ();
                    break;
                Case "Coca-Cola":
                    dri = new Coca-Cola ();
                    break;
            return dri;
        }
    }

The final set of test client is the main function main

static void Main (string[] args)
        {
            try
            {
                //instantiate a variety of beverages
                Drink mei-da = Drinkfactory.createdrink ("Mi-da");
                Drink Sprite = Drinkfactory.createdrink ("sprite");
                Drink Coca-Cola = Drinkfactory.createdrink ("Coca-Cola");
                Get beverage
                if (US-year!= null)
                {
                    Console.WriteLine (US-year). Drinkshow ());
                }
                if (sprite!= null)
                {
                    Console. WriteLine (Sprite.) Drinkshow ());
                }
                if (Coca-Cola!= null)
                {
                   Console. WriteLine (Coca-Cola). Drinkshow ());
                }
            catch (Exception ex)
            {
                Console.WriteLine ("You entered the error:" + ex.) message);
            }
        

The output results are as follows:

(iv) Final analysis:

Summary: The simple factory model separates the creator and the consumer, not letting the consumer create the class directly, but connecting to the factory interface. This facilitates the optimization and scalability of the software structure, and when a new beverage (product) is added, only the branch statements of the factory-created instance need to be modified, not all of them need to be redone. That is, users can create the required instances directly from the factory class when they need to, without knowing how the instance is created and how it is organized. Benefit the optimization of the whole software architecture. However, the simple factory pattern is static and cannot be inherited by the factory subclass.