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