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

This article mainly shows you "what is the use of the factory method model in Python", the content is easy to understand, clear, hope to help you solve your doubts, the following let the editor lead you to study and learn "what is the use of factory method model in Python" this article.

The factory method (Factory Method) pattern, also known as the virtual constructor (Virtual Constructor) pattern or the polymorphic factory (Polymorphic Factory) pattern, belongs to the class creation pattern. In the factory method pattern, the parent class is responsible for defining the public interface that creates the object, while the subclass is responsible for generating the concrete object. The purpose of this is to defer the instantiation of the class to the subclass, that is, it is up to the subclass to decide which class should be instantiated.

In the simple factory pattern, a factory class is at the center of instantiating a product class, knowing the details of each product class and deciding when which product class should be instantiated. The advantage of the simple factory model is that it can make the client independent of the product creation process, and there is no need to modify the client when a new product is introduced into the system, but the disadvantage is that when a new product is to be added to the system, the factory class must be modified to add the necessary processing logic. The Achilles heel of the simple factory pattern is the factory class at the core, because once it cannot determine which class to instantiate, it cannot be used, and the factory method pattern can well avoid this problem.

Consider such an application framework (Framework), which can be used to browse documents in various formats, such as TXT, DOC, PDF, HTML, etc., in order to make the software architecture as general as possible, two abstract parent classes, Application and Document, are defined, and customers must deal with a specific type of document through their subclasses. For example, to write a PDF file browser using this framework, you must first define two classes, PDFApplication and PDFDocument, which should inherit from Application and Document, respectively.

The responsibility of Application is to manage the Document and create them when needed, for example, when the user selects Open or New from the menu, Application is responsible for creating an instance of Document. Obviously, the specific document subclass that is instantiated is related to the specific application, so Application cannot predict which subclass of Document will be instantiated. It only knows when a new Document (When) will be created, but does not know which (Which) specific Document will be created. At this point, there will be a very embarrassing situation if you still insist on using the simple factory pattern: the framework must instantiate classes, but it only knows abstract classes that cannot be instantiated.

The solution is to use the factory method pattern, which encapsulates the information about which Document subclass will be created, and can separate that information from the framework. As shown in figure 1, the subclass of Application redefines the abstract method createDocument () of Application and returns an instance of an appropriate Document subclass. We call createDocument () a factory method (factory method) because it vividly describes the instantiation of a class, which is responsible for "producing" an object.

Simply put, the purpose of the factory method pattern is to generate various kinds of instances according to different conditions, which usually belong to multiple similar types and have a common parent class. The factory method pattern encapsulates the creation process of these instances, which simplifies the writing of client programs and improves the scalability of the software architecture, so that new subclasses can be added at minimum cost in the future. The factory method model is suitable for the following situations:

◆ when it is impossible to know which class the object that must be created belongs to, or which class will be returned, but only if these objects meet certain interface standards.

◆ when a class wants its subclasses to determine the objects it creates, its purpose is to make the program more extensible and more flexible when adding other classes.

◆ when the responsibility for creating an object is delegated to one of several help subclasses (helper subclass) and you want to localize information about which subclass is the agent.

It is important to note that creating objects using the factory method pattern does not necessarily make the code shorter (in fact, it is often longer), and more helper classes may need to be designed. but it does have the flexibility and flexibility to create undetermined objects, simplifying the logical structure of the client application and improving the readability and reusability of the code.

II. Mode introduction

Although the factory method itself is not complex, it is one of the most important design patterns, whether it is in COM, CORBA or EJB, it can be seen everywhere. One of the basic ideas of object-oriented is the reasonable allocation of responsibilities and rights among different objects. in essence, the factory method pattern is a polymorphic method (polymorphic method) used to create objects, which declares the method interface used to create objects in the abstract parent class, while concrete subclasses localize the object creation process by overriding this method, including whether to instantiate a subclass and whether to initialize it and so on. To some extent, the factory method can be seen as a specialization of the constructor, which is characterized by the ability to create different objects in a consistent way without worrying about which class is currently being instantiated, because the object of which class is created will depend on its subclasses.

Suppose we plan to develop a software for personal information management (Personal Information Manager,PIM) that can store all kinds of information needed in daily work and life, including address book, phone book, appointment reminder, schedule, and so on. Obviously, the design of the PIM user interface (User Interface) will be complex because a separate interface must be provided for the input, validation, and modification of each type of information in order to interact with the user. A relatively simple approach is to write a corresponding user interface for the processing of all kinds of information in PIM, but the cost is that the scalability of the software will be very poor, because once you want to add the function of managing other information (such as bank accounts) in the future, you must modify the PIM and add the corresponding user interface, which eventually leads to PIM becoming more and more complex, with a large structure and difficult to maintain. The way to improve it is to separate the user interface that deals with all kinds of information from PIM, so that PIM no longer cares about how users enter data, how to validate user input, and how users modify information, all of which are completed by a special software module, while what PIM needs to do is to provide an overall framework for managing these personal information.

In the specific implementation, we can design a general interface Editable, and let all user interfaces that deal with specific personal information (such as correspondence address and phone number) inherit from it, while PIM obtains an instance of Editor through the method getEditor () provided by Editable, and uses it to uniformly handle user input. For example, when the user has finished typing, PIM can call the method getContent () in Editor to get the data entered by the user, or call resetUI () to clear the data entered by the user. After adopting this architecture, if you want to extend the functionality of PIM, you only need to add the corresponding Editable and Editor without modifying the PIM itself.

Now that we are still one step away from the goal, because Editable and Editor are only generic interfaces, but PIM needs to instantiate their subclasses, it is natural to think of using the factory method pattern to define an EditableFactory interface for PIM to create Editable objects. In this way, the architecture of the entire PIM will look like figure 2.

The Editable interface defines a common constructive method (builder method) getEditor (), which returns an Editor object whose complete code is shown in listing 1. Any piece of personal information has its own independent user interface (Editor), which is responsible for obtaining data and modifying it when needed, while the only thing PIM needs to do is to obtain Editor through Editable and use it to manipulate the data entered by users.

Code listing 1:editable.py class Editable: "Common interface of the personal information user interface" # get the personal information editing interface def getEditor (self): pass

The Editor interface gives a common interface for handling all personal information, and the complete code is shown in listing 2. PIM can obtain UI components that interact with users by calling the getUI () method, which can be as simple as a text input box or as complex as a dialog box containing multiple graphical controls (Widget), depending on the personal information you are currently working on. Using the getContent (), commitChanges (), and resetUI () methods provided by Editor, PIM can also obtain, submit, or empty personal information entered by the user. With the introduction of Editor, PIM can be freed from the user interface that deals with specific personal information, thus focusing on how to manage that information in a unified way.

Code listing 2:editor.py class Editor: "" user uses a specific Editor to edit personal information "" # get the object def getUI (self) that represents the user interface (UI): pass # get the data entered by the user def getContent (self): pass # submit the data entered by the user def commitChanges (self): pass # clear the data entered by the user def resetUI (self): pass

EditableAddress is a concrete implementation of Editable, which PIM uses to process personal address information, and its complete code is shown in listing 3.

Code listing 3:editableaddress.py from editor import Editor from editable import Editable import Tkinter class EditableAddress (Editable): "Editable used to process personal address information" # constructor def _ _ init__ (self Master): self.master = master self.name = "" self.province = "" self.city = "" self.street = "" self.zipcode = "" self.editor = AddressEditor (self) # get the associated Editor def getEditor (self): return self.editor class AddressEditor (Editor) Tkinter.Frame): "Editor used to process personal address information"# Constructor def _ _ init__ (self, owner): Tkinter.Frame.__init__ (self) Owner.master) self.owner = owner self.name = Tkinter.StringVar () self.province = Tkinter.StringVar () self.city = Tkinter.StringVar () self.street = Tkinter.StringVar () self.zipcode = Tkinter.StringVar () self.createWidgets () # construct the user interface def createWidgets (self): # name nameFrame = Tkinter.Frame (self) nameLabel = Tkinter.Label (nameFrame Text= "Name:") nameEntry = Tkinter.Entry (nameFrame, textvariable=self.name) nameLabel.config (anchor=Tkinter.E, width=8, pady=3) nameLabel.pack (side=Tkinter.LEFT) nameEntry.pack (side=Tkinter.LEFT) nameFrame.pack () # Provincial provinceFrame = Tkinter.Frame (self) provinceLabel = Tkinter.Label (provinceFrame, text= "Province:") provinceEntry = Tkinter.Entry (provinceFrame, textvariable=self.province) provinceLabel.config (anchor=Tkinter.E, width=8 Pady=3) provinceLabel.pack (side=Tkinter.LEFT) provinceEntry.pack (side=Tkinter.LEFT) provinceFrame.pack () # City cityFrame = Tkinter.Frame (self) cityLabel = Tkinter.Label (cityFrame, text= "City:") cityEntry = Tkinter.Entry (cityFrame, textvariable=self.city) cityLabel.config (anchor=Tkinter.E, width=8 Pady=3) cityLabel.pack (side=Tkinter.LEFT) cityEntry.pack (side=Tkinter.LEFT) cityFrame.pack () # Street streetFrame = Tkinter.Frame (self) streetLabel = Tkinter.Label (streetFrame, text= "Street:") streetEntry = Tkinter.Entry (streetFrame, textvariable=self.street) streetLabel.config (anchor=Tkinter.E, width=8 Pady=3) streetLabel.pack (side=Tkinter.LEFT) streetEntry.pack (side=Tkinter.LEFT) streetFrame.pack () # zipcodeFrame = Tkinter.Frame (self) zipcodeLabel = Tkinter.Label (zipcodeFrame, text= "ZIP Code:") zipcodeEntry = Tkinter.Entry (zipcodeFrame, textvariable=self.zipcode) zipcodeLabel.config (anchor=Tkinter.E, width=8 Pady=3) zipcodeLabel.pack (side=Tkinter.LEFT) zipcodeEntry.pack (side=Tkinter.LEFT) zipcodeFrame.pack () # overload the method in Editor Get the object def getUI (self) that represents the user interface (UI): methods in return self # overloaded Editor Get the user input data def getContent (self): content = "Name:" + self.name.get () + "\ n" content + = "Province:" + self.province.get () + "\ n" content + = "City:" + self.city.get () + "\ n" content + = "Street:" + self.street.get () + "\ n" content + = " ZIP Code: "+ self.zipcode.get () return content # overloads the method in Editor Submit the data entered by the user def commitChanges (self): selfself.owner.name = self.name.get () selfself.owner.province = self.province.get () selfself.owner.city = self.city.get () selfself.owner.street = self.street.get () selfself.owner.zipcode = self.zipcode.get () # overload the method in Editor Clear data entered by the user def resetUI (self): self.name.set (") self.province.set (") self.city.set (") self.street.set (") self.zipcode.set (")

EditablePhone is another concrete implementation of Editable, which PIM uses to process personal phone numbers, and the complete code is shown in listing 4.

Code listing 4:editablephone.py from editor import Editor from editable import Editable import Tkinter class EditablePhone (Editable): "Editable for handling personal phone numbers"# Constructor def _ _ init__ (self, master): self.master = master self.areaCode =" Self.phoneNumber = "self.editor = PhoneEditor (self) # get the associated Editor def getEditor (self): return self.editor class PhoneEditor (Editor, Tkinter.Frame):" Editor used to process personal phone numbers "" # constructor def _ _ init__ (self, owner): self.owner = owner Tkinter.Frame.__init__ (self) Self.owner.master) self.areaCode = Tkinter.StringVar () self.phoneNumber = Tkinter.StringVar () # construct the user interface codeLabel = Tkinter.Label (self, text= "Area Code:") codeEntry = Tkinter.Entry (self, textvariable=self.areaCode) codeLabel.config (anchor=Tkinter.E, width=12, pady=3) codeLabel.grid (row=0, column=0) codeEntry.grid (row=0, column=1) numberLabel = Tkinter.Label (self) Text= "Phone Number:") numberEntry = Tkinter.Entry (self, textvariable=self.phoneNumber) numberLabel.config (anchor=Tkinter.E, width=12, pady=3) numberLabel.grid (row=1, column=0) numberEntry.grid (row=1, column=1) # overload methods in Editor Get the object def getUI (self) that represents the user interface (UI): return self # overloads the method in Editor and gets the data entered by the user def getContent (self): content = "Area Code:" + self.areaCode.get () + "\ n" content + = "Phone Number:" + self.phoneNumber.get () + "\ n" return content # overload the method in Editor Submit the data entered by the user def commitChanges (self): selfself.owner.areaCode = self.areaCode.get () selfself.owner.phoneNumber = self.phoneNumber.get () # overload the method in Editor to clear the data entered by the user def resetUI (self): self.areaCode.set (") self.phoneNumber.set (")

The EditableFactory interface is the core of applying the factory method pattern in PIM, and its complete code is shown in listing 5. Unlike the "superclass" in the simple factory pattern, which is responsible for creating all objects, EditableFactory only defines how to instantiate the factory method createEditable () of Editable, and does not control their life and death. It is the subclasses of EditableFactory that are really responsible for the creation.

Code listing 5:editablefactory.py class EditableFactory: factory class for creating Editable "" # instantiate the Editable object def createEditable (self, master): pass

EditableAddressFactory is a concrete implementation of EditableFactory, which PIM uses to instantiate EditableAddress objects, and the complete code is shown in listing 6.

Code listing 6:editableaddressfactory.py from editablefactory import EditableFactory from editableaddress import EditableAddress class EditableAddressFactory (EditableFactory): factory class for creating EditableAddress # overloads the method in EditableFactory and instantiates the EditableAddress object def createEditable (self, master): address = EditableAddress (master) return address

EditablePhoneFactory is another concrete implementation of EditableFactory, which PIM uses to instantiate EditablePhone objects, and the complete code is shown in listing 7.

Code listing 7:editablephonefactory.py from editablefactory import EditableFactory from editablephone import EditablePhone class EditablePhoneFactory (EditableFactory): factory class for creating EditablePhone # overloads the method in EditableFactory and instantiates the EditablePhone object def createEditable (self, master): phone = EditablePhone (master) return phone

Once all these helper classes are defined, you can write the PIM class, which provides a framework for unified management of a variety of personal information, with the complete code shown in listing 8.

Code listing 8:pim.py from editablephone import EditablePhone from editableaddressfactory import EditableAddressFactory from editablephonefactory import EditablePhoneFactory import Tkinter class PIM: "" personal Information Management "" # Constructor def _ _ init__ (self): mainFrame = Tkinter.Frame () mainFrame.master.title ("PIM") # Command button addressButton = Tkinter.Button (mainFrame, width=10, text= "Address") phoneButton = Tkinter.Button (mainFrame, width=10 Text= "Phone") commitButton = Tkinter.Button (mainFrame, width=10, text= "Commit") resetButton = Tkinter.Button (mainFrame, width=10, text= "Reset") addressButton.config (command=self.addressClicked) phoneButton.config (command=self.phoneClicked) commitButton.config (command=self.commitClicked) resetButton.config (command=self.resetClicked) addressButton.grid (row=0, column=1, padx=10, pady=5, stick=Tkinter.E) phoneButton.grid (row=1, column=1 Padx=10, pady=5, stick=Tkinter.E) commitButton.grid (row=2, column=1, padx=10, pady=5, stick=Tkinter.E) resetButton.grid (row=3, column=1, padx=10, pady=5, stick=Tkinter.E) # containers self.editorFrame = Tkinter.Frame (mainFrame) self.editorFrame.grid (row=0, column=0, rowspan=4) self.editorFrame.grid_configure (stick=Tkinter.N) for all kinds of Editor Pady=15) self.editor = Tkinter.Frame (self.editorFrame) self.editor.grid () # personal information display area self.content = Tkinter.StringVar () self.contentLabel = Tkinter.Label (mainFrame, width=50, height=5) self.contentLabel.configure (textvariable=self.content) self.contentLabel.configure (anchor=Tkinter.W, font= "Arial 10 italic bold") self.contentLabel.configure (relief=Tkinter.RIDGE, pady=5 Padx=10) self.contentLabel.grid (row=4, column=0 Columnspan=2) mainFrame.pack () mainFrame.mainloop () # Address button callback function def addressClicked (self): address = EditableAddressFactory () .createEditable (self.editorFrame) self.editor.grid_remove () self.editor = address.getEditor () self.editor.getUI () .grid () # Phone button callback function def phoneClicked (self): phone = EditablePhoneFactory () .createEditable (self.editorFrame) self.editor.grid_remove () self.editor = phone.getEditor () self.editor.getUI () .grid () # Commit button callback function def commitClicked (self): content = self.editor.getContent () self.content.set (content) # Reset button callback function def resetClicked (self): self.editor App UI () # main function if (_ _ name__ = = "_ _ main__"): app = PIM ()

Figure 3 shows the interface effect of PIM at run time.

III. General structure

The factory method pattern is a further abstraction and extension of the simple factory pattern, which not only maintains the advantage that the simple factory pattern can hide the instantiation process of the class from the customer, but also overcomes the disadvantage that the factory class is too complex and not easy to expand through polymorphism. In the factory method pattern, the factory class at the core is no longer responsible for the creation of all products, but leaves the specific creation to the subclasses. After functional abstraction, the core factory class in the factory method pattern becomes an abstract factory role, which is only responsible for giving the interfaces that the specific factory subclass must implement, without involving the details of which product class should be instantiated. The general structure of the factory method pattern is shown in figure 4, where only one product class and one factory class are given for simplification, but multiple product classes and multiple factory classes usually need to be designed in a real system.

The essence of the factory method pattern is to delay the creation of the object to its subclass implementation, that is, the subclass dynamically decides which product class should be instantiated according to the current situation. As can be seen from the above figure, the factory method pattern involves four participants: abstract factory role, concrete factory role, abstract product role and concrete product role.

◆ Abstract Factory (Creator) role: the core of the factory method pattern, which is responsible for defining factory methods that create abstract product objects. Abstract factories cannot be called directly from the outside world, but any factory class used to create product objects in the pattern must implement the factory methods defined by it.

Concrete Concrete Creator role: is the external interface of the factory method pattern, which is responsible for implementing the internal logic of creating specific product objects. The specific factory is closely related to the application and can be directly called by the outside world to create the desired products.

Abstract product (Product) role: the parent class of all objects created by the factory method pattern, which is responsible for describing the common interface common to all concrete products.

Specific product (Concrete Product) role: is the creation target of the factory method pattern, and all objects created are instances of a specific class that plays this role.

The abstract factory role is responsible for declaring factory methods (factory method) to "produce" abstract products. The following is an example Python code for an abstract factory:

Code listing 9:creator.py class Creator: "" abstract factory role "" # factory method def factoryMethod (self): pass to create an abstract product

The specific factory role is responsible for creating an instance of a specific product and returning it to the caller. A specific factory is related to a specific product, and a common practice in implementation is to define a specific factory for each specific product. The following is an example Python code for a specific factory:

Code listing 10:concretecreator.py class ConcreteCreator (Creator): "specific factory role" # Factory method def factoryMethod (self): product = ConcreteProduct () return product for creating a specific product

The main purpose of abstract product roles is to provide a common interface for all specific products, usually with a corresponding declaration rather than a specific implementation. The following is an example Python code for an abstract product class:

Code listing 11:product.py class Product: "" Abstract product roles "" # Common interface def interface (self) for all product classes: pass

The specific product role serves as the ultimate creation goal. generally speaking, it is a subclass of the abstract product class, implements all the factory methods defined in the abstract product class, and usually has more complex business logic in practical application. The following is an example Python code for a specific product class:

Code listing 12:concreteproduct.py class ConcreteProduct (Product): "specific product roles" # implementation of the public interface def interface (self): print "ConcreteProduct Method"

When applying the factory method pattern, you usually need to introduce another client role, which is responsible for creating a specific factory object, and then calling the factory method in the factory object to create the corresponding product object. The following is the sample Python code for the client:

Code listing 13:client.py class Client: "" client role "" def run (self): creator = ConcreteCreator () product = creator.factoryMethod () product.interface () # main function if (_ _ name__ = = "_ _ main__"): client = Client () client.run ()

In this simple schematic implementation, there is only one class that acts as a specific product and a specific factory, but in real practical applications, it is usually encountered that there will be multiple specific product classes at the same time. At this time, it is necessary to provide multiple specific factory classes, and each specific factory is responsible for producing the corresponding specific products.

The activity sequence of the factory method pattern is shown in figure 5. The client Client first creates the ConcreteCreator object, and then calls the factory method factoryMethod () of the ConcreteCreator object, which is responsible for "producing" the required ConcreteProduct object.

IV. Practical application

Using the factory method pattern can introduce new products without modifying specific factory roles, which undoubtedly makes the factory method pattern more extensible than the simple factory model. When developing an actual software system, the product role is usually designed before the factory role is designed, and complex requirements lead to a very large tree structure between abstract and concrete products, as shown in figure 6.

In the above product hierarchy, there is more than one abstract product class and more than two class levels, which is often encountered in constructing real systems. When applying the factory method pattern to this software architecture, it is common to design the same factory hierarchy according to the hierarchical structure of the product, as shown in figure 7.

The purpose of defining the factory role is to create the corresponding product role, so the architecture of the entire system will look like figure 8. This structure, often referred to as a parallel class hierarchy (parallel class hierarchies), enables one class to delegate some of its responsibilities to another independent class, while the factory method is the link between the two. The factory method model does not limit the number of product levels. Although there are only two levels (abstract product layer and concrete product layer) in the general structure given above, more complex product levels are often needed in practical application.

In the general structure of the factory method pattern, whenever a factory method in a specific factory class is requested, the constructor of the specific product class is called to create a new product instance, which is then provided to the client. However, when the factory method pattern is applied to a real software system, what the factory method does may be more complex, and one of the most common situations is to recycle product objects. The strategy adopted is to register all product objects created by the factory object into an object pool (object pool), so that whenever the customer requests the factory method to create the corresponding product object, the eligible product object can be queried from the object pool first, and if there happens to be such an object in the object pool, the product object can be directly returned to the client. If there is no such object in the object pool, create a new product object that meets the requirements, register it in the object pool, and then return it to the client.

The factory method model depends on the polymorphism of factory role and product role, but in practical application, this model may degenerate, which is characterized by the loss of polymorphism. In the factory method pattern, all concrete factory objects should share an abstract superclass, or in other words, multiple concrete factory classes should exist in the factory hierarchy as subclasses of an abstract factory class. but if there is only one concrete factory class in the factory hierarchy, the abstract factory role can be omitted. When the abstract factory role is omitted, the factory method pattern is degraded, which is represented by the loss of factory role polymorphism, and the degraded pattern can still play the role of part of the factory method pattern, which is often referred to as the degraded factory method pattern. The degraded factory method pattern is largely similar to the simple factory model, as shown in figure 9, which can be replaced by a simple factory model in practice.

In the factory method pattern, what is returned from the factory method should be an abstract product type, not a specific product type, because this is the only way to ensure the polymorphism of product roles. That is, clients that call factory methods can program against abstract product classes without having to rely on specific product classes. In practical application, there may be a very special situation, that is, the factory method only needs to return a specific product class, and the function of the factory method pattern will also be degraded, but this degradation will show the loss of product role polymorphism, as shown in figure 10. Strictly speaking, when the factory method pattern degenerates, it can no longer be called the factory method pattern, because the client can determine what type of object it is going to get from the static type of the factory method. This just goes against the original intention of the factory method pattern.

V. advantages and disadvantages

In the factory method pattern, the factory method is used to create the product that the customer needs, while hiding the details of which specific product class will be instantiated from the customer. The core of the factory method pattern is an abstract factory class, and various concrete factory classes inherit factory methods from the abstract factory class, so that customers can only care about abstract products and abstract factories, regardless of which concrete product is returned or how it is created by the concrete factory.

Polymorphic design based on factory role and product role is the key to the factory method pattern, which allows the factory to determine which product object to create, and the details of how to create the object are completely encapsulated in the specific factory. The factory method pattern is also called the polymorphic factory pattern, obviously because all concrete factory classes have the same abstract parent class.

Another advantage of using the factory method pattern is that when adding new products to the system, there is no need to modify the interface provided by the abstract factory and the abstract product, but only to add a specific factory and specific product. There is no need to modify the client, and there is no need to modify other specific factories and specific products. The scalability of the system is very good. Excellent object-oriented design encourages the use of Encapsulation and Delegation to construct software systems, while the factory method pattern is a typical example of encapsulation and delegation, where encapsulation is embodied through abstract factories, while delegates are represented by abstract factories that delegate the responsibility of creating objects entirely to concrete factories.

The disadvantage of using the factory method pattern is that when you add a new product, you need to write a new specific product class and provide a corresponding specific factory class. When both are relatively simple, the extra cost of the system is relatively large.

The above is all the content of the article "what is the use of factory method patterns in Python". 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.