Developer on Alibaba Coud: Build your first app with APIs, SDKs, and tutorials on the Alibaba Cloud. Read more ＞
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.
This article is an English version of an article which is originally in the Chinese language on aliyun.com and is provided for information purposes only. This website makes no representation or warranty of any kind, either expressed or implied, as to the accuracy, completeness ownership or
reliability of the article or any translations thereof. If you have any concerns or complaints relating to the article, please send an email, providing a detailed description of the concern or
complaint, to email@example.com. A staff member will contact you within 5 working days. Once verified, infringing content will be removed immediately.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
and provide relevant evidence. A staff member will contact you within 5 working days.