Use typescript to rewrite the JavaScript tank Wars Game Code _ basics

SOURCE download

Source I have uploaded to CSDN, no need for resources, download address: http://download.csdn.net/detail/zgynhqf/8565873.

The source code is developed using VS 2013 +typescript 1.4. When opened, displays the following figure:

Jstankgame 1.0: The old use of JS prepared tank game.

Jstankgame 2.0: New use of TS direct translation of the game.

Jstankgame: On the basis of 2.0, the new game after refactoring the type.

Refactoring steps

Because the old JS game is the use of MS Ajax Client Library to build, and adopted a OOD way to design, plus typescript can be compatible with all the code JS. Therefore, the use of typescript to migrate the work is relatively simple, mainly replace the type design code: Class, inheritance, interface and so on.

When you're done, you get the 2.0 version that you wrote with TS. There are many benefits of a strongly typed language in the process, and of course there are some things that TS are not perfect at the moment (later).

Got a strongly typed version of 2.0 after, and did not end. To experience the benefits of strong typing for refactoring, I decided to refactor the code structure on top of this version.

With strongly typed code, I can easily analyze each type, each method, and where it is used. In this way, I can quickly understand the dependencies between types. Do not see do not know, a look startled. Before the 1.1 point of the code written by heart, the thought of the type design is good, the coupling should not be very high. But after the picture is over, only to discover and imagine nearly very far, this is not drawing directly to write code results, see the following two pictures:

It can be seen that the relationship between the wizard types is more chaotic, two-way dependence is everywhere. (In fact, because the picture is drawn to another picture, it shows no more complex and spritemanager relationship.) ）

As a result, I plotted a new diagram, and then I reconstructed all the code by this relationship. This will be the latest version of 3.0.

The new version of the type diagram is as follows:

Layered:

Elves:

Organizer:

At the code level, the main point is that the code that is coupled between the sprites is ported to the top manager. At the same time, define the event for the wizard to remove the wizard from the direct coupling of the manager.

The pros and cons of the TS first experience

Advantage: The LAMBDA solves the problem of this pointer very well. Chrome, IE can directly debug typescript! The process also found errors that were not discovered by the weak type. The original code has not been modified because of renaming. (Spritemanager.js 98 lines)

Disadvantage: Development environment-There is no integrated Code annotation feature, only manual copy. Development environment-Code Snippets is not currently supported. Development environment-Keyword code generation is not supported: if, while, swith, bracket matching, and so on. Development environment-the definition of code region is not supported (Region). Syntax-the definition of an event is not supported. Syntax-defining overloaded methods for a class is not currently supported. See Spritebase.iscollided method.

Other:

The compiled JS code has a certain amount of redundancy. The command space is particularly noticeable. Overriding the base class method without prompting. The Property Picker/setup for the base class cannot be overridden. Cannot tell which methods are virtual methods. Cannot define a read-only property in an interface. There are also bugs. (Spritemanager.ts line 93). If you define a field that is a numeric type, the default value is not 0, but NaN.

Summarize

Overall, after a trial, I feel TS to the current version of 1.4, already can be used for the formal large-scale JS project development. But there are plenty of places to improve!

Attach Chrome, IE debug TS screenshot:

The above mentioned is the entire content of this article, hope to be able to master typescript to be helpful to everybody.