NET Design Specifications Chapter 1 framework design basis and framework structure specifications

NET Design Specifications Chapter 1 framework design basis and framework structure specifications
NET Design Specifications Chapter 1 Framework Design Basis

A powerful and easy-to-use framework should be designed.

Developers should understand and design frameworks for them.

Understand various programming languages and design frameworks for them.

Make sure that the API design specifications are the core part of any feature that includes a public API.

You need to define some of the most common use cases for each major feature domain.

Make sure that the Application Scenario corresponds to an appropriate abstraction level. The scenario should roughly correspond to the end user's use case.

When designing an API, you must first compile sample code for the main application scenarios, and then define the object model to support these sample codes.

Use at least two different programming languages to write sample code for the main scenario.

Consider using dynamic language to write sample code for main scenarios.

Do not rely entirely on standard design methods when designing public APIs of the framework.

Availability test research should be arranged to test the APIs used in major scenarios.

Make sure that the namespace of each major feature domain only contains the types used in the most common scenarios. The types used for more advanced scenarios should be placed in the sub-namespace.

You need to provide simple overload functions for constructors and methods. A simple overload function not only has a very small number of parameters, but also all parameters are of the basic type.

Do not place members for advanced scenarios in the types designed for main use scenarios.

Do not require that more than one type be displayed in the most basic scenario.

Do not require users to perform a lot of initialization before writing code for basic use cases.

Provide the appropriate default values for all attributes and parameters as much as possible (with convenient overload functions.

The misuse of APIs should be conveyed through exceptions.

Make sure that the API is intuitive and can be used in basic scenarios without reference documents.

Provide excellent documentation for all APIs.

You need to invest a lot of time and effort in reviewing the specifications to discuss the selection of identifiers.

Do not worry that the name of the identifier is too long.

Consider engaging educational experts early in the design process. Consider leaving the best name to a common type.

An exception message is used to notify developers of misuse of the framework.

Provide as many APIs as possible.

Make sure that it is consistent with the. NET Framework and other frameworks that customers may use.

Avoid using too many abstractions in APIs in major scenarios.

Consider layering the framework so that high-level APIs can provide the best development efficiency. Low-Level APIs can provide the most powerful functions and the most abundant expressiveness.

Avoid mixing complex (including many types) low-level APIs and high-level APIs in the same namespace.

Make sure that different layers in a single feature domain can be well integrated. Developers should be able to use one layer for development at the beginning, and then use another layer by modifying the code, and such changes do not need to overwrite the entire application.

 

 

 

Http://www.cnblogs.com/liqingwen/p/7147887.html.