单例模式,也叫单子模式,是一种常用的软件设计模式。在应用这个模式时,单例对象的必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象,这样有利于我们协调系统整体的行为。比如在某个服务器程序中,该服务器的配置信息存放在一个文件中,这些配置数据由一个单例对象统一读取,然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。

例:Object counter() to count the quantity of users

抽象工厂模式英语:Abstract factory pattern)是一种软件开发设计模式。抽象工厂模式提供了一种方式,可以将一组具有同一主题的单独的工厂封装起来。在正常使用中,客户端程序需要创建抽象工厂的具体实现,然后使用抽象工厂作为接口来创建这一主题的具体对象。客户端程序不需要知道(或关心)它从这些内部的工厂方法中获得对象的具体类型,因为客户端程序仅使用这些对象的通用接口。抽象工厂模式将一组对象的实现细节与他们的一般使用分离开来。

举个例子来说,比如一个抽象工厂类叫做DocumentCreator(文档创建器),此类提供创建若干种产品的接口,包括createLetter()(创建信件)和createResume()(创建简历)。其中,createLetter()返回一个Letter(信件),createResume()返回一个Resume(简历)。系统中还有一些DocumentCreator的具体实现类,包括FancyDocumentCreatorModernDocumentCreator。这两个类对DocumentCreator的两个方法分别有不同的实现,用来创建不同的“信件”和“简历”(用FancyDocumentCreator的实例可以创建FancyLetterFancyResume,用ModernDocumentCreator的实例可以创建ModernLetterModernResume)。这些具体的“信件”和“简历”类均继承自抽象类,即LetterResume类。客户端需要创建“信件”或“简历”时,先要得到一个合适的DocumentCreator实例,然后调用它的方法。一个工厂中创建的每个对象都是同一个主题的(“fancy”或者“modern”)。客户端程序只需要知道得到的对象是“信件”或者“简历”,而不需要知道具体的主题,因此客户端程序从抽象工厂DocumentCreator中得到了LetterResume类的引用,而不是具体类的对象引用。

“工厂”是创建产品(对象)的地方,其目的是将产品的创建与产品的使用分离。抽象工厂模式的目的,是将若干抽象产品的接口与不同主题产品的具体实现分离开。这样就能在增加新的具体工厂的时候,不用修改引用抽象工厂的客户端代码。

使用抽象工厂模式,能够在具体工厂变化的时候,不用修改使用工厂的客户端代码,甚至是在运行时。然而,使用这种模式或者相似的设计模式,可能给编写代码带来不必要的复杂性和额外的工作。正确使用设计模式能够抵消这样的“额外工作”。

信息学中,微内核英语:Microkernel,μ-kernel),又称为微核心,是一种内核的设计架构,由一群尽可能将数量最小化的软件程序组成,它们负责提供、实现一个操作系统所需要的各种机制与功能。这些最基础的机制,包括了底层地址空间管理,线程管理,与进程间通讯(IPC)。

这样的设计,使内核中最核心的功能,设计上变的更简单。需要特权的进程,只有基本的线程管理,内存管理进程间通信等,这个部分,由一个简单的硬件抽象层与关键的系统调用组成。其余的服务进程,则移至用户空间。

让服务各自独立,可以减少系统之间的耦合度,易于实现与除错,也可增进可移植性。它可以避免单一组件失效,而造成整个系统崩溃,内核只需要重新启动这个组件,不致于影响其他服务器的功能,使系统稳定度增加。同时,操作系统也可以视需要,抽换或新增某些服务进程,使功能更有弹性。

回归测试软件测试的一种,旨在检验软件原有功能在修改后是否保持完整。

回归测试过程

  1. 识别出软件中被修改的部分

  2. 从原基线测试用例库“T”中,排除所有不再适用的测试用例,确定对新版本依然有效的测试用例,创建新的基线测试用例库“TN”

  3. 依据一定的策略从TN中选择测试用例测试被修改的软件

  4. 如果必要,生成新的测试用例集“T1”,用于测试TN无法充分测试的软件部分

  5. 用T1执行修改后的软件

  • 第2和第3步测试验证修改是否破坏了现有的功能,第4和第5步测试验证修改工作本身。