Shulou(Shulou.com)06/01 Report--

Editor to share with you the example analysis of the factory method pattern in java, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Creators and products

All factory patterns are used to encapsulate the creation of objects. The factory method pattern (Factory Method Pattern) encapsulates the process of object creation by letting the subclass decide what the object is to create. Let's take a look at these class diagrams to see what the constituent elements are:

Creator (Creator) product category another point of view: parallel class hierarchy

As you can see above, you can combine an orderPizza () method with a factory method to form a framework. In addition, the factory approach encapsulates production knowledge into individual creators, which can also be seen as a framework.

Let's take a look at these two parallel class levels and recognize their relationship:

Define the factory method pattern

The factory method pattern defines an interface to create an object, but it is up to the subclass to decide which class to instantiate. The factory method causes the class to defer instantiation to subclasses.

The factory method pattern can encapsulate specific types of instantiation. Looking at the class diagram below, the abstract Creator provides an interface to methods that create objects, also known as "factory methods." In the abstract Creator, any other implemented method may use the product made by this factory method, but only the subclasses actually implement the factory method and create the product.

Object dependency

Assuming you've never heard of the factory model, can you imagine how many specific pizza objects come from this category if you want to open a pizzeria in New York and Chicago with a variety of pizza objects? If you add another California flavor, how many people will you rely on? You might as well take a look:

Public lass DependentPizzaStore {

Public Pizza createPizza (String style, String type) {

Pizza pizza = null

If (style.equals ("NY")) {

If (type.equals ("cheese")) {

Pizza = new NYStyleCheesePizza ()

} else if (tpye.equals ("clam")) {

Pizza = new NYStyleClamPizza ()

} else if (type.equals ("pepperoni")) {

Pizza = new NYStylePrpperoniPizza ()

}

} else if (style.equals ("Chicago")) {

If (type.equals ("cheese")) {

Pizza = new ChicagoStyleCheesePizza ()

} else if (tpye.equals ("clam")) {

Pizza = new ChicagoStyleClamPizza ()

} else if (type.equals ("pepperoni")) {

Pizza = new ChicagoStylePrpperoniPizza ()

}

} else {

System.out.println ("Error: invalid type of pizza")

Return null

}

}

}

When you instantiate an object directly, you are relying on its concrete class. If you draw a picture of this version of the pizzeria and its dependent object, it looks like this:

Principle of dependency inversion

As you can see from the above, it is a good thing to reduce the dependence on concrete classes in our code. In fact, there is an OO design principle that formally illustrates this; it even has a loud and formal name: the dependency inversion principle. Rely on abstractions, not concrete classes.

This principle is similar to "programming for interfaces, not for implementation", but this principle places more emphasis on "abstraction". This principle states that high-level components cannot be made to rely on low-level components, and that both should rely on abstraction, regardless of high-level or low-level components.

The so-called "high-level" components are classes that define the behavior of other lower-level components. For example, PizzaStore is a high-level component because its behavior is defined by pizza; PizzaStore creates all the different pizza objects that are prepared, baked, sliced, and boxed; and pizza itself is a low-level component. PizzaStore relies on these specific types of pizza.

Application of principles

The main problem with being very dependent on pizzeria is that it depends on every type of pizza. Because it instantiates these specific types in its own orderPizza () method.

How do you separate the code for these instantiated objects in the orderPizza () method? As we all know, the factory method just came in handy. After applying the factory method, the class diagram is changed to look like this:

After applying the factory approach, have you noticed that both high-level components (PizzaStore) and low-level components (that is, these pizzas) rely on Pizza abstractions. The factory method is not the only skill to follow the principle of dependency inversion, but it is one of the most powerful ones.

Depending on inversion, where on earth is inversion?

Inversion in the principle of dependency inversion refers to the opposite of the way of thinking in general OO design. Looking at the diagram above, you will notice that lower-level components now rely on high-level abstractions. Similarly, high-level components now rely on the same abstraction. Previously, dependency graphs were drawn from top to bottom, but now they are inverted, and both high-and low-level modules now rely on this abstraction.

Rely on inversion, but also need to invert your way of thinking. Previously, if you needed to design a pizzeria, it would start at the top and then go down to the specific category. Now you need to reverse your ideas, don't start at the top, start with pizza, and then think of abstracting a Pizza class. And then think that you have to rely on a factory to take these classes out of the pizzeria, different pizza types can only rely on an abstraction, and the same pizzeria will rely on this abstraction.

In this way, we inverted the design of a store that relied on specific classes, and also reversed your way of thinking. However, you also need to avoid violating the principle of dependency inversion in your OO design:

Variables cannot hold references to specific classes: if you use new, you will hold references to specific classes. You can switch to a factory to avoid this practice.

Don't let a class derive from a concrete class: if it is derived from a concrete class, you will rely on it. Please derive from an abstraction (interface or abstract class)

Do not override the implemented methods in the base class: if you override the implemented methods in the base class, then your base class is not really an abstraction suitable for inheritance. The implemented methods in the base class should be shared by all subclasses

The above is all the content of the article "sample Analysis of Factory method patterns in java". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.