Software reconfiguration and Design pattern understanding

Before working on a database query tool. The general background is that this tool requires databases, development, testing, performance, and so on across different environments. The earliest simple version, which initializes a three-library connection on the first query, is saved in the map, Subsequent queries then take out the corresponding connection construction SQL directly based on the environment type selected by the user.

As more and more of the different systems are connected, each platform to save its own connection, resulting in a sharp increase in code redundancy, last week, using a little time at night to read the << refactoring >> This book, deeply inspired, is a refactoring is to take the way of small steps to move, Under the cover of the test case, quickly change, remove the unreasonable place in the code. The other is refactoring needs to have a deeper understanding of the current and future changes in the business, knowing what the system can do and can't do. To better refactor.

Therefore, according to the characteristics of this tool, the sense of abstract factory model is more appropriate, thus, under the guidance of the abstract factory model, the key part is reconstructed, and after adding several classes, the code complexity begins to drop. The code for each access system is essentially dozens of lines, preceded by hundreds of lines, a lot of redundant code, Can only say that their previous vision too short-sighted. Also, an operation similar to a single example pattern is used. When the query is made, the key is connected according to the current environment, if the connection is closed, or if it does not exist, initialize it, and then put it in the map and return. If so, use it directly. After this change, The first query only needs to initialize a connection, which is very fast. It's also a good thing.

Thus, a reflection of the design pattern has been seen before. But I always feel that all kinds of books are quite plain, the given example also seems to be the same as the author said, but in fact, how to identify the current business in the work should be more difficult, need to be in the business change, constantly refactoring their own code, to discover, A pattern seems particularly suitable for solving this problem, whereas refactoring also requires a certain design pattern as a basis, otherwise the refactoring of the code will only stay in the extraction of public methods. Renaming. The stage of a large class of smaller classes.

Hopefully, we'll be able to take the time to develop the << Agile Software: Principles, patterns and Practices >> the book. At the meantime can really understand these patterns of occasions, think of a word, know a technical scheme of good, that you have not understood this method, only you know the deficiencies of this scheme, You really understand him, I believe that a lot of technology I do not understand. Design pattern is also, hope to understand the shortcomings of each model, refactoring the book will often turn over, can deepen the understanding of the code.