2018正版葡京赌侠诗《.NET 设计规范》第 9 章:常用的设计方式

第 9 章:常用的设计情势

9.1 聚合组件

  考虑为常用的本性域提供聚合组件。

  要用聚合组件来对高层的概念(物理对象)举行建模,而不是对系统级的义务拓展建模。

  要让聚合组件的名字与肯定的种类实体相对应,比如
MessageQueue、Process 或 伊芙ntLog,那样就能使项目尤其分明。

  要在安插聚合组件时使伊始化尽大概地几乎,这样用户只需进行简要的开首化就可以运用组件。即使某一项起先化是必不可少的,那么由于没有对组件进行初阶化而吸引的要命应该肯定地报告用户应该怎么办。

  不要须要聚合组件的用户在一个场地中显式地实例化多少个对象。

  要保管让聚合组件帮忙 Create-Set-Call
使用形式,那样用户就足以先实例化组件,然后设置它的特性,最后调用一些简短的法门,以促成多数光景。

  要为全部的聚众组件提供私行认同构造函数或万分简单的构造函数。

  要为聚合组件提供可读写的质量来与构造函数中的全数参数相呼应。

  要在聚集组件中行使事件,不要使用基于委托的 API。

  考虑用事件来代表须求被遮盖的虚成员。

  不要须求聚合组件的用户在常用场景中使用持续、覆盖措施及贯彻接口。

  不要须求聚合组件的用户在常用场景中除了编写代码之外,还要做任何的做工。例如,不应当让用户用配备文件来安顿组件,也不该让用户生成能源文件,等等。

  考虑让聚合组件可以自行切换状态。

  不要涉及有五种情况的因数类型。

  考虑将集结组件集成到 VS 的设计器中。

  考虑把聚合组件和因子类型分开,各自放在不相同的顺序集中。

  考虑把聚合组件内部的因数类型暴光给外界访问。

 

9.2 Async 模式

  要贯彻基于事件的 Async 格局 –
借使类型是三个资助可视化设计器的零部件(相当于说类型达成了 IComponent)。

  要达成经典的 Async 格局 – 若是非得协助等待句柄。

  考虑在得以落成高层 API 时使用基于事件的 Async
方式。例如,聚合组件就应有完毕该情势。

  考虑在落到实处底层 API 时使用经典的 Async
方式,在那种情景下更强硬的效益、更少的内存消耗、更好的八面见光、更少的磁盘占用要比可用性更关键。

  防止在同二个类型中照旧是一组有关的项目中并且落到实处几种 Async 方式。

  要在为异步操作定义 API 时坚守上边的预约。给定名为 Operation
的协同方法,应该提供名为 BeginOperation 和 EndOperation
的不二法门,它们的不二法门签名如上边所示(注意,输出参数不是必不可少的)。

  要保证 Begin 方法的回来类型完成了 IAsyncResult 接口。

  要力保联合方法的按值传递和按引用传递的参数在 Begin
方法中都是按值传递的。同步方法的出口参数不该出现在 Begin
方法的签署中。

  要确保 End 方法的回来类型与共同方法的回到类型相同。

  要确保同步方法的别样输出参数和按引用传递的参数都用作 End
方法的输出参数。同步方法中安排传递的参数不应有出现在 End 方法的签署中。

  不要继续执行异步操作 – 借使 Begin 方法抛出了拾叁分。

  要一次通过下边的体制来打招呼调用方异步操作已经形成。

    将 IAsyncResult.IsCompleted 设为 true。

    激活 IAsyncResult.AsyncWaitHandle 再次回到的等候句柄。

    调用异步回调函数。

  要经过从 End 方法中抛出尤其来代表爱莫能助得逞地完毕异步操作。

  要在 End 方法被调用时一起完结全体没有形成的操作。。

  考虑抛出 InvalidOperationException 非凡 – 假使用户用同2个IAsyncResult 一次调用 End 方法,或 IAsyncResult 是从另1个不相干的 Begin
方法重返的。

  要把 IAsyncResult.CompletedSynchronously 设为 true –
当且仅当异步回调函数将在调用 Begin 方法的线程中运维的时候。

  要确保在科学的线程中调用事件处理程序。与经典 Async
方式比较,那是采纳基于事件的 Async 方式的严重性利益之一。

  要确保无论是操作已经达成,照旧操作失误,依然操作被收回,都以种会调用事件处理程序。不应该让应用程序无停歇地等候一间永远不会生出的风云

  要力保在异步操作退步后,访问时间参数类的特性会掀起那多少个。换句话说,如若有荒唐造成操作无法完结,那么就不该允许用户访问操作的结果。

  不要为回到值为空的方法定义新的事件处理程序或事件参数类型。要采纳AsyncCompleted伊夫ntArgs,AsyncCompleted伊芙ntHandler 或
伊夫ntHandler<AsyncCompleted伊夫ntArg>。

  要力保一旦在一个一步操作中落到实处了 PaogressChanged
事件,那么在操作的已毕事件被触发之后,不应有再出新此类事件。

  要保管一旦选择了正规的 ProgressChanged伊芙ntArgs,那么
ProgressPercentage
始终能用来代表进程的百分比(不必然要完全标准,但象征的自然要百分比)。倘诺利用的不是正规进度,那么从
ProgressChanged伊芙ntArgs 派生壹个子类会更贴切,那种场所下相应保持
ProgressPercentage 为 0 ;

  要在有增量结果要求报告的时候动身 ProgressChanged 事件。

  要对 ProgressChanged伊夫ntArgs
举行扩大来保存增量结果数据,并用扩大后的光阴参数类来定义 ProgressChanged
事件。

  要把增量结果报告与进度报告分开。

  要为每种异步操作定义单独的 <MethodName>ProgreessChanged
事件和对应的事件参数类,来拍卖该操作的增量结果数据。

  

9.3 珍惜属性

  要提供信赖属性 – 即便需求用他们来支撑种种 WPF
天性,比如样式、触发器、数据绑定、动画、动态能源以及三番五次。

  要在筹划正视属性的时候继承自 DependencyObject
或它的子类型。该类型完成的质量存储区卓殊火速,它还自行协理 WPF
的数量绑定。

  要为每一个看重属性提供正规的 CL途观 属性和存放
System.Windows.DependencyProperty 实例的公有静态只读字段。

  要通过调用 DependencyObject.GetValue 和 DependencyObject.SetValue
的法子来促成依靠属性。

  要用依赖属性的名字加上“Property”后缀来命名看重属性的静态字段。

  不要显式地在代码中装置正视属性的暗许值,应该在元数据中设置专断认同值。

  不要在性质的访问器中添加额外的代码,而应该运用正规代码来拜访静态字段。

  不要采取依赖属性来保存保密数据。任何代码都能访问依赖属性,即使它们是私家的。

  不要把吝惜属性的表达逻辑放在访问器中,而相应把验证毁掉函数传给
DependencyProperty.Register 方法。

  不要在依靠属性的访问器中贯彻属性改变的文告,而相应向
PropertyMetadata
注册改成文告的回调函数,后者是倚重属性本人提供的一项特征,为了支持改变布告,必须使用该特性。

  不要在依靠属性的访问器中贯彻属性强制赋值逻辑,而相应向
PropertyMetadata
注册强制赋值的回调函数。后者是依靠属性本身提供的一项特征,为了协理强制赋值,必须使用该天性。

  

9.4 Disopse 模式

  要为含有可处以项目实例的花色完毕基本 Dispose 格局。

  要为类型达成大旨 Dispose 格局并提供终结方法 –
如若类型持有必要由开发人士显式释放的花色,而且后者自己并未终止方法。

  考虑为类完结中央 Dispose 形式 –
若是类本人并不负有非托管能源或可处以对象,不过它的子类型却可能会有所非托管能源或可处以对象。

  要按下边的办法来促成 IDisposable 接口,即先调用
Dispose(true),然后再调用 GC.SuppressFinalize(this)。

  不要将无参数的 Dispose 方法定义为虚方法。

  不要为 Dispose 方法申明除了 Dispose() 和 Dispose(bool)
之外的其余其余重载方法。

  要允许数十次调用 Dispose(bool)
方法。他可以在首先次调用之后就如何也不做。

  幸免从 Dispose(bool)
方法中抛出十三分,除非是殷切情状,所处的进程已经受到破坏(比如泄漏、共享状态不平等,等等)。

  要从分子中抛出 ObjectDisposedException 十分 –
固然该成员在目的终结之后就无法持续应用。

  考虑在 Dispose() 方法之外在提供贰个 Close() 方法 – 如果 close
是该领域中的多少个正经术语。

  防止定义可竣事类型。

  不要定义可完工的值类型。

  要将类型定义为可竣事类型 –
即便该品种要负责释放非托管能源,且非托管财富本人不有所终结方法。

  要为全部的可完工类型落成核心 Dispose 形式。

  不要在停止方法中走访任何可竣事对象,那样做存在很大的危害,因为被访问的目的只怕曾经被终止了。

  要将 Finalize 方法定义为受保证的。

  不要在截止方法中放过任何格外,除非是沉重的连串错误。

  考虑创造三个用来急迫处境的可竣事对象 –
如若得了方法在应用程序域被胁制卸载或线程万分退出的事态下都不或许不要实践。

 

9.5 Factory 模式

  要先行接纳构造函数,而不是事先使用工厂,因为与特种的目的协会机制比较,构造函数一般的话更便于拔取、更平等,也更有益。

  考虑拔取工厂 – 即使构造函数提供的目标创立机制不可以满意须要。

  要动用工厂 –
如果开发人士只怕不知情待成立的对象的卓殊品种,比如对基类或接口编程就属于那种气象。

  考虑接纳工厂方法 – 假设那是让操作不言自明的唯一方法。

  要在更换风格的操作中应用 factory。

  要硬着头皮将工厂操作方法完毕为艺术,而不是达成为属性。

  要通过措施的重回值而不是办法的出口参数来回到新创立的靶子实例。

  考虑把 Create 和要创建的门类名连在同步,五遍来命名工厂方法。

  考虑把要创造的品类名和 Factory
连在一起,四回来命名工厂类型。例如,可以考虑把成立 Control
对象的工厂类型命名为 ControlFactory。

  

9.6 对 LINQ 的支持

  要促成 IEnumerabl<T>,其目标是为着获取基本的 LINQ 援救。

  考虑落成 ICollection<T>,其目的是为着增强查询的品质。

  考虑达成 IQueryable<T> – 倘若非得要访问传给 IQueryable
的分子的查询表明式。

  不要草率地完结IQueryable<T>,要精晓那样做恐怕会对质量爆发什么震慑。

  要在 IQueryable<T> 的办法中抛出 NotSupportedException –
假如您的数据源上不协理该操作。

  要在新类型校官 Query 方式完结为实例方法 – 若是在 LINQ
以外的地方,那些格局在档次中仍旧有存在的含义。否则,应该将它们贯彻为伸张方法。

  要让贯彻了 Query 格局在类型已毕了 IEnumerable<T>。

  考虑在统筹 LINQ
操作符时,让它们再次回到领域蓄意的可枚举类型。即使从实质上的话,Select
查询艺术可以回到任何项目,可是大家平时都指望查询的结果是可枚举类型。

  幸免只兑现 Query 情势的一有个别 – 假若不期望退回去基本的
IEnuerable<T> 完结。

  要为有序系列定义单独的种类,从而将它和呼应的无序种类分开。那样的连串应该定义
ThenBy 方法。

  要延缓执行实际的查询操作。对 Query
方式的绝大部分分子来说,小编盼望它们只是创立3个新的靶子,并在枚举的时候才发生集合重负荷查询条件的因素。

  要将用来查询的壮大方法放在主命名空间中的二个名为“Linq”
的子命名空间中。例如,为 System.Data 性格定义的扩充方法被放在
System.Data.Linq 命名空间。

  要在参数中行使 Expression<Func<…>>,而不是
Func<…> – 借使须要查询查询表明式。

 

9.7 Optional Feature 模式

  考虑将 Optional Feature 方式用于抽象中的可选特性。

  要提供一个几乎的布尔属性来让用户检测对象是或不是帮衬可选性情。

  要在积累团长可选特性定义为虚方法,并在该格局中抛出
NotSupportedException 极度。

  

9.8 Simulated Convariance 模式

  考虑接纳 Simulated Convariance 形式 –
即使须求有一种统一的品种来代表泛型类型的保有实例。

  要保障以等价的办法来促成基础类型成员和呼应的泛型类型成员。

  考虑动用抽象基类来代表根基类型,而不是行使接口来表示根基类型。

  考虑用非泛型类型作为基础类型 – 尽管这么的项目已经存在。

  

9.9 Template Method 模式

  幸免将国有成员定义为虚成员。

  考虑动用 Template Method 方式来更好地操纵扩充性。

  考虑以非秀成员的名字加“Core”后缀为名字,来定名为该费虚成员提供扩充点的受保险的虚成员。

  

9.10 超时

  要事先让用户通过参数来制订超时长度。

  要先期采纳 TimeSpan 来代表超时长度。

  要在逾期后抛出 System.TimeoutException 很是。

  不要通过重返错误码的办法来告诉用户爆发了晚点。

  

9.11 可供 XAML 使用的品类

  考虑提供暗中同意构造函数 – 若是想让项目能用于 XAML。

  要提供标记扩充 – 倘诺想让 XAML 读取程序可以创造不可变的种类。。

  防止定义新的门类转换器,除非那样的更换是自但是直观的。一般的话,应该将项目转换器的行使限制限制在
.NET 框架中早就运用了连串转换器的地点。

  考虑将 ContentPropertyAttribute 用于最常用的特性,从而拿到更有利于的
XAML 语法。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注