Java design pattern: Analyzing abstract factory pattern from Starcraft 1

Abstract Factory mode is one of the Creation modes. There are four creation modes: factory mode (Abstract Factory, factory method), generator mode, single mode, and prototype mode. The following is a brief analysis of the abstract factory model.

The definition of the abstract factory mode is to create an interface that provides a series of related or mutually dependent objects without specifying their specific classes. All the creation modes have a feature. We don't care about the type of the specific object produced by the factory. We will separate the specific class from the factory. The following is an example of Starcraft.

In Starcraft games, human barracks can produce two types of troops: machine guns and flame soldiers. Machine guns can be attacked by machine guns and flame soldiers can be attacked by fire guns. We need to build a barracks to produce these two types of troops, and they all have their own attack methods.

The Java code is as follows:

Interface SoldierFactory {Soldier ProduceMarine (); Soldier ProduceFirebat ();} interface Soldier {void attack ();} class Marine implements Soldier {public void attack () {System. out. println ("Gunshots scanning with machine guns") ;}} class Firebat implements Soldier {public void attack () {System. out. println ("using a firegun to launch an attack") ;}} class Barracks implements SoldierFactory {public Soldier ProduceMarine () {System. out. println ("generate a GUNSHOTS"); return new Marine ();} public Soldier ProduceFirebat () {System. out. println ("generating a firegun"); return new Firebat () ;}} class Demo {public static void main (String [] args) {Barracks myBarrack = new Barracks (); Soldier marine = myBarrack. produceMarine (); Soldier firebat = myBarrack. produceFirebat (); marine. attack (); firebat. attack ();}}

The SolderFactory interface of the abstract factory declares two methods: generate a machine gun and generate a flame soldier. Each Soldier can attack, so they all inherit from the Soldier interface. We have defined the Marine and Firebat classes to implement these two types of military actions. Finally, we define a Barracks class for the production of weapons, and implement the methods in SolderFactory, which implement the production of machine guns and flame soldiers in ProduceMarine and ProduceFirebat respectively, and return it as the return value of the method.

In the main method, we can see that we first instantiate a barracks myBarracks, and then use ProduceMarine and ProduceFirebat to implement the production of arms, at last, we can call the attack method of the military to let them attack in their own way.

Note that when we declare the marine and firebat objects, we always use the Soldier interface to define them, rather than using their specific classes (Marine and Firebat). Why? The main reason is to achieve separation and reduce the code coupling. In addition, there may be other methods for the Marine and Firebat classes. If Soldier is used for declaration, the attack method will only be exposed to us.

The shortcomings of the abstract factory model are also obvious. Suppose we want to add Ghost agents (Ghost, also known as the atomic bomb) and medical soldiers to the factory, we have to modify SoldierFactory to add the ProduceGhost and ProduceMedic method declarations for it, this is not conducive to our expansion. That is to say, it is difficult to support new types of products.