Design Pattern-API design of ArcGIS

There were 10 months of project implementation during a business trip last year. All the work done is the extension research and development of ArcGIS.

This year, we finally have time to stop, learn new things, and summarize our knowledge. Because c ++ does not have a reflection mechanism and ArcGIS is based on the COM technology, the extension of ArcGIS is based on the COM technology. How to expand is actually to do two things. First, determine whether there are any extension points. If there is an extension point, implement the interface to be implemented and complete the methods in the interface.

What is the basis for scaling? In fact, after doing a lot of work, there will be two points. First, we will understand the common design patterns of C ++ without making assumptions.

The most important principle for writing Extension Based on Component-based development is not to make assumptions. You cannot assume that the methods in the interface return specific things in the environment. Under the general design, I only return what is needed in the client call process. In this case, the return cannot be customized. This is really hard to understand. This is because extended components can be used in any environment. problems may occur if the calling sequence or method is changed due to special features. For example, I wrote the isymbol extension component for the telecom station. The call sequence of isymbol in 9.3 is different from that of isymbol in 9.2, if there are assumptions about the sequence of method calls in the interface (which may be conducive to GDI initialization), the result will be faulty.

With regard to the model, I continue to learn and summarize in the Development of ArcGIS. In fact, ArcGIS's architecture is quite sophisticated. Some people say that they are over-designed because they did not go deep into the application extension layer.CodeDevelopers do not need to understand the design and pattern. In fact, most GIS functions are provided in ArcGIS components, users only need to learn how to call components in sequence. Most people do not care about and understand how components are written.

Understanding the ArcGIS model is also a long-term process. In fact, we can understand some product architectures through the object model diagram (OMD) provided by ArcGIS, however, it is difficult to understand the underlying architecture. I think it is most useful to study the extension examples and descriptions provided by ArcGIS. You can find many examples by searching extending ArcObjects on Google. In addition, by writing some components, you can use the VC debugger to view the detailed call details of AO interface calling. However, it is certain that a clear understanding of the model is the basis of all of these.

Several of the longest-used models of ArcGIS APIs include factory, bridge, facde, and so on. In the future, we will gradually summarize our own reverse engineering. Because ArcGIS will be closer to lightweight applications (for cloud deployment) in the future product evolution process, the product design framework will emphasize the flexibility of the architecture.