.NET 设计规范--.NET约定、惯用法与模式--4.类型设计规范

  要确每个类型有一组定义明确、相互关联的成员组成,而不仅仅是一些无关功能的随机集合。

  4.1 类型和名字空间

  要用名字空间把类型组织成一个相关的特性域的层次结构,该层次结构应该为开发人员更容易地浏览框架并找到想要的API而优化。

  避免非常深的名字空间层次。这样的层次难于浏览,因为用户不得不经常的回溯。

  避免有太多的名字空间。在最常见的场景中,框架的用户应该不需要导入许多的名字空间。只要有可能,就应该把常见场景中一起使用的类型放在一个单独的名字空间中。

  避免把为高级场景而设计的类型和为常见编程任务而设计的类型放在同一个名字空间中。

  不要不指定名字空间就定义类型

  标准子名字空间的命名

  很少使用的类型应该放在子名字空间中年,以免搅乱主名字空间。我们确定了几组类型,应该把它们从主名字空间中分离出来

  1.  .Design子名字空间

  仅用于设计时的类型应该放在名为.Design的子名字空间中。

  要用带”.Design“后缀的名字空间来容纳那些为基本名字空间提供设计时的功能的类型,例如System.Windows.Forms.Design。

  2.  .Permissions子名字空间

  许可类型应该放在名为.Permissions的子名字空间中。

  要用带”.Permissions“后缀的名字空间来容纳那些为基本名字空间提供自定义许可的类型。

  3. .Interop子名字空间

  许多框架需要支持与旧式系统的互操作性(interoperability)。把与旧式组件进行互操作的功能放到一个子名字空间中是合理的。

  要用带".Interop"后缀的名字空间来容纳那些为基本名字空间提供互操作功能的类型

  要用带".Interop"后缀的名字空间来容纳所有位于Primary Interop Assembly(PIA)中的代码。

4.2 类和结构之间的选择

  考虑定义结构而不要定义类--如果该类型的实例比较小而且生命期比较短,或者经常被内嵌在其他对象中。

  不要定义结构,除非该类型具有以下所有的特征:

  它在逻辑上代表一个独立的值,与基本类型相似

  它的实例的大小小于16个字节

  它是不可变的

  它不需要经常被装箱

4.3 类和接口之间的选择

  要优先采用类而不是接口

  要用抽象类而不是接口来解除协定月实现之间的耦合

  要定义接口,如果需要提供一个多态的值类型层次结构的话

  考虑通过定义接口来到达与多重继承向类似的效果

4.4 抽象类的设计

  不要在抽象类型中定义公有的活内部受保护的(protected-internal)构造函数

  要为抽象类型定义受保护的构造函数或内部构造函数

  要为你发布的抽象类型提供至少一个继承自给类的具体类型。例如System.IO.FileStream是System.IO.Stream抽象类的一个实现。

4.5 静态类的设计

静态类被定义为一个只包含静态成员的类。在C#2.0中,如果一个类被定义wie静态,那么它就是密封、抽象的,不能覆盖或声明任何实例成员。

  要尽量少用静态类

  不要把静态类当做是杂物箱,每一个静态类都应该有其明确的目的。

  不要在静态类中声明或覆盖实例成员

  要把静态类定义为密封的、抽象的,并添加一个私有的实例构造函数--如果你的编程语言没有内存对静态类的支持

4.6 接口的设计

  CLR不支持多重继承,但除了自以俄国基类继承之外,它还允许类型实现一个或多个接口。因此通常用接口来到达多重继承的效果。

  另一种适合定义接口的情况是在创建能够为多种类型(包括值类型)所支持的公共接口时,值类型无法自除了System.ValueType之外的类型继承,但是他们定义可以实现接口,所有为了同一个公共的基类型,使用接口时唯一的选择。

  要定义接口,如果你需要包括值类型在内的一组类型支持一些公共的API

  考虑定义接口,如果你需要让已经自其他类型继承的类型支持该接口提供的功能。

  避免使用记号接口(没有成员的接口) 如果你需要给一个具备某种特征的类做记号,一般来说,最好使用自定义attribute而不是使用接口。

  要为接口提供至少一个实现该接口的类型 System.Collections.ArrayList是System.Collections.IList接口的实现

  要为你定义的每个即可提供至少一个使用该接口的API(一个以该接口为参数的方法,或是一个类型为该接口的属性)

    例如List<T>.Srot使用了IComparer<T>接口

  不要给已经发行的接口在添加成员,你应该创建一个新的接口。

4.7 结构的设计

  不要为结构提供默认的构造函数

  要确保当所有的实例数据都为零,false或null时,结构仍然处于有效状态

  要为值类型实现IEuatable<T>

  不要显示地扩展System.ValueType,事实上大多数编程语言不允许这样做。

4.8 枚举的设计 

  要用枚举来加强那些表示值的集合的参数、属性以及返回值的类型性

  要优先使用枚举而不要使用静态常量

  不要把枚举用于开放的集合(比如操作系统的版本、朋友的名字等)

  不要提供为了今后使用而保留的枚举值

  避免显示的暴露只有一个值的枚举

  不要吧Sentinel值包含在枚举值中 sentinel值是用来跟踪枚举状态的值,而不属于枚所表示的值的集合。

  要为简单枚举类型提供零值,可以考虑把该值成为"None"之类的东西。如果这样的值不适用于某个特定的枚举,那么应该把枚举中最常用的默认值赋值为零。

  考虑用Int32作为枚举类型的基本实现类型,除非下面的任何一条成立:

    该枚举是一个标记枚举,而你有超过32个标记,或预计今后会用更多的标记

    为了更方便地与需求不同大小的枚举的非托管代码进行互操作,基本的实现类型必须是Int32之外的类型。

    更小的底层实现类型可能会节省相当的空间。如果你预计枚举将主要用于控制流的参数,那么枚举的大小几乎不会造成什么区别。如果属于下面的情况,那么空间的节省肯尼个相当可观:

      你预计枚举将被用作结构或类的字段,而且该结构或类会频繁地实例化

      你预计用户会创建包含该枚举实例的大型数组或集合

      你预计该枚举的大量实例会被序列化

  要用复数名词或名词短语来命名标记枚举,用单数名词或名词短语来命名简单枚举

  不要直接扩充System.Enum。

  8.1标记枚举的设计

  要对标记枚举使用System.FlagsAttribute。不要把该attribute用于简单的枚举

  要用2的幂次方作为标记枚举的值,这样可以通过按位或操作自由地组合它们。

  考虑为常用的标记组合提供特殊的枚举值

  位操作时一个高级概念,对简单的任务来说 应该不是必须的。

  避免让创建的标记枚举包含某些无效的组合

  避免把零用作为标记枚举的值,除非该值表示”所有标记都被清除“,而且按下一条规范进行设当的命名。

  要把标记枚举的零值命名为None。对标记枚举来说,该值必须始终意味着"所有标记均被清除"

  8.2 给枚举添加值

  考虑给枚举添加值,尽管有那么一点兼容的风险

4.9 嵌套类型

  嵌套类型是一个定义在另一个类型的作用域内的类型,另一个类型称为外层(enclosing type)。嵌套类型能够访问它的外层类型的所有成员。

 

转载于:https://www.cnblogs.com/lufangtao/archive/2012/04/09/2438915.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
清晰完整PDF版本,是我从网上买来的,是第二版,在 CSDN 上只有我整个是清晰完整的。 共 50MB,分为5个分卷 .NET设计规范约定惯用模式(第2版)克瓦林纳 2/5 .NET 设计规范 约定惯用模式 第2版 克瓦林纳 定 价:69.00元 作  者:(美)克瓦林纳 等著,葛子昂 译 出 版 社:人民邮电出版社 出版时间:2010-5-1 页  数:370 字  数:579000 I S B N:9787115226518 -------------------------------------------------------------------------------- 数千名微软精锐开发人员的经验和智慧,最终浓缩在这本设计规范之中。与上一版相比,书中新增了许多评注,解释了相应规范的背景和历史,从中你能聆听到微软技术大师Anders Hejlsberg、Jeffrey Richter和Paul Vick等的声音,读来令人兴味盎然。   本书虽然是针对.NET平台上的框架设计的,但对其他平台的框架设计同样具有借鉴意义。新版根据.NET Framework 3.0和3.5的新特性做了全面更新,主要关注的是直接影响框架可编程能力的设计问题。遵守这些规范对于使用.NET Framework创建高质量的应用程序至关重要。   本书提供配套光盘,内含Designing .NET Class Libraries等13个演讲视频。此外,光盘还包括.NET Framework类和组件设计指南、API规范样例以及其他有用的资源和工具。 :数千名微软精锐开发人员的经验和智慧,最终浓缩在这本设计规范之中。与上一版相比,书中新增了许多评注,解释了相应规范的背景和历史,从中你能聆听到微软技术大师Anders Hejlsberg、Jeffrey Richter和Paul Vick等的声音,读来令人兴味盎然。   本书虽然是针对.NET平台上的框架设计的,但对其他平台的框架设计同样具有借鉴意义。新版根据.NET Framework 3.0和3.5的新特性做了全面更新,主要关注的是直接影响框架可编程能力的设计问题。遵守这些规范对于使用.NET Framework创建高质量的应用程序至关重要。   本书提供配套光盘,内含Designing .NET Class Libraries等13个演讲视频。此外,光盘还包括.NET Framework类和组件设计指南、API规范样例以及其他有用的资源和工具。 作者简介 -------------------------------------------------------------------------------- Krzysztof Cwalina 微软公司.NET Framework开发组项目经理。他为.NET Framework设计了多个API,还开发了FxCop等框架开发工具。目前,他正致力于在微软内部开发推广设计规范,将其应用到.NET Framework中,同时负责核心.NET Framework API的交付。 :Krzysztof Cwalina 微软公司.NET Framework开发组项目经理。他为.NET Framework设计了多个API,还开发了FxCop等框架开发工具。目前,他正致力于在微软内部开发推广设计规范,将其应用到.NET Framework中,同时负责核心.NET Framework API的交付。 目录 -------------------------------------------------------------------------------- 第1章 概述  1.1 精心设计的框架所具备的品质   1.1.1 精心设计的框架是简单的   1.1.2 精心设计的框架设计代价高   1.1.3 精心设计的框架充满利弊权衡   1.1.4 精心设计的框架应该借鉴过去的经验   1.1.5 精心设计的框架要考虑未来发展   1.1.6 精心设计的框架应具有良好的集成性   1.1.7 精心设计的框架是一致的 第2章 框架设计基础  2.1 渐进框架  2.2 框架设计的基本原则   2.2.1 围绕场景进行设计的原则   2.2.2 低门槛原则   2.2.3 自说明对象模型原则 显示全部信息 :第1章 概述  1.1 精心设计的框架所具备的品质   1.1.1 精心设计的框架是简单的   1.1.2 精心设计的框架设计代价高   1.1.3 精心设计的框架充满利弊权衡   1.1.4 精心设计的框架应该借鉴过去的经验   1.1.5 精心设计的框架要考虑未来发展   1.1.6 精心设计的框架应具有良好的集成性   1.1.7 精心设计的框架是一致的 第2章 框架设计基础  2.1 渐进框架  2.2 框架设计的基本原则   2.2.1 围绕场景进行设计的原则   2.2.2 低门槛原则   2.2.3 自说明对象模型原则   2.2.4 分层架构原则  2.3 小结 第3章 命名规范  3.1 大小写约定   3.1.1 标识符的大小写规则   3.1.2 首字母缩写词的大小写   3.1.3 复合词和常用术语的大小写   3.1.4 是否区分大小写  3.2 通用命名约定   3.2.1 单词的选择   3.2.2 使用单词缩写和首字母缩写词   3.2.3 避免使用编程语言特有的名字   3.2.4 为已有API的新版本命名  3.3 程序集和DLL的命名  3.4 名字空间的命名  3.5 类、结构和接口的命名   3.5.1 泛型类型参数的命名   3.5.2 常用类型的命名   3.5.3 枚举类型的命名  3.6 类型成员的命名   3.6.1 方的命名   3.6.2 属性的命名   3.6.3 事件的命名   3.6.4 字段的命名  3.7 参数的命名  3.8 资源的命名  3.9 小结 第4章 类型设计规范  4.1 类型和名字空间  4.2 类和结构之间的选择  4.3 类和接口之间的选择  4.4 抽象类的设计  4.5 静态类的设计  4.6 接口的设计  4.7 结构的设计  4.8 枚举的设计   4.8.1 标记枚举的设计   4.8.2 给枚举添加值  4.9 嵌套类型  4.10 类型和程序集元数据  4.11 小结 第5章 成员设计 第6章 扩展性设计 第7章 异常 第8章 使用规范 第9章 常用的设计模式 附录A C#编程风格约定 附录B 通过FxCop来实施设计规范 附录C API规格书样例 术语表 推荐读物

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值