做啥网站能挣钱,wordpress自定义全局变量,洛阳制作网站ihanshi,seo自动优化工具UML泛化#xff08;继承非抽象类#xff09;#xff1a;带空心三角形的直线表示实现#xff08;继承抽象类#xff0c;类实现接口#xff09;#xff1a;带空心三角形的虚线表示依赖#xff1a;类与类之间最弱的关系#xff0c;依赖可以简单的理解一个类使用了另一个类…UML泛化继承非抽象类带空心三角形的直线表示实现继承抽象类类实现接口带空心三角形的虚线表示依赖类与类之间最弱的关系依赖可以简单的理解一个类使用了另一个类带箭头的虚线表示依赖关联一个类和另一类有联系带箭头的实线表示关联关系是一种包含关系在UML中用一个带箭头的实线表示箭头指向被包含类。在UML类中有如下几种。1..1表示另一个类的一个对象只与该类的一个对象有关系0..*表示另一个类的一个对象与该类的零个或多个对象有关系1..*表示另一个类的一个对象与该类的一个或多个对象有关系0..1表示另一个类的一个对象没有或只与该类的一个对象有关系* 任意多个对象关联聚合表示整体与部分的关系但是部分可以脱离整体而存在带空心菱形的直线加箭头表示has-a关系组合部分和整体的关系但是部分存活周期受到整体的影响若整体不存在则部分也将不存在。此时部分需在整体的构造方法中创建带实心菱形的直线加箭头表示。关系所表现的强弱程度依次为组合聚合关联依赖软件设计七大原则开闭原则:对扩展开放对修改封闭。在程序需要进行拓展的时候不能去修改原有的代码而是要扩展原有代码实现一个热插拔的效果。所以一句话概括就是为了使程序的扩展性好易于维护和升级。单一职责原则:不要存在多于一个导致类变更的原因也就是说每个类应该实现单一的职责否则就应该把类拆分。里氏替换原则:任何基类可以出现的地方子类一定可以出现。依赖倒置原则:面向接口编程依赖于抽象而不依赖于具体。写代码时用到具体类时不与具体类交互而与具体类的上层接口交互。接口隔离原则:每个接口中不存在子类用不到却必须实现的方法如果不然就要将接口拆分。使用多个隔离的迪米特法则:一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂都应该将逻辑封装在方法的内部通过public方法提供给外部。这样当被依赖的类变化时才能最小的影响该类。接口比使用单个接口多个接口方法集合到一个的接口要好。合成复用原则:尽量首先使用合成/聚合的方式而不是使用继承。创建型工厂方法模式定义定义一个创建对象的接口但让实现这里接口的类来决定实例化那个类工厂方法让类的实例化推迟到子类中进行优点用户只需要关心所需要产品的工厂无需关心创建细节加入新产品符合开闭原则提高扩展性缺点类的个数容易过多增加复杂度增加了系统的抽象性和理解难度适用场景创建对象需要大量重复的代码应用层不依赖于产品类实例如何被创建、实现等细节一个类通过其子类来指定创建那个对象抽象工厂模式定义抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口优点具体产品在应用层代码隔离无需关心创建细节将一个系列的产品族统一到一起创建缺点规定了所有可能被创建的产品集合产品族中扩展新的产品困难需要修改抽象工厂的接口增加了系统的抽象性和理解难度适用场景应用层不依赖于产品类实例如何被创建、实现等细节强调一系列相关的产品对象属于同一产品族一起使用创建对象需要大量重复代码提供一个产品类的库所有产品以同样的接口出现从而使应用层依赖于具体实现单例模式注意私有构造器、线程安全、延迟加载、序列化和反序列化安全、反射、cpu乱序执行优化定义保证一个类仅有一个实例并提供一个全局访问点优点在内存里只有一个实例减少了内存开销可以避免对资源的多重占用设置全局访问点严格控制访问缺点没有接口、扩展困难适用场景想确保任何情况下都绝对只有一个实例建造者模式定义将一个复杂对象的构建与它的表示分离使得同样的构建过程可以创建不同的表示优点封装性好创建和使用隔离扩展性好、建造类之间独立、一定程度上解耦缺点会产生多余的Builder对象使用Lombok的注解可以避免产品内部发生变化建造者都要修改成本较大Lombok可以解决适用场景如果一个对象有非常多的属性想把复杂对象的创建和使用分离原型模式定义指定原型实例指定创建对象的种类并且通过拷贝这些原型创建新的对象优点比直接new一个对象性能高简化创建过程缺点必须配备克隆方法对克隆复杂对象或对克隆出的对象进行复杂改造时容易引入风险深拷贝、浅拷贝要运用得当适用场景类初始化消耗较多资源new产生的一个对象需要非常繁琐的过程数据准备、访问权限等构造函数比较复杂循环体中产生大量对象时行为型适配器模式定义将一个类的接口转换成客户期望的另一个接口优点能提高类的透明性和复用现有的类复用但不需要改变目标类和适配器类解耦提高程序扩展性符合开闭原则缺点适配器编写过程需要全面考虑可能会增加系统的复杂性增加系统代码可读的难度适用场景已经存在的类它的方法和需求不匹配时方法结果相同或相似不是软件设计阶段考虑的设计模式是随着软件维护由于不同产品、不同厂家造成功能类似而接口不同情况下的解决方案装饰器模式定义在不改变原有对象的基础之上将功能附加到对象上提供了比继承更有弹性的替代方案优点继承的有力补充比继承灵活不改变原有对象的情况下给一个对象扩展功能通过使用不同装饰类以及这些装饰类的排列组合可以实现不同效果符合开闭原则缺点会出现更多的代码更多的类增加程序复杂性动态装饰时多层装饰时会更复杂适用场景扩展一个类的功能或者添加附加职责动态的给一个对象添加功能这些功能可以再动态的撤销代理模式定义为其他对象提供一种代理以控制对这个对象的访问优点代理模式能将代理对象与真实被调用的目标对象分离一定程度上降低了系统的耦合度扩展性好保护目标对象增强目标对象缺点代理模式会造成系统设计中类的数目增加在应用层和目标对象增加一个代理对象会造成请求处理速度变慢增加系统的复杂度适用场景保护目标对象增强目标对象外观模式定义提供了一个统一的接口用来访问子系统中的一群接口优点简化了调用过程无需深入了解子系统防止带来风险减少系统依赖松散耦合更好的划分访问层次符合迪米特法则即最少知道原则缺点增加子系统、扩展子系统行为容易引入风险适用场景子系统越来越复杂增加增加外观模式提供简单调用接口构建多层系统结构利用外观对象作为每层的入口简化层间的调用桥接模式定义将抽象部分与具体实现部分分离使他们可以独立变化通过组合的方式建立两个类之间联系而不是继承优点分离抽象部分和具体实现部分提高了系统的可扩展性符合开闭原则符合合成复用原则缺点增加了系统的理解与设计难度需要正确地识别出系统中两个独立变化的维度适用场景抽象和具体之间增加更多的灵活性一个类存在两个或多个独立变化的维度且这两个或多个维度都需要独立进行扩展不希望使用继承或者因为多层继承导致系统类的个数剧增组合模式定义将对象组合成树型结构以表示“部分-整体”的层次结构优点清除地定义分层次的复杂对象表示对象的全部或部分层次让应用层忽略了层次的差异方便对整个层次结构进行控制简化应用层代码符合开闭原则缺点限制类型时会比较复杂使设计变得更加抽象适用场景希望应用层可以忽略组合对象与单个对象的差异时处理一个树型结构时享元模式定义提供了减少对象数量从而改善应用所需的对象结构的方式优点减少对象的创建降低内存中对像的数量降低系统的内存提高效率减少内存之外的其他资源占用缺点关注内/外部状态、关注线程安全问题使系统、程序的逻辑复杂化适用场景常常应用于系统底层的开发以便解决系统的性能问题系统有大量相似对象、需要缓冲池的场景结构型策略模式定义定义了算法家族分别封装起来让它们之间可以相互替换此模式让算法的变化不会影响到使用算法的用户优点开闭原则避免使用多重条件转移语句提高算法的保密性和安全性缺点应用层必须知道所有的策略类并自行决定使用哪一个策略类产生很多策略类适用场景系统有很多类而他们的区别仅仅在于他们的行为不同一个系统需要动态的在几种算法中选择一种模板方法模式定义定义了一个算法的骨架并允许子类为一个或多个步骤提供实现优点提高复用性提高扩展性符合开闭原则缺点类数目增加增加了系统实现的复杂度继承关系自身缺点如果父类添加新的抽象方法所有子类都要改一遍适用场景一次性实现一个算法的不可变的部分并将可变的行为留给子类来实现各子类中公共的行为被提取出来并集中到一个公共父类中从而避免代码重复观察者模式定义定义了对象之间的一对多依赖让多个观察者对象同时监听某一个主题对象当主题对象发生变化时它的所有依赖者观察者都会收到通知并更新优点观察者和被观察者之间建立一个抽象的耦合观察者模式支持广播通信缺点观察者之间有过多的细节依赖、提高时间消耗及程序复杂度使用要得当要避免循环调用适用场景关联行为场景建立一套触发机制迭代器模式定义提供一种方法顺序访问一个集合对象中的各个元素而又不暴露改对象的内部表示优点分离了集合对象的遍历行为缺点类的个数成对增加适用场景访问一个集合对象的内容而无需暴露它的内部表示为遍历不同的集合结构提供一个统一的接口责任链模式定义为请求创建一个接收此次请求对象的链优点请求的发送者和接收者解耦责任链可以动态组合缺点责任链太长或者处理时间过长影响性能责任链有可能过多适用场景一个请求的处理需要多个对象当中的一个或几个协作处理命令模式定义将请求封装成对象以便使用不同的请求优点降低耦合容易扩展新命令或一组命令缺点命令的无限扩展会增加类的数量提高系统实现复杂度适用场景请求调用者和请求接受者需要解耦使调用者和接受者不直接交互需要抽象出等待执行的行为备忘录模式定义保存一个对象的某个状态以便在适当的时候恢复对象优点为用户提供一种可恢复机制存档信息的封装缺点资源占用适用场景保存及恢复数据相关业务场景后悔的时候即想恢复到之前的状态状态模式定义允许一个对象在其内部状态改变时改变它的行为优点将不同的状态隔离把各种状态的转换逻辑分布到State的子类中减少相互间依赖增加新的状态非常简单缺点状态多的业务场景导致类数目增加系统变复杂适用场景一个对象存在多个状态不同状态下行为不同且状态可相互转换访问者模式定义封装作用于某数据结构如List/Set/Map等中的各个元素的操作优点增加新的操作很容易即增加一个新的访问者缺点增加新的数据结构困难具体元素变更比较麻烦适用场景一个数据结构如List/Set/Map等包含很多类型对象数据结构与数据操作分离中介者模式定义定义一个封装一组对象如何交互的对象优点将一对多转化成了一对一降低程序复杂度类之间解耦缺点中介者过多导致系统复杂适用场景系统中对象之间存在复杂的引用关系产生的相互依赖关系结构混乱且难以理解交互的公共行为如果需要改变行为则可以增加新的中介者类解释器模式定义给定一个语言定义它的文法的一种表示并定义一个解释器这个解释器使用该表示来解释语言中的句子优点语法由很多类表示容易改变及扩展此“语言”缺点当语法规则数目太多时增加了系统复杂度适用场景某个特定类型问题发生频率足够高
