英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料
C#设计模式
詹姆斯·库珀
摘要：软件开发群体已经对模式产生了共鸣，并出版了大量著作来记录软件开发的模式。这些书籍记录了软件过程的最佳时间、高级体系结构，以及软件在类级别的设计，同时，与模式有关的新书还在不断出版。如果你需要选择译本有关模式的书籍，你应该首先花一些时间去读一读那些对已出版书记的评论，然后，从中选择译本对你帮助最大的书籍，并将其作为你的学习对象。
关键词：模式 软件开发 软件过程 体系结构 设计
一个模式是一种方案，利用这种方案，我们可以完成某项工作。一个模式也是一种途径，通过这种途径，我们可以达到某个目的。同时，一个模式也是一种技术。为了完成某项工作，我们必须获取并利用有效的技术。这种思想可以应用于多种工作，例如：做饭、制造烟火、开发软件以及其他工作。如果某乡工作所属的领域正在不段的完善，那么，这个领域的从业人员会去寻找一些通用的、有效的解决方案，利用这些方案，在不用的环境下解决相关问题，从而达到完成工作的目的。某个领域的从业人员经常会产生该领域的习惯用语，这些习惯用语有助于相关人员对工作进行交流。模式也是一些习惯用语。所谓模式，就是一些能够完成特定任务并达到任务目标的现成技术。随着某项技术及相关习惯用语的发展，一些人将这项技术及模式记录成文，这些记录下来的文献使习惯用语得到标准化，并使一些行之有效的技术得到了广泛传播。
Christopher Alexander 就是把某种技巧的最佳事实方案旧路为模式的先驱者之一。他的研究领域是建筑学，而不是软件。在其著作《A Pattern Language：Towns，Buildings，Construction》一书中，Alexander提出了建造房屋和建设城市的成功模式。Alexander的著作影响深远，因此也影响到软件领域。这部著作之所以能够影响到其他领域，部分也是因为作者对目的具有独特的观察方式。
你可能会认为，建筑模式的目的就是“设计建筑”。但是Alexander明确提出，应用建筑模式的目的是服务于那些以后要居住在这些建筑物内或居住在这些城市中的人们，并使他们感到舒适和欣慰。Alexander的工作表明，模式是一种获取并交流某个技术领域知识的极好途径。同时他也指出，合理地认识并记录某项工作的目的是非常关键的，这需要哲学的思考，同时还面临着难以捉摸的挑战。
软件开发群体已经对模式产生了共鸣，并出版了大量著作来记录软件开发的模式。这些书籍记录了软件过程的最佳时间、高级体系结构，以及软件在类级别的设计，同时，与模式有关的新书还在不断出版。如果你需要选择译本有关模式的书籍，你应该首先花一些时间去读一读那些对已出版书记的评论，然后，从中选择译本对你帮助最大的书籍，并将其作为你的学习对象。
抽象的说，一个类的接口是由这个类的某些方法和字段构成的一个集合。其他类的对象实例可以通过这个集合对这个类进行访问。借口通常表达了方法执行的操作所提供的功能职责，这些职责往往用方法的名称、代码注释，以及其他文档进行描述说明。一个类的实现指的是在类方法中实现的代码。
C#语言改进了接口的概念，使之可以单独进行构造，从而把接口（即：一个对象必须做什么）和实现（即：一个对象如何满足其功能职责）有效地区分开来。C#语言的接口允许多个类提供同一个功能，同时，C#的接口也可以使一个类实现多个接口。
有好几个设计模式可以利用C#所提供的特征。例如：我们可以用一个接口来适配某个类的接口，这实际是通过应用适配器模式来满足一个客户的需求。为了讨论某些无法用C#语言完成的工作，我们应该了解C#语言是如何完成工作的，所以我们首先讨论C#语言的接口。
如果你确实无法使用接口，那么，你可以使用抽象类（C 语言提供了抽象类）。然而，在n层（n-tier）软件开发和对象定义构造等方面，接口具有关键的作用。与此类似的是，如果你确实无法使用委托，那么你可以使用接口。如果某个公共任务需要注册一个方法来进行回调，那么，委托可以改进这类任务，因此，C#语言提供的委托是一项非常有用的内容。
接口与抽象类
请指出C#语言的抽象类与接口之间的三种不同之处。
在使用上，一个没有提供非抽象方法的抽象类与一个接口是类似的。然而，我们需要注意以下几点：
一个类可以实现任意多个接口，但是最多只能对一个抽象类进行子类化。
一个抽象类可以包括非抽象方法，而一个接口的所有方法在效果上都是抽象的。
一个抽象类可以声明并使用变量，而一个接口不能。
一个抽象类中的方法的访问修饰符可以是public、internal、protected、protected internal或者是private，而接口成员的访问修饰符在默认情况下都是public，而且，在声明接口成员时，不允许使用访问修饰符（甚至不允许使用public访问修饰符）。
一个抽象类可以定义构造函数，而一个接口不能。
接口与委托
接口与委托的比较：
接口与委托的相似之处在于它们都可以定义我们所期望的功能。我们在学习使用委托的过程中经常会产生一些混乱，究其原因，部分是由于“委托”这个词，它可以表达含义具有微小差别的不同概念。在对委托和接口进行比较之前，我们有必要回顾一下委托在C#语言中是如何工作的。
C#语言的关键字delegate引入了一种新的委托类型，这种新的委托类型可以确定什么类型的方法才可以用于实例化这种委托类型。委托类型没有规范方法的名称，但是它规范了方法的参数类型和返回类型。
我们考虑以下声明：
Public delegate object BorrowReader（IDataReader reader）；
这条语句声明了一个新的委托类型。委托类型的名称是BorrowReader。声明指出该委托类型可以用任何方法进行实例化，只要这个方法接收一个IDataReader对象作为方法参数，并且方法返回类型为object。假定某个类中有以下方法：
Pricate static object GetNames(IDataReader reader)
{
//hellip;
}
GetNames()方法的参数类型和返回类型满足BorrowReader委托类型的规范定义，因此可以使用这个方法名称对委托类型进行实例化，实例化语句如下：
变量b是一个BorrowReader委托类型的实例。任何能够访问该委托实例的代码都可以调用对象b，然后委托实例将调用对象b包容的方法。之所以使用对象实例b，是因为这个方案具有以下优点：其他方法可以在合适的时候调用对象b及其包容的方法。例如：一个数据服务类可以获得一个数据库读取器，调用一个BorrowReader委托实例（即把上述读取器传递给这个委托实例），然后把这个数据库读取器作为一个资源进行释放。
一个C#接口可以包容方法、C#属性（property），以及索引器。一个接口也可以包容时间，但是不能包容委托。为什么？
我们可以简单地给出以下解释：
Delegate关键字引入了一个新的类型，而event关键字引入了一个新的成员。一个接口声明规范了成员，而不是类型，因此时间可以归入接口，而委托不能归入接口。
而详细的解释是：
Event关键字声明了一个特定类型的字段（一个“事件”），规范了其类型（必须是一个委托类型）及其名称。C#限制了对事件的访问，客户不能使用事件类型（其委托类型）的所有行为。客户只能使用委托所提供的 =和-=行为。这种限制所产生的结果之一是：只有声明类可以调用（或激发）一个事件。但是，只要使某个类包容一个public事件成员，一个接口客户的组成类就可以实例化上述那个类。因为事件是一个类的接口的标准组成部分，因此我们有充分的理由让接口包括事件。
当采用委托对单个方法进行回调时，一个基于接口的设计是同样有效的。但是如果设计中需要使用委托来持有并调用多哥方法时，那么，采用委托更为清晰。特别是当一个对象使用一个委托让多个客户对一个事件（例如“点击”事件）进行注册的时候，这个优点尤其突出。一个时间是一个成员，这个成员可以使一个对象或者类提供通知消息。
理解C#语言的委托可能非常困难，特别是因为我们重复定义了“委托”这个术语的意义。例如，我们可以使用“委托”这个术语表示一个委托声明、委托类型，甚至一个委托实例。特别是，人们经常说“调用一个委托”，但是一个对象只能调用一个委托的实例，而不能调用一个委托的类型。如果你感觉这部分内容有些混乱难解，别担心，很多人都是如此。但是我们确实应该认真研究在C#中委托是如何工作的，因为这不仅是理解应用程序如何工作的关键，也是理解类之间如何进行交互的关键。
接口与属性
C#语言的借口可以规范接口实现必须提供的索引器或者C#属性。如果你定义了一个新的集合类型，那么就需要规范一个索引器。如果你做出了以下声明，即某个实现中必须包括一个方法，而这个方法要使用一个属性值，并且（或者）需要设置这个属性值，那么，你就需要规范一个C#属性。
以下代码声明了一个没有使用C#属性的接口，但是在实现时，需要提供对一个广告对象的属性的访问。
Public interface IAdvertisement
{
Int GetID();
String GetADCopy();
Void SetADCopy(string text);
}
上述代码中的接口是Oozinoz系统中Showproperties类库的一部分。简单说来，这个接口为其实现规范了两个C#属性，但严格说来，它们并非C#属性。使用C#的语法进行C#属性规范的优点是其语法比较优雅。但是，最重要的一点是，不具备预见能力的客户可以通过反射检测到C#属性的存在。例如，只要相关对象属性是真正的C#属性，一个Datagrid对象就可以在一个ArrayList集合中显示相关对象的属性。
在一个接口中，C#属性的表示是依赖于语法的，因此在实现接口时会产生一些差异。我们应该深入理解使用C#接口特征的相关概念和使用细节。
接口的细节
C#接口的主要优势在于，接口把对象的交互进行了限制。这种限制实际上是一种解放。就一个实现了某个接口的类而言，这个类可能在提供这个接口服务功能的过程中发生了许多变化，但是这些变化不会影响到这个类的客户。虽然使用借口的目的很容易理解，但是在时间中，细节又迫使开发人员不断地求助于参考资料。
接口描述了类在交互过程中的期望行为和不期望行为。接口与纯抽象类很类似，接口定义了它应该完成的功能，但是并没有实现这些功能。接口与委托也很类似，当然，委托仅仅对每个方法规范了方法参数以及返回类型。
委托也是类型，因此一个接口无法包容一个委托并把它当作一个成员。然而委托类型的变量和标记了event关键字的变量可以出现在接口中。
除了方法和事件，接口还可以包容索引器和属性。这些内容的语法非常重要，因为客户可以通过使用这些成员类型以及使用反射，检测并了解实现类（实现类指实现了接口的类）的行为。掌握如何应用C#接口的概念和细节非常重要，因此这值得你花费一些时间。这部分内容也是许多功能呢感强大的设计的核心内容，同时也是几种设计模式的核心。
普通接口无法提供的内容
使用C#接口可以简化并加强系统设计，当然，有时候借口的设计可能会超出一般接口的定义范围和使用范围。
如果希望把一个类的接口与一个客户的期望接口进行适配，那么可以应用适配器模式。
如果你希望为类的集合提供一个简单的接口，那么可以应用外观模式。
如果你希望定义一个接口，使之可以应用于耽搁对象，也可以应用于对象组，那么可以应用合成模式。
如果你希望将一个抽象与其实现进行分离，使之可以相互独立变化，那么可以应用桥接模式。
每个设计模式的目的是：在一个特定的语境中解决一个问题。基于接口的模式强调了语境，因为语境决定了我们是否需要定义或重新定义对方法的访问手段，这些方法既可以是一个类的方法，也可以是一组类的方法。例如：如果某个类提供了我们所需要的服务，但是方法名称与客户所期望的方法名称并不匹配，那么我们就可以使用适配器模式解决这个问题。
如果一个对象需要调用我们开发的代码，那么这个对象是一个客户。在某些情况下，客户的代码在我们的代码完成之后才开发的，因此开发人员可以要求可户的代码服从我们的对象接口规范。但是在某些情况下，可户的代码也可以独立开发。例如：一个火箭仿真程序需要使用我们提供的火箭信息，但是仿真程序也定义了火箭的工作方式。这种情况下，我们会发现，现有的类已经提供了客户所需要的服务，但是方法的名称却不相同。这时，我们就可以应用适配器模式。适配器模式的目的在于：如果客户需要使用某个类的服务，而这项服务是这个类用一个不同的接口提供的，那么，可以使用适配器模式为客户提供一个期望的接口。
C#语言与JAVA语言的不同之处就在于：C#语言不需要方法对任何可能抛出的异常进行声明。这是否是一个良好特性？请给出你的结论和相关理由。
在一个方法首部之外对异常进行声明的原因是：
我们应该首先注意，JAVA语言并不要求方法声明所有可能抛出的异常。例如，任何方法都可能遇到一个空指针，然后抛出一个未声明的异常。甚至JAVA语言的设计者也承认，强迫程序员声明所有可能的异常是一个不切实际的想法。应用程序需要一种策略，并根据此策略处理所有的异常。要求开发人员声明某种类型异常的方法是不能替代这种异常处理策略的。
另一方面：程序员应该得到所有他们能够得到的帮助。确实，一个应用程序的体系结构应该具有一个可靠的
全文共5812字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[9209]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
