大小写约?/h2>
标识W的大小写规?/p>
PascalCasingQ如HtmlTag IOStream
camelCasingQ如htmlTag ioStream
- 要把PascalCasing用于由多个单词构成的名字I间、类型、以及成员的名字Q?
- 要把camelCasing用于参数的名字?/li>
通用命名U定
单词的选择
Ҏ架中标识W的名字来说Q很重要的一Ҏ一目了然?/p>
名字的意思清楚比长度短更重要。名字应该与场景、系l的逻辑l成或物理组成以及ؓ人熟知的概念相对应，而不应该与技术或框架相对应?/p>
- 要ؓ标识W选择易于阅读的名字；
- 要更看重可读性，而不是更看重短性；
- 不要使用下划Uѝ连字符以及其他M既非字母也非数字的字W；
- 不要使用匈牙利命名法Q?
- 避免使用与广泛用的~程语言的关键字有冲H的标识W?/li>
使用单词~写和首字母~写?/strong>
一般来_不要在标识符中用单词羃写或首字母羃写：宁可名字长一点，也不要别人看不懂?nbsp; 其不要使用未被q泛接受的单词羃写和首字母羃写词?/p>
- 不要使用~写词或~略词作为标识符名字的一部分
用GetWindow 不用GetWin - 不要使用未被q泛接受的首字母~写?br>多谓q泛接受Q用搜烦引擎在网上搜索该首字母羃写词Q如果返回的前几个结果与期望相符Q那么该首字母羃写词才有资格被称Z所周知?/li>
避免使用语言Ҏ的名?/strong>
- 要给cd名用语义上有意义的名字Q而不要用特有的关键?br>GetLength比GetInt要好
- 要用CLR的通用cd名，而不要用语aҎ的别?
- 要用常见的名字Q比如value或itemQ而不要重复类型的名字
为已有API的新版本命名
当用新类型和新成员接替或取代已有的类型或成员Ӟ如何选择名字Q?/p>
- 使用与旧API怼的名?
- 要优先用后~而不是前~来表C已有API的新版本
q样有助于在览文档或用Intellisense时发现新版本Q按字母排序 - 可以考虑使用全新但有意义的标识符
- 要用数字后~来表C已有API的新版本
有些名字Q或工业标准Q不宜添加后~或改? - 不要在标识符中用“Ex”“New”等cM的后~来区分相同API的不同版?
- 要在引入64位整敎ͼlongQ而非32位整数进行操作的新版本API时用?4”后~Q反之亦然?/li>
E序集和DLL的命?/h2>
E序集是一个部|单元，同时q代表托代码程序的w䆾。虽然程序集可以分布一个或多个文g中，但一般来说一个程序集仅与一个DLL相对应?/p>
名字I间与DLLE序集的区别Q?/p>
名字I间Q一l逻辑实体
DLL和程序集Q打包和部v时的一个单
- 要ؓE序集和DLL选择提示性的名字Q比如System.DataQ这样很Ҏq道它的大致功能?
- DLL命名Q?lt;Company>.<Component>.dll
名字I间的命?/h2>
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
- 要用公司名称作ؓ名字I间的前~Q不要用~写
- 要用E_的与版本无关的品名UC为名字空间的W二?
- 不要Ҏ公司的组l架构来军_名字I间的层ơ结构，因ؓ公司内部l织的名UC般来说不会持l太长的旉
- 要用PascalCasing大小写风|q用点号来分隔名字空间的各部分?br>如Microsoft.Office.PowerPoint
- 考虑适当的时候在名字I间中用复数Ş式?nbsp; 首字母羃写词例外
System.Collections
System.IO - 不要用相同的名字来命名名字空间与位于该名字空间中的类?br>如：不要名字空间命名ؓDebugQ然后又在该名字I间中提供一个名为Debug的类?/li>
名字I间和类型冲H?/strong>
- 不要引入太一般化的类型名Q比如Element、Node、Log以及Message?/li>
不同cd的名字空_有不同的规范来避免类型名的冲H：
- 应用E序模型名字I间Qapplication model namespaceQ?br>属于单个应用E序模型的名字空间经怸起用，但是它们几乎不合属于其他应用E序模型的名字空间一起?br>System.Windows*
System.UI* - 基础设施名字I间Qinfrastructure namespaceQ?br>此类别包含一些在开发常用应用程序时很少会导入的名字I间
- 核心名字I间Qcore namespaceQ?br>包含了所有的System名字I间Q但应用E序模块名字I间和基设施名字I间除外?nbsp; 包括System、System.IO、System.Xml以及System.Net{等
- 技术名字空间组Qtechnology namespace groupQ?br>此类别包含所有那些以相同的两个前~Q?lt;Company>.<Technology>*Q开始的名字I间?/li>
cR结构和接口的命?/h2>
一般来说类型名应该是名词词l。如果无法ؓcd扑ֈ一个名词词l，那么应该重新考虑cd的M设计?/p>
另一个中重要的考虑因素Q最易于识别的名字应该用于最常用的类型?/p>
最常用的类型名应该反映Z用场景，而不是承层ơ?/p>
- 要用名词词组来给cd命名。用PascalCasing风格
- 不要l类名加前缀
只有接口才能Q可以）被加前缀“I”，那是因ؓ.NET框架受到COM及Java的媄? - 考虑让派生类的名字以其基cȝ?br>public class FileStream : Stream {...}
- 要确保一对类/接口的名字只差一个“I”前~Q如果该cL该接口的标准实现?br>public interface IComponent {...}
public class Component : IComponent {...}
泛型cd参数的命?/strong>
- 要用描述性的名字来命?
- 考虑用T来命名参数类?
- 要给描述性的cd参数名加上T前缀
- 考虑在类型参C昄出施加于该类型参C的限?/li>
枚Dcd的命?/strong>
- 要用单数名词来命名枚丄型，除非它表C的是位域（bit fieldQ?
- 不要l枚丄型的名字d“Enum”后~Q也不要d“Flag”、“Flags”等后缀
- 不要l枚丄型值的名字d前缀
此规范与C++中通常所使用的恰好相反。在C++中给枚D的每个成员加上完成的限定W是很重要的Q因为它们可能在枚D名的作用域之外被讉K。但是在托管代码中，枚D成员只能通过枚D名的作用域来讉K?/li>
cd成员的命?/h2>
cdQ方法、属性、事件、构造函数、字D?/p>
Ҏ的命?/strong>
要尽量根据方法所对应的Q务来l它们命名，而不要根据一些实现细节?/p>
- 要用动词或动词词l来命名Ҏ
属性的命名
- 要用名词、名词词l或形容词来命名属?
- 不要让属性名看v来与“Get”方法的名字怼
- 要用肯定性的短语QCanSeek而不是CantSeekQ来命名布尔属?
- 考虑用属性的cd名来命名属?br>public enum Color {...}
public class Control
{
public Color Color
{
get {...}
set {...}
}
}
事g的命?/strong>
- 要用动词或动词短语来命名事g
事gL表示一些动作，要么正在发生Q要么已l发? - 要用现在时和q去时来赋予事g名之前和之后的概?br>H口关闭之前发生的close事gQClosing
H口关闭之后发生的close旉QClosed - 不要用Before和After前缀或后~来区分前|和后置事g
- 要在命名事g处理函数Q用作事件类型的委托Q时加上“EventHandler”后~
- 要在事g处理函数中用sender和e作ؓ两个参数的名?br>senderQ触发事件的对象Q在整个.NET框架中，sender为objectcd
- 要在命名事g的参数类型时加上“EventArgs”后~
字段的命?/strong>
- PascalCasing风格
- 名词或名词短?
- 不要l字D名d前缀
参数的命?/h2> - camelCasing风格
- 要用描q性的参数?br>参数名要具备_的描q性，使得在大多数情况下，用户Ҏ参数的名字和cdp够确定它的意?
- 考虑Ҏ参数的意思而不是参数的cd来命名参?/li>
资源的命?/h2>
本地化的资源好比是属性，可以通过特定的对象来引用。因此，它的命名规范与属性的怼?/p>
- 要在命名属性关键字Qresource keyQ时使用PascalCasing大小写风?
- 要标识W的名字h描述性而不是名字变短
- 不要使用各主要CLR~程语言Ҏ的关键字
- 要在命名资源时用字母、数字和下划U?
- 要用点号来给标识W清楚地划分层次
- 要在为异常消息资源命名是遵@下面的命名约定：
资源标识W应该是异常的类型名加一个简短的异常标识W，之间以点号分?/li>
]]>
]]>
]]>
]]>
对用戯言Q真正的开发效率来自能够轻易地创造非凡的产品Q而ƈ非来自能够轻易地创造垃圾?
1. 场景驱动设计原则
2. 低门栏原?
3. 自说明对象原?
4. 分层架构原则 阅读全文
]]>
]]>
]]>
* 要确保API是直观的Q无需查阅参考文就能用于基本场?
你M希望写个“Hello World”都L阅API文吧?
* 要ؓ所有的API提供优秀的文?
一斚wQƈ非所有的API都能自说明。不同的Z认ؓ不同的API是自说明的；
另一斚wQ有些h惛_开始用API之前完全理解它们?nbsp; 阅读全文
]]>
]]>
]]>
?/strong>用户而言Q真正的开发效率来自能够轻易地创造出非凡的品，而ƈ非来自能够轻易地创造垃圾?/h3> 场景驱动设计的原?/font>
框架通常包含非常大的一lAPI。但在开发过E中Q真正用到的只是其中较小的一个子集，只会涉及一部分常用场景?/p>
在设计框架时Q用场景来驱动。从用户的角度，先自q写一些对主要场景来说必不可少的代码，然后再设计对象模型（object modelQ来支持q些样例代码?/p>
于功能性规范之前，先撰写一份场景驱动的API规范Q应该列Z个给定的技术领域中最常用??0个用场景，q列出实现这些场景的样例代码Q至用两种语言~写?/p>
- 要确保对M包含公用API的特性设计来_其核心部分都是API设计规范?/li>
- 要ؓ每个主要的特性域Qfeature areaQ定义一些最常用的场景?/li>
- 要确保用场景与适当的抽象层ơ相对应。场景应该大致与最l用L用例相对应?/li>
- 先ؓ主要的用场景编写样例代码，然后再定义对象模型来支持q些样例代码?/li>
- 要用臛_两种不同的编E语a来ؓ主要场景~写样例代码?br>最好能保证所选编E语a的语法和风格差异很大?/li>
- 不要在设计框架的公用API时完全依赖于标准的设计方法?br>标准的设计方法（包括面向对象的方法）是ؓ了设计的具体实现容易维护，而不是ؓ了得到的API易于使用?br>以场景驱动设计ؓ主，辅以原型制作、可用性研I以及一定数量的q代Q这U方法要比标准的设计Ҏ好得多?br>可用性研I是Z定开发h员真正的需求。这跟需求获取一P设计师此时化wؓ一名需求分析师Q而开发h员则变成了客戗需求分析师不能惛_然的认ؓ客户的真正需求是什么，一定要通过跟客户交才行，站在客户的角度考虑问题。跟需求获取类|可用性研I宜早不宜迟?/li>
- 要安排可用性研I来试用于主要场景的API?br>如果开发h员在Z要场景编写代码时Q遇到较大问题，则说明API需要重新设计。在原有API的基上修改，开销反而大Q而且是很大?/li>
]]>
]]>
原文地址Q?a target="_blank">接口和抽象类的定义方式D例说?/font>
接口定义
关于java的接口定义方式，以下三种情况下可以采用接口定义方式：
1. 接口中声明的变量全部为final 和staticcd的，q且q个接口的作用在于定义一些g能改变的变量?br>举个例子Q?br>public interface ObjectConstants{
public static final String SPACE = new String(" ");
public static final char FORMFEED = '\f';
}
2. 接口中只定义可供实现的抽象方?br>EventListener.java
public interface EventListener {
public void handleEvent(Event evt);
}
Runnable.java
package java.lang;
public interface Runnable {
public abstract void run();
}
3. q有一U方式是上述两种方式的组合，如非必要一般会这样一个接口定义拆分成两个接口定义
抽象cȝ定义
1. 如果一个类包含一个接口但是不完全实现接口定义的方法，那么该类必须定义成abstract?br>例如InputStream.javacȝ定义方式Q?br>package java.io;
public abstract class InputStream implements Closeable {
// SKIP_BUFFER_SIZE is used to determine the size of skipBuffer
private static final int SKIP_BUFFER_SIZE = 2048;
// skipBuffer is initialized in skip(long), if needed.
private static byte[] skipBuffer;
public abstract int read() throws IOException;
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
public int read(byte b[], int off, int len) throws IOException {
if (b == null) {
throw new NullPointerException();
} else if ((off < 0) || (off > b.length) || (len < 0) ||
((off + len) > b.length) || ((off + len) < 0)) {
throw new IndexOutOfBoundsException();
} else if (len == 0) {
return 0;
}
int c = read();
if (c == -1) {
return -1;
}
b[off] = (byte)c;
int i = 1;
try {
for (; i < len ; i++) {
c = read();
if (c == -1) {
break;
}
if (b != null) {
b[off + i] = (byte)c;
}
}
} catch (IOException ee) {
}
return i;
}
public long skip(long n) throws IOException {
long remaining = n;
int nr;
if (skipBuffer == null)
skipBuffer = new byte[SKIP_BUFFER_SIZE];
byte[] localSkipBuffer = skipBuffer;
if (n <= 0) {
return 0;
}
while (remaining > 0) {
nr = read(localSkipBuffer, 0,
(int) Math.min(SKIP_BUFFER_SIZE, remaining));
if (nr < 0) {
break;
}
remaining -= nr;
}
return n - remaining;
}
public int available() throws IOException {
return 0;
}
public void close() throws IOException {}
public synchronized void mark(int readlimit) {}
public synchronized void reset() throws IOException {
throw new IOException("mark/reset not supported");
}
public boolean markSupported() {
return false;
}
}
2. 抽象cȝҎ体中只定义抽象的ҎQ例如AbstractMethodError.java
package java.lang;
public class AbstractMethodError extends IncompatibleClassChangeError {
public AbstractMethodError() {
super();}
public AbstractMethodError(String s) {
super(s); }
}
]]>