第12章 装饰模式
- 格式:pptx
- 大小:1.62 MB
- 文档页数:26
第12章虚拟仪器技术虚拟仪器是在20世纪后期随计算机水平和软件技术的迅速进步而出现并发展起来的有别于传统仪器的新概念。
虚拟仪器技术突破了传统电子仪器以硬件为主体的模式,具有用简单硬件将被测量采集到上位机,然后通过软件设计即可方便灵活地完成对被测试量的分析、判断、显示及数据存储等功能的特点。
软件设计的灵活易变、成本低等特点使虚拟仪器在测试测量技术中越来越发挥出其优势。
目前,虚拟仪器的开发工具有LabVIEW、LabWINDOWS、VB等,下面主要介绍用NI 公司的LabVIEW软件开发虚拟仪器的方法。
本书第13章到17章的综合实例是在计算机上对整个测量系统的联合软件仿真设计,因此在本章后面将介绍用LabVIEW同NI公司的另一款电路仿真软件Multisim进行联合仿真的方法。
12.1 LabVIEW软件的特点LabVIEW(Laboratory Virtual Instrument Engineer Workbench,实验室虚拟仪器工作平台)是美国NI公司推出的一种基于G语言(Graphics Language,图形化编程语言)的具有革命性的图形化虚拟仪器开发环境,是业界领先的测试、测量和控制系统的开发工具。
虚拟仪器的概念是用户在通用计算机平台上,在必要的数据采集硬件的支持下,根据测试任务的需要,通过软件设计来实现和扩展传统仪器的功能。
传统台式仪器是由厂家设计并定义好功能的一个封闭结构,有固定的I/O接口和仪器操作面板。
每种仪器只能实现一类特定的测量功能,并以确定的方式提供给用户。
虚拟仪器的出现,打破了传统仪器由厂家定义,用户无法改变的模式,使得用户可以根据自己的需求,设计自己的仪器系统,并可通过修改软件来改变或增减仪器的功能,真正体现了“软件就是仪器”这一新概念。
作为虚拟仪器的开发软件,LabVIEW的特点如下。
➢具有图形化的编程方式,设计者无须编写任何文本格式的代码,是真正的工程师语言➢提供丰富的数据采集,分析及存储的库函数➢提供传统的数据调试手段,如设置断点,单步运行,同时提供独具特色的执行工具,使程序动画式进行,利于设计者观察到程序运行的细节,使程序的调试和开发更为便捷➢囊括了PCI,GPIB,PXI,VXI,RS-232/485,USB等各种仪器通信总线标准的所有功能函数,使得不懂得总线标准的开发者也能驱动不同总线标准接口设备与仪器➢提供大量与外部代码或软件进行连接的机制,如DLL(动态链接库),DDE(共享库),Activex等➢具有强大的Internet功能,支持常用的网络协议,方便网络,远程测控仪器开发在测试和测量方面,LabVIEW已经变成了一种工业的标准开发工具;在过程控制和工厂自动化应用方面,LabVIEW软件非常适用于过程监测和控制;而在研究和分析方面,LabVIEW软件有力的软件分析库提供了几乎所有经典的信号处理函数和大量现代的高级信号的分析。
装饰模式和职责链模式的对比在软件开发中,设计模式是一个十分重要的概念,是指在软件设计过程中可以重复使用的解决问题的方案。
其中,装饰模式和职责链模式都是常见的设计模式,本文将对这两种模式进行比较分析。
一、装饰模式装饰模式,是指在不改变现有对象的基础上,动态地添加一些新的功能。
这种模式通过创建一个包装对象,也可以叫做装饰器来实现。
在装饰器模式中,有三个主要角色,分别是抽象构件(Component)、具体构件(ConcreteComponent)和装饰器(Decorator)。
其中,抽象构件角色定义了抽象接口,具体构件角色实现抽象接口,而装饰器角色继承了抽象构件角色,并持有一个具体构件的实例,起到包装的作用。
装饰模式的优点是可以动态地添加或删除功能,而且可以从不同的角度来扩展一个类的功能,避免了继承带来的代码复杂性和类爆炸问题。
但缺点是装饰层数过多会增加程序的复杂度,也可能会导致增加了过多的类。
二、职责链模式职责链模式,是指通过建立一个请求的处理链,并且每个节点都有处理请求的机会,直到请求被处理完成。
这种模式拥有很强的扩展性,可以根据需要动态地改变请求的处理流程。
在职责链模式中,有两个主要角色,分别是处理者(Handler)和请求(Request)。
处理者是职责链上的节点,每个处理者都可以处理请求,如果请求不能被当前处理者处理,则将请求传递给下一级处理者。
请求则封装了请求的内容和需要执行的操作。
职责链模式的优点是将请求发送者和接收者解耦,可以动态地改变请求的处理流程,可以避免请求发送者和处理者之间的紧耦合关系。
但缺点是会导致请求的处理延迟,也需要合理设计职责链的节点顺序,避免请求被一直传递下去。
三、装饰模式和职责链模式的比较1. 功能不同装饰模式是为对象动态地添加功能,而职责链模式则是为了解耦并且动态地改变请求的处理流程。
2. 使用场景不同装饰模式适用于需要动态地添加或删除功能的场景,也适用于不想使用继承或希望从不同角度扩展类功能的场景。
装饰者模式的使用方法和案例分享装饰者模式(Decorator Pattern)是一种常用的设计模式,在软件开发中十分实用。
它能够动态地将责任附加到对象上,从而实现对象功能的扩展,同时避免重复代码的产生。
本文将介绍装饰者模式的使用方法以及一些实际案例的分享。
一、装饰者模式的定义装饰者模式是指在不改变原有对象结构的情况下,动态地扩展该对象的功能。
该模式通过一种装饰器对象来包裹原有对象,并在运行时动态地添加新的行为。
二、装饰者模式的实现装饰者模式的实现需要定义一个包装类和一个抽象组件类。
包装类实现了抽象组件类,并定义了一个指向抽象组件类的指针,从而实现对抽象组件类的扩展。
抽象组件类是被装饰的类,定义了抽象接口。
三、装饰者模式的优点1. 可以动态地添加或删除功能。
2. 可以避免重复代码的产生,减少代码的复杂程度。
3. 可以提高代码的可扩展性和维护性。
四、装饰者模式的实际案例分享1. Java I/O模块Java I/O模块是一个典型的使用装饰者模式的实例。
Java I/O模块通过InputStream和OutputStream来处理输入输出流,通过FileInputStream和FileOutputStream来处理文件输入输出流,同时还可以通过BufferedInputStream和BufferedOutputStream来实现缓冲输入输出流和过滤输入输出流。
这些类的组合和复合就是通过装饰者模式实现的,从而实现了输入输出流的灵活性和可扩展性。
2. GUI开发中的控件美化在GUI开发中,控件美化也是一个典型的应用场景。
通过使用装饰者模式,可以动态地修改一个控件的外观和功能,而不需要修改源代码。
例如,可以通过直接继承一个控件类,实现控件的装饰,从而实现控件的美化。
3. 日志记录日志记录也是一个常见的应用场景。
通过使用装饰者模式,可以自定义不同类型的日志记录器,从而实现日志记录的灵活性和可扩展性。
例如,可以自定义一个输出到数据库的日志记录器,一个输出到文件的日志记录器等。
实验报告实验二装饰者模式的运用一、实验目的:装饰者模式动态地将责任附加到对象上,若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
在熟悉装饰者模式相关理论知识的基础上,使用装设者模式实现米线店结账小程序。
二、实验要求:使用装饰者模式实现米线店结账程序,要求如下:1.米线有三种,干浆、酸浆和水米线。
2.配料有三种,豆腐、鸡蛋、牛肉,今后还会更多。
3.客户可疑随心所欲的要各种米线搭配各种配料,配料可以加同一种加多份,或者不同种加多份。
1、设计并绘制该程序的类图;2、依照设计的类图使用Java语言编写代码,并实现该程序;3、除了核心的模式相关类实现外,提供测试环境,按照难度高低,分别是:a)控制台程序,Client硬编码初始化模式和测试环境,运行结果文本输出;b)控制台程序,Client初始化测试环境,并根据用户输入运算,运行结果文本输出;c)设计并实现用户UI,Client初始化测试环境,并根据用户在UI控件上的输入运算,运行结果文本输出;三、实验内容:类图代码抽象类public abstract class Ricenoodle{public String descrption="米线";public abstract double cost();public String getDescrption() {return descrption;}}基类public class Dry_rice extends Ricenoodlepublic Dry_rice(){this.descrption="干浆米线";}public double cost() {return 5;}}public class Wintercherry_rice extends Ricenoodle{ public Wintercherry_rice(){this.descrption="酸浆米线";}public double cost() {return 6;}}public class Water_rice extends Ricenoodle{public Water_rice(){this.descrption="水米线";}public double cost() {return 6;}}配料装饰类public abstract class CondimentDecorator extends Ricenoodle{ public abstract String getDescrption();配料public class Tofu extends CondimentDecorator{ Ricenoodle r;public Tofu(Ricenoodle r){this.r=r;}public String getDescrption() {return r.getDescrption()+"加豆腐";}public double cost() {return r.cost()+2;}}public class egg extends CondimentDecorator{Ricenoodle r;public egg(Ricenoodle r){this.r=r;}public String getDescrption() {return r.getDescrption()+"加鸡蛋";}public double cost() {return r.cost()+1.5;}}public class beef extends CondimentDecorator{Ricenoodle r;public beef(Ricenoodle r){this.r=r;}public String getDescrption() {return r.getDescrption()+"加牛肉";}public double cost() {return r.cost()+4;}}订单测试import java.util.Scanner;public class test {public static void main(String[] args) {Ricenoodle []order=new Ricenoodle[3] ;Scanner sc = new Scanner(System.in);order[0]=new Dry_rice();order[1]=new Wintercherry_rice();order[2]=new Water_rice();System.out.println("输入选项选择米线种类 1 干浆米线,2 酸浆米线,3 水米线");int mi =sc.nextInt();System.out.println("您购买了一份"+order[mi-1].getDescrption());for(int i=0;i<2;){System.out.println("输入选项选择调料 1 豆腐,2鸡蛋,3牛肉,4不加");int ve =sc.nextInt();order[mi-1]=new Tofu(order[mi-1]);System.out.println("当前订单为"+order[mi-1].getDescrption());}else if(ve==2){order[mi-1]=new egg(order[mi-1]);System.out.println("当前订单为"+order[mi-1].getDescrption());}else if(ve==3){order[mi-1]=new beef(order[mi-1]);System.out.println("当前订单为"+order[mi-1].getDescrption());}elsei=4;System.out.println("是否还要加调料 1 yes 2no");int k=sc.nextInt();if(k==1){i=1;}else{i=4;sc.close();}}+"\n价格为:"+order[mi-1].cost());}}运行结果四、实验总结:通过本次实验,加深了对装饰者模式意图,使用场景以及使用效果的理解,提升了编程能力。
LZ到目前已经写了九个设计模式,回过去看看,貌似写的有点凌乱,LZ后面会尽量改进。
那么本章LZ和各位读友讨论一个与JAVA中IO有着不解情缘的设计模式,装饰器模式。
定义:装饰模式是在不必改变原类文件和使用继承的情况下,动态的扩展一个对象的功能。
它是通过创建一个包装对象,也就是装饰来包裹真实的对象。
这一个解释,引自百度百科,我们注意其中的几点。
1,不改变原类文件。
2,不使用继承。
3,动态扩展。
上述三句话一语道出了装饰器模式的特点,下面LZ给出装饰器模式的类图,先上图再解释。
从图中可以看到,我们装饰的是一个接口的任何实现类,而这些实现类也包括了装饰器本身,装饰器本身也可以再被装饰。
另外,这个类图只是装饰器模式的完整结构,但其实里面有很多可以变化的地方,LZ给出如下两条。
1,Component接口可以是接口也可以是抽象类,甚至是一个普通的父类(这个强烈不推荐,普通的类作为继承体系的超级父类不易于维护)。
2,装饰器的抽象父类Decorator并不是必须的。
那么我们将上述标准的装饰器模式,用我们熟悉的JAVA代码给诠释一下。
首先是待装饰的接口Component。
packagecom.decorator;publicinterfaceComponent{voidmethod();}接下来便是我们的一个具体的接口实现类,也就是俗称的原始对象,或者说待装饰对象。
packagecom.decorator;publicclassConcreteComponentimplementsComponent{publicvoidmethod(){System.out.println("原来的方法");}}下面便是我们的抽象装饰器父类,它主要是为装饰器定义了我们需要装饰的目标是什么,并对Component进行了基础的装饰。
packagecom.decorator;publicabstractclassDecoratorimplementsComponent{protectedComponentcomponent;publicDecorator(Componentcomponent){super();ponent=component;}publicvoidmethod(){component.method();}}再来便是我们具体的装饰器A和装饰器B。