[Translation] Chapter 1-an introduction to ASP. net mvc (2)

Original article address: Chapter 1-an introduction to ASP. NET MVC
Avoiding code smells

If you are not very careful, the software program will soon become very difficult to change accordingly. We all once had this experience, taking over an application from someone else, and then being asked to make changes to it. Think back to your worries and fears before making the first change.

In this baton game, you must remove the baton from the heap without affecting other baton. A tiny error may be huge for a bunch of baton.

Modifying an existing software application is similar to a baton game. When you fix an error, a bug is introduced.

Bad software is hard to cope with changes. Robert and Micah Martin describe the characteristics of bad software as code flavor. The following code indicates the bad software code:

· Rigidity-rigid software means that when you change a place, you also need to change many other places.

· Fragile-a vulnerable software means that after you make a change, the software will crash in multiple places.

· Unnecessary complexity-unnecessary complexity means that the software is overly designed to solve any possible changes.

· Unnecessary repetition-unnecessary repetition refers to the inclusion of repetitive code in the software.

· Obscure-Obscure software is hard to understand.

* ** Begin note ***

These codes taste in the agile principles, patterns, and works by MICAH and Robert Martin.
Practices in C # is mentioned on page 1 and is strongly recommended.

* ** End note ***

Note that the taste of these codes is related to changes. Any of these codes is an obstacle before a change.

Software Design Principles

The software does not have to be poorly written. You can design the software at the beginning so that it can better cope with subsequent changes.

The best strategy for making the software easily respond to changes is to make the software components loosely coupled. In a loosely coupled application, you can modify a component of the Program without affecting other components.

Over the years, some principles have emerged to develop good software. These principles can reduce the degree of dependency between different parts of the software. These
Principles are collected by Robert Martin in his books.

Robert Martin did not invent these principles. He was the first to collect these principles into a simple list. The following is his list of software design principles:

· SRP-single Responsibility Principle

· OCP-Open-Close Principle

· LSP-liskov replaceable Principle

· ISP-interface isolation principle

· Dip-Dependency inversion principle

This set of principles is widely referred to as solid (yes, solid is the abbreviation of the first letter of each principle ).

For example, according to the single responsibility principle, a class should have only one reason to cause changes. The following is an actual example of how to apply this principle: If you know that you may change the verification logic of the program, the verification logic is independent of its data access logic, then, you should not put the authentication and data access logic in a class.

* ** Begin note ***

There are other lists of software design principles. For example 《Head first design patternsIt also contains a very good list.

* ** End note ***

Software Design Patterns

The software design pattern is the embodiment of the application software design principle. In other words, the software design principle is a good idea, and the design pattern is a tool to realize this idea (it is a drum ).

The idea of the design model was initially 《Design Patterns: Elements of reusable object-oriented softwareThis book, also known as the "four-person group" or the "four-person group", affects many other books about software design patterns.

Compared with the four-person book ,《Head first Design PatternIt provides a more user-friendly introduction to design patterns. This book focuses on 14 models, such as observer, facade, single piece, and adapter.

Another influential book in the field of software design patterns is Martin Fowler's 《Patterns of enterprise application architecture. This book has a support website that provides all the modes involved in the book. The website address is http://www.martinfowler.com/eaacatalog /.

The software design pattern makes your code easier to change. For example, in many parts of this book, we use the repository mode in the design pattern. In his book domain-driven design, Eric Evans describes the repository mode as follows:

A repository represents all objects of a specific type. A specific type is a conceptual set (typically simulated ). It is similar to a set in operations, but contains more complex query capabilities. Specific types of objects can be added and deleted. These insertion and deletion operations are performed by operating the database (refer to page 151 ).
Note: This text translation may not be accurate. In my personal understanding, repository is equivalent to a layer between the application layer and the data layer. It provides persistent data to the application layer and manages persistent data to the data layer. Attached Original article: A repository represents all objects of a certain
Type as a conceptual set (usually emulated). It acts like a collection, cannot
With more elaborate querying capability. Objects of the appropriate type are
Added and removed, and the machinery behind the repository inserts them or
Deletes them from the database. (See page 151.

According to Evans, one of the main advantages of the Repository mode is that it enables you to "decouple applications, Domain Design and persistence layer technologies, multi-database policies, or multiple data sources" (ibid). In other words, repository
You can protect your applications when the database access mechanism changes, so that the applications are independent from the database access method.

For example, when we write Forum applications at the end of this book, we use the repository mode to isolate Forum applications and specific persistent layer technologies. With this design method, Forum applications can switch between different access salvation, such as switching from LINQ to SQL, Entity Framework or even nhib.pdf.

Writing Unit Tests for your code

By using software design principles and patterns, you can create software that is easier to cope with changes. Design Patterns are architectural patterns that focus on the overall structure of applications.

If you want to show that your program can respond to changes at a finer level, you can build unit tests for your application. Unit testing allows you to determine whether the methods in the program run as intended.

You can get many benefits from writing unit tests for your code:

1) Writing and testing your code can provide you with a security environment for changes.

2) writing tests for your code forces you to write loosely coupled code.

3) writing a test for your code forces you to look at the code from the user's standpoint.

First, unit testing provides you with a secure environment to respond to changes 《Working extends tively with legacy codeAs I have repeatedly stressed in, in fact, he defines the legacy code as "simple code without testing" (see XVI ).

When your application is covered by unit tests, you can modify the code without worrying that the changes will damage the code function. Unit testing allows you to refactor your code securely. If you can refactor your code, you can use the design pattern to modify the code, making it easier for the program to cope with changes.

* ** Begin note ***

Refactoring is a process in which the code is changed, but the code function is not changed.

* ** End note ***

Second, writing unit tests for your code forces you to write code in a special way. The testable code is usually loosely coupled, and unit testing is to isolate a piece of code. To make your program testable, You have to build your application by isolating components.

When a class is loosely coupled with another class, you do not need to affect the second class when modifying the first class. Test-driven development often forces you to write very loosely coupled code that is very easy to handle changes.

Finally, writing unit tests forces you to look at the code from the user's standpoint. When writing a unit test, you will take the same stance as the person who will use your code in the future. Since writing a test will force you to think about future developers (maybe you will be yourself in the future) how to Use Your code will naturally be better designed.

Test driven development

In the previous chapter, we discussed the importance of Writing Unit Tests for your code. Test-driven development is a software design methodology, it holds that unit testing is central throughout the software development process. When you develop a unit test in the test zone, you first write the test and then write the code for the test.

In more detail, when you practice test-driven development, three steps (red/green/refactoring) are required when you write code ):

· Write a failed unit test (red ).

· Code compilation, which has passed the unit test (green ).

· Refactor your code ).

First, write unit tests. unit tests should express how code is expected to run. When you create a unit test for the first time, it should fail because you have not written any code that can satisfy the test.

Next, you need to write the necessary code to make unit tests pass, and write the code in the lazy, sloppy, and fastest way. You should not waste time thinking about the program architecture. You should focus on writing the minimum amount of code to satisfy the intent expressed in unit testing.

Finally, after writing enough code, you can think back to the entire architecture of the program. At this stage, you should use the design pattern to rewrite (rebuild) your code, such as the repository mode, makes your code easier to maintain. In this process, you can safely rewrite the code because the code has been covered by unit tests.

Practical testing-driven development can bring many benefits. First, test-driven development forces you to focus on the code that is actually needed, because your continuous focus only writes code that can pass specific tests, you can avoid writing huge code that you will never use.

Second, the "test-first" design methodology forces you to code from the perspective of how your code is used. In other words, when you practice test-driven development, you always write your tests from the user's perspective. In this way, test-driven development can bring more clean and understandable APIs.

Finally, test-driven development forces you to write unit tests as part of the entire software development process. In the methodology focusing on the project deadline, testing is often the first to be canceled. However, in practice-driven development, unit testing is centered throughout the development process, you may be more comfortable writing unit tests.

Short term pain, long term gain

Building software to cope with changes requires more preliminary efforts, thinking and efforts to implement design principles and models, and writing tests takes time. However, compared with the effort to build software in the right way in the early stage, it will return a lot in the future.

There are two ways for developers. You can be a cowboy, or you can be a craftsman. After receiving the task, the cowboy immediately jumps in and starts coding. He can quickly build a software application. The problem is that the software must be maintained over time.

The craftsman is very patient. Craftsman is very careful when building software. He will be very careful to build unit tests to overwrite all the code in the application, so that he will spend a longer time to complete an application. However, after an application is created, it is easy to modify bugs and add new features.

Most developers start their programming career as a cowboy. However, at some point, you must suspend your saddle to build software that can withstand the test of time.