Recommended Guidelines for defining classes

• When defining a class, classes are typically explicitly marked as sealed unless you are sure that you plan to define the class as a base class that allows the derived class to be specialized. As mentioned above, this is the opposite of the default mode of c # And other compilers. Classes are marked as internal by default unless you want them to be publicly available outside the assembly. Fortunately, the default mode of the c # compiler is internal when the visibility of the type is not displayed. If you think that other classes can be derived from this class, and do not want to be specialized, you can use the virtual method sealing technology mentioned above to create a closed class, then inherit the base class.

• Within the class, do not hesitate to define the field as private. Fortunately, c # marks the field as private by default. If c # defines all fields as private, but does not mark the fields as protected, internal, or public, this is very popular. The exposure status is very prone to problems. It makes the behavior of objects unpredictable and exposes potential security vulnerabilities. Even if only some fields are defined as internal, these problems do exist. Even in a separate assembly, it is very difficult to trace all the code that references a field, especially when several developers write code together and compile it in the same assembly.

• Within a class, you always define your methods, attributes, and events as private and non-virtual. Fortunately, the default method of c # is the same. Of course, defining methods, properties, and events as public can provide functions of some types of types. Avoid defining members as protected or internal, which may cause potential vulnerabilities in the type. However, it is better to mark the member as protected or internal than to mark the member as virtual, because the virtual member does not have much control, and it does depend on the normal behavior of the derived class. Object-Oriented Programming has an old saying that when things become exceptionally complex, more types are generated. When the implementation of some algorithms becomes complex, you can define auxiliary types to seal discrete function blocks. If you define these secondary type values to be used by the uber type, you can then define these secondary types nested in the uber type, which allows range management (scoping ), also, code in nested types can be referenced to define Private Members of the uber type. However, FxCop enforces a design guiding rule, that is, the publicly available nested types should be defined within the scope of a file or assembly, rather than in another type. This rule is developed after Developers find it difficult to reference the syntax of nested types. This rule is admirable and therefore never defines public nested types.