软件体系结构(SoftwareArchitecture)内容软件构造技术的发展软件复用技术（1/2）软件复用技术（2/2）软件框架概念的出现软件框架的概念软件框架的概念(续)框架的分类框架的特性——部分实现框架的特性—“反向控制”框架的特性—固定点和扩展点框架特性相关概念相关概念相关概念相关概念相关概念相关概念内容软件框架构造技术框架的开发领域分析——共性和变化性变化性分类变化性分类（续）扩展点（1/3）扩展点——OOF扩展点——OOF(续)扩展点——OOF(续)扩展点——CBF扩展点——CBF扩展点——CBF扩展点——CBF小结——OOF和CBF的不同框架描述语言（1/6）框架描述语言（2/6）框架描述语言（3/6）框架描述语言（4/6）框架描述语言（5/6）框架描述语言（6/6）框架的测试（1）框架的测试（2）框架的维护（1）框架的维护（2）框架的演化（1/2）框架的演化（2/2）框架构造原则单一职责原则（SRP）开放-封闭原则(TheOpen-ClosedPrinciple,OCP)Liskov替换原则(LSP)依赖倒置原则(DIP)接口隔离原则(ISP)现在的问题是，如何建立类TimerClient和类TimedDoor之间的关联，才能在超时时通知TimedDoor中相应的处理代码？下面给出了一种可想到的方案：现在,类Door依赖于TimerClient。该方案的主要问题就出现在这里。1）不是所有种类的Door都需要定时功能。最初的Door与定时功能没有任何关系，如果需要创建一个没有定时功能的派生类，那么就必须要提供TimeOut方法的“退化”实现，这就违反了接口分离原则。2）另外，使用这些派生类的应用程序，即使不使用定义的TimerClient，也必须引入之，因此就具有不必要的复杂性和不必要的重复-“臭味”。这是一个接口污染问题：1）Door的接口被一个它不需要的方法污染了-在Door的接口中加入这个方法只是为了给它的子类带来好处。2）如果这样持续下去的话，每一次子类需要一个新方法时，就被加入到基类中，这样就可能进一步污染了接口，使它“胖”了起来。3、实现分离接口的途径1）分离客户（程序）就是分离接口Door的接口和TimerClient的接口完全被不同的客户程序所使用，即Timer使用TimerClient，而对Door的操作使用了类Door。既然客户程序是分离的，所以接口也应该保持分离。原因是客户程序对它们使用的接口是有影响的。2）使用委托分离接口创建一个由TimerClient所派生的对象，并把该对象的请求委托给TimedDoor.对这一方案的分析:1)该方案遵循了ISP,并避免了Door的客户程序和之间的耦合.2)即使对Timer的进行了修改,也不会影响Door的使用者.其中Timer的定义如下:ClassTimer{public:voidRegister(inttimeout,inttimeoutID,TimeCclient*client);};ClassTimerClient{public:virtualvoidTimeOut(inttimeoutID)=0;};3)TimedDoor也不必具有和TimerClient一样的接口;4)DoorTimerAdapter会将TimerClient接口转换为TimedDoor接口.因此，这是一个非常通用的解决方案。5)该方案尽管是一种通用的,但不是很优雅的.即每次想去注册一个超时请求时,都要创建一个新的对象.这对于那些对内存和运行时间要求高的系统而言,例如嵌入式实时系统,就显得不够理想。结论1、胖类可以导致它们的客户程序之间产生不正常的、且有害的耦合关系。当一个客户程序要求该胖类进行一个修改时，会影响到其他所有客户程序。因此，客户程序应该仅仅依赖它们实际调用的方法。2、把胖类的接口分解为多个特定于客户程序的接口，可以实现以上目标。每个特定于客户程序的接口仅仅声明它的特定客户或客户组调用的那些函数，接着该胖类就可以继承所有特定于客户程序的接口，并实现它们。这就解除了客户程序和它们没有调用的方法之间的依赖关系，并使客户程序之间互不依赖。小结：框架技术带来的好处内容SanFrancisco背景目标目标SF体系结构的特点SF体系结构（1）SF体系结构（2）SF体系结构（3）SF体系结构（4）SF体系结构（5）Foundation层FoundationClassEntityDependentCommandSanFrancisco的编程模式通用商业对象层（CBO）CBOcategoriesCBOcategoriesCBOcategories设计模式设计模式核心商业过程