24种设计模式及案例.docx
- 文档编号:9284133
- 上传时间:2023-02-04
- 格式:DOCX
- 页数:24
- 大小:31.11KB
24种设计模式及案例.docx
《24种设计模式及案例.docx》由会员分享,可在线阅读,更多相关《24种设计模式及案例.docx(24页珍藏版)》请在冰豆网上搜索。
24种设计模式及案例
24种设计模式及案例
关键时刻,第一时间送达!
个人Github-24种设计模式案例链接
维导图
创建型模式工厂模式
工厂模式(FactoryPattern)是Java中最常用的设计模式之一。
这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
在工厂模式中,我们在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象。
介绍意图:
定义一个创建对象的接口,让其子类自己决定实例化哪一个工厂类,工厂模式使其创建过程延迟到子类进行。
主要解决:
主要解决接口选择的问题。
何时使用:
我们明确地计划不同条件下创建不同实例时。
如何解决:
让其子类实现工厂接口,返回的也是一个抽象的产品。
关键代码:
创建过程在其子类执行。
应用实例:
1、您需要一辆汽车,可以直接从工厂里面提货,而不用去管这辆汽车是怎么做出来的,以及这个汽车里面的具体实现。
2、Hibernate换数据库只需换方言和驱动就可以。
优点:
1、一个调用者想创建一个对象,只要知道其名称就可以了。
2、扩展性高,如果想增加一个产品,只要扩展一个工厂类就可以。
3、屏蔽产品的具体实现,调用者只关心产品的接口。
缺点:
每次增加一个产品时,都需要增加一个具体类和对象实现工厂,使得系统中类的个数成倍增加,在一定程度上增加了系统的复杂度,同时也增加了系统具体类的依赖。
这并不是什么好事。
使用场景:
1、日志记录器:
记录可能记录到本地硬盘、系统事件、远程服务器等,用户可以选择记录日志到什么地方。
2、数据库访问,当用户不知道最后系统采用哪一类数据库,以及数据库可能有变化时。
3、设计一个连接服务器的框架,需要三个协议,'POP3'、'IMAP'、'HTTP',可以把这三个作为产品类,共同实现一个接口。
注意事项:
作为一种创建类模式,在任何需要生成复杂对象的地方,都可以使用工厂方法模式。
有一点需要注意的地方就是复杂对象适合使用工厂模式,而简单对象,特别是只需要通过new就可以完成创建的对象,无需使用工厂模式。
如果使用工厂模式,就需要引入一个工厂类,会增加系统的复杂度。
抽象工厂模式
抽象工厂模式(AbstractFactoryPattern)是围绕一个超级工厂创建其他工厂。
该超级工厂又称为其他工厂的工厂。
这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
在抽象工厂模式中,接口是负责创建一个相关对象的工厂,不需要显式指定它们的类。
每个生成的工厂都能按照工厂模式提供对象。
介绍意图:
提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。
主要解决:
主要解决接口选择的问题。
何时使用:
系统的产品有多于一个的产品族,而系统只消费其中某一族的产品。
如何解决:
在一个产品族里面,定义多个产品。
关键代码:
在一个工厂里聚合多个同类产品。
应用实例:
工作了,为了参加一些聚会,肯定有两套或多套衣服吧,比如说有商务装(成套,一系列具体产品)、时尚装(成套,一系列具体产品),甚至对于一个家庭来说,可能有商务女装、商务男装、时尚女装、时尚男装,这些也都是成套的,即一系列具体产品。
假设一种情况(现实中是不存在的,要不然,没法进入共产主义了,但有利于说明抽象工厂模式),在您的家中,某一个衣柜(具体工厂)只能存放某一种这样的衣服(成套,一系列具体产品),每次拿这种成套的衣服时也自然要从这个衣柜中取出了。
用OO的思想去理解,所有的衣柜(具体工厂)都是衣柜类的(抽象工厂)某一个,而每一件成套的衣服又包括具体的上衣(某一具体产品),裤子(某一具体产品),这些具体的上衣其实也都是上衣(抽象产品),具体的裤子也都是裤子(另一个抽象产品)。
优点:
当一个产品族中的多个对象被设计成一起工作时,它能保证客户端始终只使用同一个产品族中的对象。
缺点:
产品族扩展非常困难,要增加一个系列的某一产品,既要在抽象的Creator里加代码,又要在具体的里面加代码。
使用场景:
1、QQ换皮肤,一整套一起换。
2、生成不同操作系统的程序。
注意事项:
产品族难扩展,产品等级易扩展。
单例模式
单例模式(SingletonPattern)是Java中最简单的设计模式之一。
这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建。
这个类提供了一种访问其唯一的对象的方式,可以直接访问,不需要实例化该类的对象。
注意:
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例。
介绍意图:
保证一个类仅有一个实例,并提供一个访问它的全局访问点。
主要解决:
一个全局使用的类频繁地创建与销毁。
何时使用:
当您想控制实例数目,节省系统资源的时候。
如何解决:
判断系统是否已经有这个单例,如果有则返回,如果没有则创建。
关键代码:
构造函数是私有的。
应用实例:
1、一个党只能有一个主席。
2、Windows是多进程多线程的,在操作一个文件的时候,就不可避免地出现多个进程或线程同时操作一个文件的现象,所以所有文件的处理必须通过唯一的实例来进行。
3、一些设备管理器常常设计为单例模式,比如一个电脑有两台打印机,在输出的时候就要处理不能两台打印机打印同一个文件。
优点:
1、在内存里只有一个实例,减少了内存的开销,尤其是频繁的创建和销毁实例(比如管理学院首页页面缓存)。
2、避免对资源的多重占用(比如写文件操作)。
缺点:
没有接口,不能继承,与单一职责原则冲突,一个类应该只关心内部逻辑,而不关心外面怎么样来实例化。
使用场景:
1、要求生产唯一序列号。
2、WEB中的计数器,不用每次刷新都在数据库里加一次,用单例先缓存起来。
3、创建的一个对象需要消耗的资源过多,比如I/O与数据库的连接等。
注意事项:
getInstance()方法中需要使用同步锁synchronized(Singleton.class)防止多线程同时进入造成instance被多次实例化。
建造者模式(构建者模式)
建造者模式(BuilderPattern)使用多个简单的对象一步一步构建成一个复杂的对象。
这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
一个Builder类会一步一步构造最终的对象。
该Builder类是独立于其他对象的。
介绍意图:
将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。
主要解决:
主要解决在软件系统中,有时候面临着'一个复杂对象'的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法却相对稳定。
何时使用:
一些基本部件不会变,而其组合经常变化的时候。
如何解决:
将变与不变分离开。
关键代码:
建造者:
创建和提供实例,导演:
管理建造出来的实例的依赖关系。
应用实例:
1、去肯德基,汉堡、可乐、薯条、炸鸡翅等是不变的,而其组合是经常变化的,生成出所谓的'套餐'。
2、JAVA中的StringBuilder。
优点:
1、建造者独立,易扩展。
2、便于控制细节风险。
缺点:
1、产品必须有共同点,范围有限制。
2、如内部变化复杂,会有很多的建造类。
使用场景:
1、需要生成的对象具有复杂的内部结构。
2、需要生成的对象内部属性本身相互依赖。
注意事项:
与工厂模式的区别是:
建造者模式更加关注与零件装配的顺序。
原型模式
原型模式(PrototypePattern)是用于创建重复的对象,同时又能保证性能。
这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
这种模式是实现了一个原型接口,该接口用于创建当前对象的克隆。
当直接创建对象的代价比较大时,则采用这种模式。
例如,一个对象需要在一个高代价的数据库操作之后被创建。
我们可以缓存该对象,在下一个请求时返回它的克隆,在需要的时候更新数据库,以此来减少数据库调用。
介绍意图:
用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。
主要解决:
在运行期建立和删除原型。
何时使用:
1、当一个系统应该独立于它的产品创建,构成和表示时。
2、当要实例化的类是在运行时刻指定时,例如,通过动态装载。
3、为了避免创建一个与产品类层次平行的工厂类层次时。
4、当一个类的实例只能有几个不同状态组合中的一种时。
建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
如何解决:
利用已有的一个原型对象,快速地生成和原型对象一样的实例。
关键代码:
1、实现克隆操作,在JAVA继承Cloneable,重写clone(),在.NET中可以使用Object类的MemberwiseClone()方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。
2、原型模式同样用于隔离类对象的使用者和具体类型(易变类)之间的耦合关系,它同样要求这些'易变类'拥有稳定的接口。
应用实例:
1、细胞分裂。
2、JAVA中的Objectclone()方法。
优点:
1、性能提高。
2、逃避构造函数的约束。
缺点:
1、配备克隆方法需要对类的功能进行通盘考虑,这对于全新的类不是很难,但对于已有的类不一定很容易,特别当一个类引用不支持串行化的间接对象,或者引用含有循环结构的时候。
2、必须实现Cloneable接口。
使用场景:
资源优化场景。
类初始化需要消化非常多的资源,这个资源包括数据、硬件资源等。
性能和安全要求的场景。
通过new产生一个对象需要非常繁琐的数据准备或访问权限,则可以使用原型模式。
一个对象多个修改者的场景。
一个对象需要提供给其他对象访问,而且各个调用者可能都需要修改其值时,可以考虑使用原型模式拷贝多个对象供调用者使用。
在实际项目中,原型模式很少单独出现,一般是和工厂方法模式一起出现,通过clone的方法创建一个对象,然后由工厂方法提供给调用者。
原型模式已经与Java融为浑然一体,大家可以随手拿来使用。
注意事项:
与通过对一个类进行实例化来构造新对象不同的是,原型模式是通过拷贝一个现有对象生成新对象的。
浅拷贝实现Cloneable,重写,深拷贝是通过实现Serializable读取二进制流。
结构型模式
适配器模式
适配器模式(AdapterPattern)是作为两个不兼容的接口之间的桥梁。
这种类型的设计模式属于结构型模式,它结合了两个独立接口的功能。
这种模式涉及到一个单一的类,该类负责加入独立的或不兼容的接口功能。
举个真实的例子,读卡器是作为内存卡和笔记本之间的适配器。
您将内存卡插入读卡器,再将读卡器插入笔记本,这样就可以通过笔记本来读取内存卡。
我们通过下面的实例来演示适配器模式的使用。
其中,音频播放器设备只能播放mp3文件,通过使用一个更高级的音频播放器来播放vlc和mp4文件。
介绍意图:
将一个类的接口转换成客户希望的另外一个接口。
适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
主要解决:
主要解决在软件系统中,常常要将一些'现存的对象'放到新的环境中,而新环境要求的接口是现对象不能满足的。
何时使用:
1、系统需要使用现有的类,而此类的接口不符合系统的需要。
2、想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作,这些源类不一定有一致的接口。
3、通过接口转换,将一个类插入另一个类系中。
(比如老虎和飞禽,现在多了一个飞虎,在不增加实体的需求下,增加一个适配器,在里面包容一个虎对象,实现飞的接口。
)如何解决:
继承或依赖(推荐)。
关键代码:
适配器继承或依赖已有的对象,实现想要的目标接口。
应用实例:
1、美国电器110V,中国220V,就要有一个适配器将110V转化为220V。
2、JAVAJDK1.1提供了Enumeration接口,而在1.2中提供了Iterator接口,想要使用1.2的JDK,则要将以前系统的Enumeration接口转化为Iterator接口,这时就需要适配器模式。
3、在LINUX上运行WINDOWS程序。
4、JAVA中的jdbc。
优点:
1、可以让任何两个没有关联的类一起运行。
2、提高了类的复用。
3、增加了类的透明度。
4、灵活性好。
缺点:
1、过多地使用适配器,会让系统非常零乱,不易整体进行把握。
比如,明明看到调用的是A接口,其实内部被适配成了B接口的实现,一个系统如果太多出现这种情况,无异于一场灾难。
因此如果不是很有必要,可以不使用适配器,而是直接对系统进行重构。
2.由于JAVA至多继承一个类,所以至多只能适配一个适配者类,而且目标类必须是抽象类。
使用场景:
有动机地修改一个正常运行的系统的接口,这时应该考虑使用适配器模式。
注意事项:
适配器不是在详细设计时添加的,而是解决正在服役的项目的问题。
装饰器模式
装饰器模式(DecoratorPattern)允许向一个现有的对象添加新的功能,同时又不改变其结构。
这种类型的设计模式属于结构型模式,它是作为现有的类的一个包装。
这种模式创建了一个装饰类,用来包装原有的类,并在保持类方法签名完整性的前提下,提供了额外的功能。
我们通过下面的实例来演示装饰器模式的用法。
其中,我们将把一个形状装饰上不同的颜色,同时又不改变形状类。
介绍意图:
动态地给一个对象添加一些额外的职责。
就增加功能来说,装饰器模式相比生成子类更为灵活。
主要解决:
一般的,我们为了扩展一个类经常使用继承方式实现,由于继承为类引入静态特征,并且随着扩展功能的增多,子类会很膨胀。
何时使用:
在不想增加很多子类的情况下扩展类。
如何解决:
将具体功能职责划分,同时继承装饰者模式。
关键代码:
1、Component类充当抽象角色,不应该具体实现。
2、修饰类引用和继承Component类,具体扩展类重写父类方法。
应用实例:
1、孙悟空有72变,当他变成'庙宇'后,他的根本还是一只猴子,但是他又有了庙宇的功能。
2、不论一幅画有没有画框都可以挂在墙上,但是通常都是有画框的,并且实际上是画框被挂在墙上。
在挂在墙上之前,画可以被蒙上玻璃,装到框子里;这时画、玻璃和画框形成了一个物体。
优点:
装饰类和被装饰类可以独立发展,不会相互耦合,装饰模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能。
缺点:
多层装饰比较复杂。
使用场景:
1、扩展一个类的功能。
2、动态增加功能,动态撤销。
注意事项:
可代替继承。
代理模式
在代理模式(ProxyPattern)中,一个类代表另一个类的功能。
这种类型的设计模式属于结构型模式。
在代理模式中,我们创建具有现有对象的对象,以便向外界提供功能接口。
介绍意图:
为其他对象提供一种代理以控制对这个对象的访问。
主要解决:
在直接访问对象时带来的问题,比如说:
要访问的对象在远程的机器上。
在面向对象系统中,有些对象由于某些原因(比如对象创建开销很大,或者某些操作需要安全控制,或者需要进程外的访问),直接访问会给使用者或者系统结构带来很多麻烦,我们可以在访问此对象时加上一个对此对象的访问层。
何时使用:
想在访问一个类时做一些控制。
如何解决:
增加中间层。
关键代码:
实现与被代理类组合。
应用实例:
Windows里面的快捷方式。
猪八戒去找高翠兰结果是孙悟空变的,可以这样理解:
把高翠兰的外貌抽象出来,高翠兰本人和孙悟空都实现了这个接口,猪八戒访问高翠兰的时候看不出来这个是孙悟空,所以说孙悟空是高翠兰代理类。
买火车票不一定在火车站买,也可以去代售点。
一张支票或银行存单是账户中资金的代理。
支票在市场交易中用来代替现金,并提供对签发人账号上资金的控制。
springaop。
优点:
1、职责清晰。
2、高扩展性。
3、智能化。
缺点:
由于在客户端和真实主题之间增加了代理对象,因此有些类型的代理模式可能会造成请求的处理速度变慢。
实现代理模式需要额外的工作,有些代理模式的实现非常复杂。
使用场景:
按职责来划分,通常有以下使用场景:
1、远程代理。
2、虚拟代理。
3、Copy-on-Write代理。
4、保护(ProtectorAccess)代理。
5、Cache代理。
6、防火墙(Firewall)代理。
7、同步化(Synchronization)代理。
8、智能引用(SmartReference)代理。
注意事项:
和适配器模式的区别:
适配器模式主要改变所考虑对象的接口,而代理模式不能改变所代理类的接口。
和装饰器模式的区别:
装饰器模式为了增强功能,而代理模式是为了加以控制。
外观模式
外观模式(FacadePattern)隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口。
这种类型的设计模式属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性。
这种模式涉及到一个单一的类,该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
介绍意图:
为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
主要解决:
降低访问复杂系统的内部子系统时的复杂度,简化客户端与之的接口。
何时使用:
客户端不需要知道系统内部的复杂联系,整个系统只需提供一个'接待员'即可。
定义系统的入口。
如何解决:
客户端不与系统耦合,外观类与系统耦合。
关键代码:
在客户端和复杂系统之间再加一层,这一层将调用顺序、依赖关系等处理好。
应用实例:
去医院看病,可能要去挂号、门诊、划价、取药,让患者或患者家属觉得很复杂,如果有提供接待人员,只让接待人员来处理,就很方便。
JAVA的三层开发模式。
优点:
1、减少系统相互依赖。
2、提高灵活性。
3、提高了安全性。
缺点:
不符合开闭原则,如果要改东西很麻烦,继承重写都不合适。
使用场景:
为复杂的模块或子系统提供外界访问的模块。
子系统相对独立。
预防低水平人员带来的风险。
注意事项:
在层次化结构中,可以使用外观模式定义系统中每一层的入口。
桥接模式
桥接(Bridge)是用于把抽象化与实现化解耦,使得二者可以独立变化。
这种类型的设计模式属于结构型模式,它通过提供抽象化和实现化之间的桥接结构,来实现二者的解耦。
这种模式涉及到一个作为桥接的接口,使得实体类的功能独立于接口实现类。
这两种类型的类可被结构化改变而互不影响。
我们通过下面的实例来演示桥接模式(BridgePattern)的用法。
其中,可以使用相同的抽象类方法但是不同的桥接实现类,来画出不同颜色的圆。
介绍意图:
将抽象部分与实现部分分离,使它们都可以独立的变化。
主要解决:
在有多种可能会变化的情况下,用继承会造成类爆炸问题,扩展起来不灵活。
何时使用:
实现系统可能有多个角度分类,每一种角度都可能变化。
如何解决:
把这种多角度分类分离出来,让它们独立变化,减少它们之间耦合。
关键代码:
抽象类依赖实现类。
应用实例:
猪八戒从天蓬元帅转世投胎到猪,转世投胎的机制将尘世划分为两个等级,即:
灵魂和肉体,前者相当于抽象化,后者相当于实现化。
生灵通过功能的委派,调用肉体对象的功能,使得生灵可以动态地选择。
墙上的开关,可以看到的开关是抽象的,不用管里面具体怎么实现的。
优点:
1、抽象和实现的分离。
2、优秀的扩展能力。
3、实现细节对客户透明。
缺点:
桥接模式的引入会增加系统的理解与设计难度,由于聚合关联关系建立在抽象层,要求开发者针对抽象进行设计与编程。
使用场景:
如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系,通过桥接模式可以使它们在抽象层建立一个关联关系。
对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统,桥接模式尤为适用。
一个类存在两个独立变化的维度,且这两个维度都需要进行扩展。
注意事项:
对于两个独立变化的维度,使用桥接模式再适合不过了。
组合模式
组合模式(CompositePattern),又叫部分整体模式,是用于把一组相似的对象当作一个单一的对象。
组合模式依据树形结构来组合对象,用来表示部分以及整体层次。
这种类型的设计模式属于结构型模式,它创建了对象组的树形结构。
这种模式创建了一个包含自己对象组的类。
该类提供了修改相同对象组的方式。
我们通过下面的实例来演示组合模式的用法。
实例演示了一个组织中员工的层次结构。
介绍意图:
将对象组合成树形结构以表示'部分-整体'的层次结构。
组合模式使得用户对单个对象和组合对象的使用具有一致性。
主要解决:
它在我们树型结构的问题中,模糊了简单元素和复杂元素的概念,客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。
何时使用:
您想表示对象的部分-整体层次结构(树形结构)。
您希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。
如何解决:
树枝和叶子实现统一接口,树枝内部组合该接口。
关键代码:
树枝内部组合该接口,并且含有内部属性List,里面放Component。
应用实例:
算术表达式包括操作数、操作符和另一个操作数,其中,另一个操作符也可以是操作数、操作符和另一个操作数。
在JAVAAWT和SWING中,对于Button和Checkbox是树叶,Container是树枝。
优点:
1、高层模块调用简单。
2、节点自由增加。
缺点:
在使用组合模式时,其叶子和树枝的声明都是实现类,而不是接口,违反了依赖倒置原则。
使用场景:
部分、整体场景,如树形菜单,文件、文件夹的管理。
注意事项:
定义时为具体类。
享元模式
享元模式(FlyweightPattern)主要用于减少创建对象的数量,以减少内存占用和提高性能。
这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结构的方式。
享元模式尝试重用现有的同类对象,如果未找到匹配的对象,则创建新对象。
我们将通过创建5个对象来画出20个分布于不同位置的圆来演示这种模式。
由于只有5种可用的颜色,所以color属性被用来检查现有的Circle对象。
介绍意图:
运用共享技术有效地支持大量细粒度的对象。
主要解决:
在有大量对象时,有可能会造成内存溢出,我们把其中共同的部分抽象出来,如果有相同的业务请求,直接返回在内存中已有的对象,避免重新创建。
何时使用:
1、系统中有大量对象。
2、这些对象消耗大量内存。
3、这些对象的状态大部分可以外部化。
4、这些对象可以按照内蕴状态分为很多组,当把外蕴对象从对象中剔除出来时,每一组对象都可以用一个对象来代替。
5、系统不依赖于这些对象身份,这些对象是不可分辨的。
如何解决:
用唯一标识码判断,如果在内存中有,则返回这个唯一标识码所标识的对象。
关键代码:
用HashMap存储这些对象。
应用实例:
1、JAVA中的String,如果有则返回,如果没有则创建一个字符串保存在字符串缓存池里面。
2、数据库的数据池。
优点:
大大减少对象的创建,降低系统的内存,使效率提高。
缺点:
提高了系统的复杂度,需要分离出外部状态和内部状态,而且外部状态具有固有化的性质,不应该随着内部状态的变化而变化,否则会造成系统的混乱。
使用场景:
1、系统有大量相似对象。
2、需要缓冲池的场景。
注意事项:
1、注意划分外部状态和内部状态,否则可能会引起线程安全问题。
2、这些类必须有一个工厂对象加以控制。
行为型模式策略模式
在策略模式
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 24 设计 模式 案例
![提示](https://static.bdocx.com/images/bang_tan.gif)