导视设计网站推荐,手机访问另一部手机访问文件,mvc电子商务网站开发,wordpress数学插件设计模式 标签#xff08;空格分隔#xff09;#xff1a; 设计模式优点 应用场景 整理自《设计模式之禅》 单例模式 优点#xff1a; 只有一个实例#xff0c;减少了内存开支#xff1b;可以避免对系统资源的多重占用#xff1b;可以在系统中设置全局的访问点#xff…设计模式 标签空格分隔 设计模式优点 应用场景 整理自《设计模式之禅》 单例模式 优点 只有一个实例减少了内存开支可以避免对系统资源的多重占用可以在系统中设置全局的访问点优化和共享资源访问缺点 没有接口扩展困难对测试开发不利应用场景 要求生成唯一序列号的场景需要一个共享访问点创建一个对象需要消耗过多的资源时需要定义大量的静态常量和静态方法时也可直接声明为static的方式工厂方法模式 优点 良好的封装性代码结构清晰扩展非常好屏蔽产品类应用场景 是new一个对象的替代品需要灵活的可扩展的框架时使用在测试驱动开发的框架下抽象工厂模式 优点 封装性产品族内部的约束为非公开状态缺点 产品族扩展困难模板方法模式 优点 封装不变部分扩展可变部分把不变的算法封装到父类实现可变的部分则通过继承来扩展提取公共部分代码便于维护行为由父类控制子类实现;缺点 子类对父类产生影响子类执行的结果影响了父类的结果;应用场景 多个子类有公有的方法且逻辑相同时重要复杂的算法可以把核心算法设计为模板方法重构时把相同的代码抽取到父类然后通过钩子函数结束其行为建造者模式 优点 封装性使得客户端不必知道产品内部的组成细节我们不用关心每一个具体的模型内部是如何实现的。建造者独立容易扩展便于控制细节风险由于具体的建造者是独立的因此可以对建造过程逐步细化而不对其他的模块产生任何影响;建造者模式的应用场景 相同的方法不同的执行顺序会产生不同的结果时多个部件或零件都可以装配到一个对象中但产生的运行结果又不相同时如Android中的AlertDialog的构造;产品类非常复杂或产品类的的调用顺序不同产生不同的效果代理模式 优点 职责清晰其实的角色就是实现实际的业务的逻辑不用关心其他非本职责的事务高扩展性具体主题角色随时都会发生变化但只要它实现了接口我们的代理类就可以在完全不做任何修改的情况下使用原型模式通过实现Cloneable接口 优点 性能优良原型模式是在内存二进制流的拷贝要比直接new一个对象性能好特别是要在循环体内产生大量对象时避免构造函数的约束直接是在内存中拷贝的构造函数是不会执行的。应用场景 类初始化需要消化非常多的资源时性能和安全要求的场景通过 new产生一个对象需要非常繁琐的数据准备和访问权限时一个对象多个修改者的场景一个对象需要提供给多个对象访问而且各个调用者都可以修改其值时注意地方浅拷贝与深拷贝 Java的Object类提供的clone方法只是拷贝本对象其对象内部的数组、引用对象等都不拷贝其他的原始类型如int,char等都会被拷贝拷贝后的对象与原生对象共享内部元素的地址浅拷贝如果拷贝后的对象修改了原生对象的数组则原生对象也会看到修改。如果需要进行深拷贝则需要在复写的clone方法里对私有的类变量内部数组引用对象进行独立的拷贝。并且使用final关键字修饰的变量不能被拷贝 中介者模式 优点 减少了类间的依赖把原有的一对多的依赖变成了一对一的依赖 缺点中介者会膨胀得很大而且逻辑复杂原本N个对象的依赖关系转换为中介者与对象的依赖关系命令模式 优点 类间解耦调用者与接收者之间没有任何依赖关系调用者实现功能时不需要了解到底是哪个接收者执行只需调用Command抽象类的execute方法就可以了可扩展性Command的子类可以非常容易扩展并且调用者和高层模块不产生严重的代码耦合缺点 Command类膨胀厉害如果有N个命令则Command类的子类就为N个 应用场景如Android中各种事件的处理责任链模式 优点 请求与处理分开请求者可以不用知道是谁处理的处理者可以不用知道请求的全貌缺点 性能问题每个请求都是从链头遍历到链尾的当这个责任链比较长时遍历开销会比较大应用场景: 如Android事件的传递机制装饰器模式 优点 装饰类和被装饰类可以独立发展而不会互相耦合装饰模式是继承关系的一个替代方案不管装饰多少层最终返回的也还是那个对象装饰模式可以动态地扩展一个实现类的功能缺点 多层的装饰比较复杂当使用多层装饰出现问题时排查问题的工作量比较大应用场景 需要扩展一个类的功能或给一个类增加附加功能需要为一批兄弟类进行改装或加装功能策略模式 优点 算法可以自由切换只要实现抽象策略它就成为策略家庭的一个成员避免使用多重条件判断扩展性良好在现有的系统中增加一个策略太容易只要实现接口就可以了;缺点 策略类数量多每一个策略都是一个类复用的可能性很小所有的策略类都需要对外暴露上层模块必须知道有哪些策略然后决定使用哪一个策略应用场景 多个类只有在算法或行为上稍有不同的场景算法需要自由切换的场景需要屏蔽算法规则的场景适配器模式 优点 让两个没有任何联系的类在一起运行增加了类的透明性提高了类的复用度灵活性好当不需要适配器时只要删掉这个适配器就可以了应用场景 修改一个已经投产的接口时Android中各种Adapter迭代器模式 迭代器模式是为解决遍历容器中的元素而诞生的没有人会单独写一个迭代器使用Java提供的Itreator就可以满足要求了组合模式 优点 高层模块调用简单高层模块不需要关心自己处理的是单个对象还是整个组合结构节点可以自由增加缺点 调用时会直接使用实现类不符合面向接口编程思想应用场景 维护和展示部分-整体关系的场景如树型菜单文件和文件夹的管理只要是树型结构就要考虑使用组合模式观察者模式 优点 观察者与被观察者之间是抽象耦合不管是增加观察者还是被观察者都非常容易扩展建立一套触发机制缺点 一个被观察者多个观察者开发与调度会比较复杂在Java中消息的通知默认是顺序执行其中一个观察者卡壳会影响整体的执行效率一般要考虑采用异步的方式应用场景 关联行为场景如Android中数据变化会引起UI的变化事件多级触发场景跨系统的消息交换场景门面模式 优点 减少系统的相互依赖所有的依赖都是与门面对象的依赖与子系统无关。提高了灵活性提高了安全性想让你访问子系统的哪些业务就开通哪些逻辑缺点 不符合开闭原则当出现bug后只能通过修改门面角色的代码来修复应用场景 为一个复杂的模块或子系统提供一个供外界访问的接口如Android的Context类只是一个抽象类所有的功能都是在ContextImpl类实现的我们不会察觉到ContextImpl的存在只需要调用Context就可以了子系统相对独立外界对子系统的访问只要黑箱操作即可预防低水平开发人员带来的风险被限定在指定的子系统开发备忘录模式 应用场景 需要保存和恢复数据的相关状态场景提供一个可回滚的操作场景需要监控的副本场景中数据库连接的事务管理就是用的备忘录模式注意事项 备忘录的生命期要主动管理它的生命周期建立就要使用不使用就删除备忘录的性能不要在频繁建立备份的场景中使用备忘录模式对象的创建是需要消耗资源的访问者模式 优点 符合单一职责原则具体元素角色负责数据的加载而访问者类则负责数据的呈现优秀的扩展性灵活性非常高缺点 具体元素对访问者公布细节访问者要访问一个类就必须要求这个类公布一些方法和数据具体元素变更比较困难具体元素角色的增加、删除、修改都是比较困难违背了依赖倒置原则访问者依赖的是具体的元素而不是抽象的元素应用场景 一个对象结构包含很多类对象它们有不同的接口而你想对这些对象实施一些依赖于其具体类的操作需要对一个对象结构中的对象进行很多不同并且不相关的操作而你想避免让这些操作”污染“这些对象的类业务规则要求遍历多个不同的对象状态模式 优点 结构清晰避免了过多的switch...case或if...else语句的使用遵循设计原则每个状态就是一个子类封装性非常好将状态变换放置到类的内部来实现缺点 子类会太多也就是类膨胀有多少个状态就会有多少个子类 应用场景行为随状态改变而改变的场景如权限设计条件、分支判断语句的替代者通过扩展子类实现条件的判断处理状态的个数最好不要超过5个解释器模式现在使用较少 优点 扩展性好缺点 解释器模式会引起类膨胀采用了递归调用方法享元模式 优点 大大减少应用程序创建的对象降低程序内存的占用;缺点 提高了系统复杂性需要分离出内部和外部状态应用场景 系统中存在大量的相似对象需要缓冲池的场景细粒度的对象都具有较接近的外部状态且内部状态与环境无关桥梁模式 优点 抽象与实现分离优秀的扩充能力实现细节对客户透明应用场景 不希望或不适用继承的场景接口或抽象类不稳定的情况重要性要求较高的场景转载于:https://www.cnblogs.com/WoodJim/p/4715385.html
