Java factory model-simple factory Model

When object A needs to call object B, many beginners choose to use the new keyword to create a B instance and then call the B instance method. From the perspective of syntax, there is no problem with this practice. The disadvantage of this practice is: class A directly calls the class name of Class B (this method is also called hard encoding coupling). Once the system needs to be restructured, Class C should be used to replace Class B, the program has to write class a code. If 100 or 10000 classes in the application are hard-coded and coupled with Class B, you need to rewrite 100, 10000 places ....
From another perspective: for object A, it only needs to call the method of object B and does not care about the implementation and creation process of object B. To allow Class B to implement an IB interface, Class A only needs to be coupled with the IB interface -- class A does not directly use the new keyword to create the B instance, but instead redefines a factory class: ibfactory, the factory class is responsible for creating IB instances, and Class A obtains IB instances through the ibfactory factory method.
Through the above design, Class A needs to be coupled with ibfactory and must be coupled with the IB interface. If the system needs to be restructured, Class C should be used to replace Class B, you only need to let the C Class implement the IB interface, and rewrite the implementation code of the IB instance created in the ibfactory, and let the factory generate C (implement the IB Interface) because the objects of IB instances are obtained through the factory, they are all changed to Class C instances, which completes System Reconstruction.

Out interface (equivalent abstract product ):

package com.fsti.factory.simplefactory;public interface Output {public final static Integer MAX_CACHE_LINE = 3;void getData(String str);void out();}

Printer implements the out interface (equivalent to a specific product ):

Package COM. fsti. factory. simplefactory; public class printer implements output {private string [] printdata = new string [max_cache_line]; // records the number of jobs to be printed. Private int datanum = 0; public void getdata (string Str) {If (datanum> = max_cache_line) {system. out. println ("failed to add when the output queue is full");} else {printdata [datanum ++] = STR ;}} public void out () {While (datanum> 0) {system. out. println ("printer printing:" + printdata [0]); // move the entire job to one place and reduce the number of remaining jobs to one system. arraycopy (printdata, 1, printdata, 0, -- datanum );}}}

The factory class (rather simple factory) returns the printer instance that implements the output interface:

package com.fsti.factory.simplefactory;public class OutputFactory {public Output getOutput() { return new Printer(); }}

Package COM. fsti. factory. simplefactory; // The computer class depends on the output of the interface. The computer and printer implementation classes are separated from public class computer {private output out; Public Computer (output out) {This. out = out;} public void keyin (string Str) {out. getdata (STR);} public void print () {out. out ();} public static void main (string [] ARGs) {outputfactory of = new outputfactory (); computer c = new computer (. getoutput (); C. keyin ("factory model"); C. keyin ("simple factory mode"); C. print ();}}

If the system needs to be restructured, you only need to implement the output interface of the replacement class and change the getoutput method of the outputfactory class.

Advantages
The factory class is the key to the entire model. It contains the necessary logical judgment to determine the specific class object to be created based on the information given by the outside world. By using the factory class, the outside world can get rid of the embarrassing situation of directly creating specific product objects, and only need to be responsible for "consuming" objects. You don't have to worry about how these objects are created and organized. Clarify their respective responsibilities and rights, which is conducive to the optimization of the entire software architecture.
Disadvantages
Because the factory class integrates the creation logic of all instances, in violation of the High Cohesion responsibility allocation principle, all creation logic is centralized into a factory class; the class it can create can only be considered in advance, if you need to add a new class, you need to change the factory class.
When the number of product categories in the system increases, the requirements for the factory category to create different instances based on different conditions may arise. this kind of judgment on the condition is intertwined with the judgment on the specific product type, and it is difficult to avoid the spread of module functions, which is very unfavorable for system maintenance and expansion;
These shortcomings have been overcome in the factory method model.
Use Cases 　　
The factory class is responsible for creating fewer objects;
The customer only knows the parameters passed into the factory class and does not care about how to create objects (logic;
Because simple factories are easy to violate the High Cohesion responsibility allocation principle, they are generally used only in simple cases.