Use abstract Factory mode to solve tight coupling and difficult maintenance problems in legacy code

Landlord work Unit is a European company, main luxury production and sales, we have a PLM (Product Lifecycle Management System), used to manage product master data, such as the Department of goods and materials from design to production, and BOM and other master data management, our procurement platform is Enovia, Of course, we have done a lot of deep customization in this system to meet the special needs of our enterprise, anyone who has built an enterprise-class system knows that a system is not independent, it often needs to interact with other systems to work together, our PLM system is the same, we build the system with SOA architecture, Each system focuses on its own services, the system and the system with the use of Web service technology to interact, Web service is based on the HTTP protocol and XML, we know that the HTTP protocol and XML data Interchange Format is platform independent, so that we can go through the web Service to achieve heterogeneous systems (cross-platform cross-language) interaction, our PLM system is no exception, we need not only the master data in the form of XML transmission to SAP, and PLM will be with the supplier's dam system to maintain communication, because some of our products are sourced from suppliers, Suppliers can send images of parts to the PLM system through the dam system, and we'll talk about PLM and SAP data interaction implementations today.

The above said with the design pattern seems to have nothing to do, but actually not, I hope that through the complete description to let everyone understand the ins and outs of the problem, or just provide problems and solutions, we read after the confused.

First of all, the PLM is how to send data to SAP, I use the UML activity diagram to describe the process (the first time to draw the activity diagram, the mind is a little nervous:))

The part that I want to refactor today is the first step in PLM for generating XML implementations. In accordance with the company's regulations, the company welcomes constructive advice, but you must write a detailed plan before the production system implementation and in the test system implementation, and finally the program documents, implementation code and test reports to the PLM manager to review, after approval can be published to the formal system.

Before, the European Enovia consultants (those consultants are very advanced, but do not seem to pay attention to OO design, entirely in accordance with the process-oriented thinking to write code) in order to try not to create new Java classes, the Pojo, interface and factory method implementation are all written in a class, now with the increase in business code volume , we have a super big factory method, counting up that method has 2278 rows! And if you do not improve now, the number of lines of code will be more, the factory method can solve some coupling problems, but the implementation of all interfaces, Pojo and factory methods in a class, the shortcomings of this method is obvious:

1. The plant method is difficult to maintain and violates the principle of high cohesion and low coupling in OO design.

2. If the user has new requirements such as adding an XML segment to the PLM-generated XML file, it is difficult to locate exactly where it should be changed.

3. Even more funny, we did not find that there are 3 duplicate code blocks in the code!

In summary, the current strategy is detrimental to the maintainability, scalability, and maintainability of the PLM export function, because the consultant uses a factory approach model to handle situations where this factory approach is not competent.

So how to solve this situation?

I think the use of abstract Factory mode + Factory method mode can effectively solve this problem, first of all to look at the class diagram:

Abstract product classes and their specific implementation classes:

Abstract Factory method classes and their specific implementation classes:

The first thing I want to do is to separate the interfaces that were previously defined in the Super class into an abstract class of abstract products, and then divide the previous large factory method into 25 small classes based on different blocks of code, and the second part is to define an abstract factory interface, There is a create method in the interface that is responsible for creating those 25 objects according to MethodName, which has a concrete implementation class, and the Create method of the implementation class still uses the factory method pattern. Unfortunately currently Enovia kernel JDK is still 1.6, I can not use switch (String), only use ugly if...else ... To solve it.

I sent the refactoring program document, implementation code and test report to the PLM project manager in Europe for review, and I didn't expect it to be approved because I had previously suggested some decoupling and performance improvements to the project, but the PLM manager was a more conservative person (that is, the fear of Change) Every time, so it has hit me a lot of enthusiasm, but this time I do not know why, less than half an hour he replied to me:

I like your proposal implement it thanks

I was in a very emotional mood.

The next step is to extract the static maps that are hard-coded in the code into the resource files so that when Tomcat is started, it can load the resources into memory and improve the efficiency of reading.

Use abstract Factory mode to solve tight coupling and difficult maintenance problems in legacy code