Atitit. Software compatibility Principles and practices V5 Qa2.docx

Atitit. Software compatibility Principles and practices V5 Qa2.docx

1. Keyword2

2. Principles for improving compatibility 2

2.1. What and how to separate 2

2.2 Old way, new method, only added, less modification, MO Delete 2

2.3. The plan can not catch up with changes, and forever API modification will not be uniform, but the risk of incompatibility 2

3. The importance and negative of compatibility 2

4. Architecture and Module Compatibility 3

4.1. Minimize particle size, get the best flexibility 3

4.2. Multiple sets of ui/xx modules, how to be compatible with 3

4.3. If you plan a new module, the old module can not modify the synchronization, recommend the new model to go well. 3

4.4. Page level, scene level configuration, IOC configuration 3

4.5. Compatibility with multiple languages 3

5. API Compatibility 3

5.1. What criteria should be used to create a new API??? 4

5.2. Add new API instead of modifying old Api4

5.3. Threadlocal4

6. Interface Compatibility 4

6.1. The new interface to inherit the original interface, the new method is declared in the sub-interface. This will keep 100% forward compatible 4

6.2. Modify the interface (a new interface should be released to cure the old interface 5

7. Web compatibility (js,html), the implementation of different projects of the same source code 5

7.1.15.1. different projects with different instance launches 5

7.2.15.2. different project and instance profiles 6

7.3.15.3. what about Web. 6

7.4.15.4. jump to different implementations of the same functional spec 6

7.5.15.5. The same functionality for different projects can be placed in the same parent module package under 6

8. Database table Compatibility 7

8.1. 2. Extended Table Mode 7

9. Compatibility Policy 7

9.1. 3. Simultaneous operating mode 7

9.2. 3.1. Perfect back compatibility 8

9.3. 3.2. Virtual machine Mode 8

9.4. 3.3. Version compatibility mode 8

9.5. 4. Forward compatibility (sufficient room for upgrade)9

9.6. 5. "Forward compatible" concept 9

9.7.6. List of specially processed software 9

9.8. Atitit. Compatibility "One plus three" policy (not recommended) 10

Ten. Ref10

1. Keyword

How to improve software compatibility with Game API upgrade

2. Promotion of compatibility principle 2.1. What is separated from how?

For example, UI, using the DSL HTML5 CSS to define the UI, do not use the native WinForm-style 3GL language

Back end, data manipulation using linq,sql, do not write yourself a watt of code, troublesome.

Other such as games, use interface mode: Define some APIs when DSLs, using implementations to different implementations:

For example, the definition scenario of cocos, very troublesome

Add BG

var size = Cc.director.getWinSize ();

This.bgsprite = new CC. Sprite (Res. Background_png);

This.bgSprite.attr ({

X:SIZE.WIDTH/2,

Y:SIZE.HEIGHT/2,

});

This.addchild (this.bgsprite, 0);

With DSL HTML5 easy to go, there are also standard DW IDE support: Visual UI design. It is convenient to implement the end multiplicity after the construction, does not affect the user.

<div style= "Background:url (xxxxx.jpg); x:0; y:0 "> </div>

The backend parses this HTML DSL definition, generating the canvas object walking OK ... 2.2. old way, new method, only added, less modification, MO delete 2.3. The plan can't keep up with the change, and the API modification will never uniform, but it brings the risk of incompatibility. 3. the importance and negative of compatibility

Java and C # compatibility go very well, win is also very concerned about compatibility ...

The negative, there are also ah. Python3, Cocos2d-js v3.x's problem

4. Architecture and Module compatibility

4.1. Minimize particle size, get the best flexibility 4.2. multiple sets of ui/xx modules, how compatible

If there are different UI patterns due to historical reasons, or different implementations of the project, do not force the unification and will greatly destroy the compatibility.

Should choose a UI as standard, and as far as possible as the H5 standard such as open standards to align, encounter problems, good Baidu AH. Supplemental can use the WPF standard .....

In the new document is recommended new standard on OK ... The old API is slowly used by people who go to Little blue.

4.3. If you plan a new module, the old module can not modify the synchronization, recommend the new model to go well . 4.4. page level, scene level configuration, IOC configuration

For example, the A module uses BCD three modules, and the P1 interface uses the traditional a module

Now there is a new D2 module, the new P2 interface to use the D2 modulus, swollen do?? Use page-level configuration walk OK. Specify a module to use the BcD2 module walk OK. Does not affect the P1 interface

4.5. compatibility with multiple languages

For example, an engine that has multiple languages of 5. API Compatibility

5.1. What criteria should be used to create a new API???

Simple, the use of the world's popular, standardized standard walk OK.

For example UI, the use of the H5 standard, not enough to supplement the use of WPF, the advantage is that more information ah, you can not need to write API documentation, direct use of this standard data walk OK, data enough.

Back-end Language API???  Using popular Java, JS, can complement C # style pull. C + +, obj-c not recommended. 5.2. adding a new API instead of modifying the old API

It is best to add new APIs: This does not need to adjust the old API. Add Test work ...

Of course some small tweaks can be adjusted directly to the old API

Some must modify the old API, can become API0 mode, in the new API call can be. To modify the bug pattern:

The new API can be named in xxxV2 mode so that it can be compatible with the old API.

5.3. Threadlocal

It also has a number of similar ways to use, that is, there are a lot of dynamic calls at the framework level, the call process needs to meet some protocol, although the Protocol we will try to be common, and many of the extended parameters in the definition of the protocol is not easy to consider full and the version is also ready to upgrade, However, when the framework expands, it also needs to satisfy the commonality and backward compatibility of the interface, and some of the expanded content we need threadlocal to do simple and convenient support.

To put it simply, threadlocal is a simple definition of some of the complex system extensions, making it very easy to relate the associated parameters, and here are some examples:

6. Interface Compatibility

6.1. new interface to inherit the original interface, the new method is declared in the sub-interface. This will keep the 100% forward compatible

Interfaces and abstract classes are similar in C # and Java, where the differences between interface design and abstract class design are mentioned. If you change the design of an interface, such as adding a method, users who use your previous code will have to change their code otherwise they cannot run and compile. But if it is an abstract class, you can provide a method with a default implementation, and the user's code does not need to be changed.

Annotations: This fact is the same in both Java and C #. However, the selection of interfaces and abstract classes (even if they include skeleton classes) is not the basis for this, it is just a performance. Again, once the interface is released, it is your commitment to the outside. Even the version upgrade can no longer make any changes, even adding new methods. That's not going to increase. If the same skeleton class is also controlled in your hand, you can do this by using the skeleton class (which is actually a usage of the abstract class, the skeleton class implements the interface, the actual class inherits the skeleton class, the skeleton class can implement some common, or default methods for the actual class) to provide a new method of the default implementation to achieve the purpose. This is not advisable, however, because the new methods that need to be added to the version upgrade are often real methods of doing things, and giving a default implementation in a skeleton class is often meaningless. A better approach is to write a new interface to inherit the original interface and declare the new method in the sub-interface. This keeps the 100% forward compatible, and the class that needs to implement the new method belongs to the class that accompanies this interface upgrade or will be implemented later. 6.2. Modifying the interface (a new interface should be released to cure the old interface

Public interface, once the conference, it should not be changed. If you want to add a new method, you should post a
The new interface:

There are several

Author:: Nickname: Old Wow's paw (full name:: Attilax Akbar Al Rapanui Attilaksachanui)

Kanji Name: Etila (Ayron), email:1466519819@qq.com

Reprint please indicate source: Http://blog.csdn.net/attilax