NET Design Specification II: type member design

Http://www.cnblogs.com/yangcaogui/archive/2012/04/20/2459567.html

Then →. NET design specification one: Based on a design specification, let us understand the type of member named Design!

3. Design of type member naming

3.1 Fields

① follows the naming rules for " camelCasing "

② use a noun or noun phrase instead of C # keywords

③ do not add any prefixes to the field

④ to use the "pascalcasing " naming convention when defining constants

⑤ named with "camelCasing" when defining a private variable and preceded by "_" as the prefix

3.2 Methods

① must be a verb phrase, do not use C # keywords

② try to name it according to the task of the method, rather than according to some internal implementation details!

Commonly used verbs are: get,update,delete,add,validate,select,search, and so on, after these verbs plus you want to do the content, it constitutes a method name!

3.3 Properties

① should be named by noun or noun phrase or adjective or adjective phrase, followed by "pascalcaing" Case specification!

② do not make the property name similar to the "Get" method name

　　　　　　

This scenario indicates that the attribute should be a method, should be merged, and only define a Method!

③ to use affirmative phrases, such as: CanSeek, not Cantseek

③ if the return value of the property is a "bool" value, consider adding "is" to the property name, "Can", "has" prefix!

1 public bool CanSeek {get; set;} 2 Public         bool Cantseek {get; set;}  3 public         bool HasValue {get; set;} Not recommended

However, this situation depends on the situation, if you add a prefix instead of the name becomes lengthy, then do not add a prefix!

　　　　　　

3.4 Events

Recommended article: Delegates and events in C #

The design of the event is very important to the individual, so I learned it very attentively.

Basic naming rules:

① to be named with verbs or verb phrases.

Verb or verb phrases such as ckecked,updated,selected, etc.

② do not use words like "before" or "after" to indicate pre-events or post-events

③ needs to define a parameter information entity for the event, which must end with the "EventArgs" suffix

④ to add an "on" prefix to the method name of the bound event

The basic framework for defining events is as follows:

1 Public     class Demoseven 2     {3 Public         event eventhandler<updatedeventargs> Updated; 4         Private Updatedeventargs _updatedeventargs = new Updatedeventargs () {updatedid = "1234"}; 5         private eventhandler<updatedeventargs> _updatedhandler; 6  7         Private Const string str = ""; 8         Private readonly string strone = ""; 9 Public         void OnUpdated ()///Execute event method one by one         {             _updatedhandler = updated;13             if (_updatedhandler! = null )                 (_updatedhandler, _updatedeventargs),             }17         }18     }19 Public     class Updatedeventargs:eventargs  //Parameter information entity class     {public         string Updatedid {get; set;} (+     }

3.5 Indexer

In fact, the point indexer is the encapsulation of a collection or an array.

The design rules for indexers are basically fixed, all using the "this" keyword, as follows:

1 public         string This[int index]2         {3             get {return "";} 4         }5 6 public         string This[int Index, string name]7         {8             get {return "";} 9         }

3.6 Naming of resources

It is possible to use resources when converting multiple languages, so the naming of the parameters within the resources is also very important!

① using the "pascalcasing " naming method, do not use the C # keyword

② If the name is descriptive, rather than blindly shorten the name, of course, but also to ensure the brevity of the name, but the premise can not sacrifice readability

③ try to use letters, numbers and underscores

④ to use a dot to clearly divide the hierarchy of identifiers

　　　　　　

⑥ Treat exception information with "Exception" suffix

If everyone knows, just review it!

Next article:. NET Design Specification III: Conventions and idioms for the design of type and type members

. NET Design Specification III: Conventions and idioms for the design of type and type members

Continue on two unfinished work →①.net design specification One: Design Specification Foundation ②.net Design Specification II: type member design

On two main is to say the type and type of members in the name of the specification, their specific design has not been involved, this article is from a common developer's point of view, there will be a lot of shortcomings, hope to get everyone's guidance!

First of all, this article is only the use of books to do some of the summary, Daniel (architects) Please do not spray me, if really suppress, it is hard to spray it, in the spray grow!

　　4. Conventions and usages of type design

　　　　4.1 Selection of classes and interfaces

① should use class first

The first class is the preferred choice for exposing abstractions!

The scenario that Microsoft developers provide to us is to define an interface and then define an abstract base class to implement this interface!

1 Public     Interface IComponent  //This is a relatively prominent case in the. NET Framework 2     {3         void GetID (); 4     } 5  6     public class Component:icomponent 7     {8 public         void GetID () 9         {Ten             //to do.11         }12     }

② to dissolve the coupling between the contract and the implementation using an abstract class rather than an interface

③ If you need to define a polymorphic value type hierarchy, define an interface

1 public     structs int32:icomparable, IFormattable, IConvertible2     {3         4     }5 public     struct Int64: IComparable, IFormattable, IConvertible6     {7 8     }

④ consider using interfaces to implement multiple inheritance

Note: The flag that defines an interface is that it only does one thing.

　　　　4.2 Design of abstract class　　

Advantages:

① Greater flexibility

② can be extended by inheriting the function

③ can override virtual methods and abstract methods in abstract classes to achieve functional expansion

Design:

① constructor modifiers in abstract classes because they are "protected" or "interal", but most of the cases are "protected"

② defined abstract class must have a class to inherit it, but not to be a loner, so as to help verify the validity of the abstract class

1 public     abstract class Animal2     {3         protected Animal () 4         {5         }6     }

4.3 design of the interface

① interface can support multiple inheritance

② avoid using the token interface (i.e., no member interface)

③ to provide the type of implementation for the interface, as in the abstract class above, do not become a loner

④ in large project development, a series of interfaces are provided for external invocation (this is also one of the design interface Scenarios)

⑤ interface once defined, it can't be changed.

　　　　4.4 Design of Static class

① as few as possible to customize static classes, if you design a static class that has a secondary effect, then you should define a static class such as the "File" class in the. NET framework, a text-assisted class

② do not declare or overwrite instance members in a static class

③ to define a static class as sealed, abstract, and add a private constructor

　　　　4.5 Design of the structure

① do not provide a default constructor for structs

② generally the custom structure analogy is less

　　　　4.6 Design of enumerations

① to use enumerations to reinforce the parameters of the collection that represents the value, the type of the property or the return value

② to use enumerations instead of static variables

For example, using enumerations is the best choice when defining some color attributes.

③ do not provide enumeration values for future use

④ do not define only one value in the enumeration, if there is only one then it is better to set a constant!

⑤ to provide a "0" value for a simple enumeration, see the "0" value in more detail → from the initialization of the enumeration [C #]

1 public     enum Color2     {3         Red = 0,//This is a specification 4         Yellow = 1,5         Black = +     }

⑥ consider the value of the "Int32" type as an enumeration value

⑦ to name "tag enumeration" using plural nouns or noun phrases, name simple enumerations with singular nouns or noun phrases

　　　　4.7 Tag Enumeration

The tag enumeration provides bit manipulation of the enumeration values!

① must add the "[Flags]" flag feature

② to use the power of 2 as the value of the tag enumeration (in fact, this rule is not very clear, but this is really a very important specification)

1     [flags]2 public     enum MyEnumTypes3     {4         Created = 0x0002,5         Updated = 0x0004,6         Deleted = 0x00087     }

③ to provide special enumeration values for tag enumerations where appropriate, that is, the combination enumeration

1     [flags]2 public     enum FILEACCESS3     {4         Read = 1,  ////The enumeration value of the "int" type defined here does not conflict with the power of the above using 2 as the enumeration value. We should use the power of 2 in future development as the enumeration value 5         ReadWrite = 3,//provide a combined value, or so →readwrite = Read | Write6         Write = +     }

④ do not define an invalid enumeration value

　　5. Member Design

　　　　5.1 Overloading of methods

① avoid arbitrarily giving parameter names when overloaded, should maintain parameter name consistency

　　　　　　

② avoid disrupting the order of parameters, maintaining the consistency of parameter order in multiple overloads

③ to make a "virtual method" of the longest overload, which helps in the rewriting of derived classes, enhances extensibility

④ do not use "ref" or "out" parameters in overloaded members

View Code

⑤ to allow arguments of reference types to be "null", but "null" values need to be judged in the method

　　　　5.2 Explicit and implicit implementations of interfaces

① avoid explicitly implementing an interface

Feel this specification in the "iterator" in the use of more, you can refer to this article: Program ape Personal article Directory index of the iterator series

To tell the truth this topic I also dare not say how much, because I own to its essence of thing understanding of good not deep enough, so on the general say a few words!

　　　　5.3 Selection of properties and methods

The ① attribute focuses on the embodiment of the data, while the method focuses on the operation, but the performance of the two is not many (although the book also discusses the performance differences, but can be ignored)

② recommends that you use attributes more, and if you define enough properties, you define the equivalent private variable for the attribute, which is the encapsulation of the variable.

③ avoid too many parameters in the method, if too much is recommended to use properties to reduce method overloading

④ some common scenarios in which you need to use methods

I, the operation is a conversion operation, such as the ToString () method

II, the result of each return of the operation is different, such as: Guid.NewGuid ()

III, the operation returns an array or a collection (the case is pretty practical)

⑤ so the use of attributes is that it represents simple data manipulation, and overly complex operations should be done using methods

　　　　5.4 Design of the indexer

Personal understanding: Indexers are the encapsulation of collections and arrays!

An indexer can be a single index or multiple indexes, and the indexer is attached to the class level, so it uses the "this" keyword, which is a simple introduction to this knowledge in the previous article!

① avoid indexers that use more than one parameter

　　　　5.5 Structural function Design

There are two types of constructors: type constructors and instance constructors

Type construction → that is, static constructors, must be static, at the time of initialization is the first to execute!

① must be a private construct (compiler enforces it)

② do not throw exceptions in type constructs

instance construction → Common constructs

① consider providing a simple constructor, which can be the default constructor

② If you use a constructor overload, the constructor's parameter action should be set to the primary property instead of the "optional" argument

③ to do the least thing in the constructor

④ If you want to use a constructor overload, you need to provide an empty construct so that you do not break a type member that relies on an empty construct

　　　　5.6 Design of the event

The basic specification of event definitions can be referenced in the previous article!

① to use a system-defined delegate →eventhandler<t> (which can be said to be a generic specification)

② consider setting the event's handling method to a virtual method so that derived classes can be overridden to improve extensibility

If you want to dig deeper into the recommended articles: C # Delegates and Events (2), talk about delegates in C #, delegates and events in C #

　　　　5.7 Design of the field

① do not raise public or protected instance fields

② to use the property to access the field, which is the same as the Direct Access field

③ to use constant fields to represent constants that never change, you can find some information to understand the difference between "Const" and "ReadOnly"

④ do not assign an instance of a mutable type to a read-only field

⑤ to define a predefined object instance with a public static read-only field (this person does not understand a bit.)

　　　　　　

Good to write so much, feel good tired, because I am not what the architect, is a small rookie (this is from my point of view, height has not risen up), write these things are imitation books, is a little summary, can not count experience!

If you have any questions, please give us a lot of advice!

Next article:. NET Design specification four: Simple extension design and personal thinking

. NET Design specification four: Simple extension design and personal thinking

One weeks did not write the article records the study and the work road, today while is Youth Day afternoon rest time to write. NET design specification of the last article!

In doing a series of naming norms, design norms, the higher level of the specification is those of the extension of the specification (or object-oriented, in fact, I am a vegetable rookie), here I only simple to say!

To tell the truth to write such an article is very difficult to write, especially when it comes to architectural design I do not have to, so I will summarize the book, try to less personal ideas!

Then on three articles: ①. NET design Specification One: Design Specification Foundation ②.net Design Specification II: Type member design ③.net design Specification III: Conventions and idioms for the design of type and type members

　　5. Extensibility Design

　　　　5.1 Sealing class

① do not recommend the use of sealed classes, unless there are special reasons

　　　　5.2 Abstract classes and abstract interfaces

① when necessary, you should define an abstract class (or a base class) and an interface, and then implement the interface with an abstract class (or base Class)

　　　　　　

　　　5.3 Base class

　　6. Unusual design

　　　　6.1 Design of custom exceptions

① avoid too deep inheritance levels

② must derive a new exception class from "System.Exception", which is a specification

③ to add the "Exception" suffix after the exception class name

④ If the exception can be serialized, this is to enable cross-application and cross-platform

⑤ to provide common constructors for exceptions

　　　　　　

⑥ to define the "ToString" method to return exception information

⑦ two points in the book, not very clear

　　　　　　

1     [Serializable] 2 public     class Myexception:exception  //This is the simplest exception handling information 3     {4         private string _ Message 5  6 Public         myexception () 7         {} 8 public         myexception (String message) 9         {Ten             _message = message;         }12 public         override String ToString () (+/to             do.16             return "";         }18     }

PS: The book in the introduction of the exception to write a lot, but the understanding of the very few, here put their own understanding written down, so still need to look at several times, so as to slowly understand him!

　　7. Encoding specification for arrays, attributes, and collections

　　　　7.1 Arrays

① using collections rather than arrays

② do not design arrays as read-only groups, it should allow the user to modify the elements in the array

　　　　7.2Attribute (characteristic)

① to add "Attribute" suffix when naming, and inherit "Attribute" base class

public class Myattribute:attribute

② to use the "AttributeUsageAttribute" feature when customizing

1     [AttributeUsage (AttributeTargets.All)]2 public     class Myattribute:attribute3     {4 5     }

③ to provide properties that can be set for optional parameters

　　　　　　

④ to provide read-only properties for required parameters

⑤ to provide constructors to initialize required parameters, each parameter name should be the same as the corresponding property name (may be different in case)

1     [AttributeUsage (AttributeTargets.All)] 2 public     class Myattribute:attribute 3     {4         public MyAttribute (string name, String message) 5         {6             name = name; 7             message = message; 8         } 9         Private Stri　　　　ng Name {get; set;}　　This is a required parameter, one for each         private string Message {get; set;}　　　This is a required parameter, public         string Author {get; set;} This is an optional parameter of     }14     [My ("ss", "ss", Author = "SSS")]//Then I will be called when the following method of calling the public     class One17     {}

⑤ as much as possible to seal up the custom Attribute, this will be the find "Attribute" faster

⑥ avoid providing constructors to initialize optional parameters

⑦ Avoid overloading the custom "Attribute" constructor

　　　　7.3 About collection properties and return values

① do not supply set properties

1 public         collection<string> Items {get; set;}  Bad Design 2 public         collection<string> Items//advocated design 3         {4             get5             {6//To do  7             } 8         }

② to use "collection<t>" or its subclasses as a property or a return value to represent a writable collection (as in the above)

③ use "readonlycollection<t>" as a property or return value to represent a read-only collection

This article is not written well, may really be due to my limited knowledge accumulation, writing is very difficult, but eventually write well, continue to refuel!

NET Design Specification II: type member design