怎么用vs做网站开发,wordpress模板使用,app制作开发公司前十名,网站建设ppt演示文稿设计原则 一、多用组合#xff0c;少用继承
eg.基类鸭子#xff0c;子类有多种鸭子#xff0c;不同鸭子的行为可能不同也有可能相同
将这种可能出现不同的行为#xff0c;抽成接口#xff0c;而不是放到直接基类里#xff0c;让每个子类实现
上述就是简单的策略模式 二…设计原则 一、多用组合少用继承
eg.基类鸭子子类有多种鸭子不同鸭子的行为可能不同也有可能相同
将这种可能出现不同的行为抽成接口而不是放到直接基类里让每个子类实现
上述就是简单的策略模式 二、开放-关闭原则
拓展功能ok少修改老的功能影响原来的使用上游
例子见装饰者模式 三、依赖倒置原则
依赖抽象不依赖具体类将具体类、功能抽象到高层
工厂模式的例子 四、最少知识原则
减少对象之间的交互只留最重要的几个 。
这个原则希望我们在设计中不要让太多的类耦合在一起免得修改系统中一部分会影响到其他部分。如果许多类之间相互依赖那么这个系统就会变成一个易碎的系统它需要花许多成本维护也会因为太复杂而不容易被其他人了解。 尽量不调用对象的子对象的方法减少耦合和间接依赖的类认知
比如错误的实践
public void fun(){return A.fun2().fun3();
}应该改成,在A里去包掉 fun2() 和 fun3()的逻辑
public void fun(){return A.fun4();
} 设计模式 策略模式 观察者模式 主题对象更新时通知观察者对象。
通知方实现接口三个方法注册观察者、删除观察者、通知观察者
观察者实现接口一个方法update() Java内置的观察者策略 通知方的类需要继承Observable因为setChanged是protect权限 然后每次notify前使用setChanged方法因为通知前会看 changed标 观察者实现update接口
推拉结合获取通知方的信息推用的多 内置的缺陷
1Observable是一个类而不是一个接口导致想实现Observable类里方法无法使用其他类方法时因为没法多继承
2setChanged()方法权限是protected通知方必须继承Observable 装饰者模式
模式说明装饰者模式动态地将责任附加到对象上。若要扩展功能装饰者提供了比继承更有弹性的替代方案。 场景示例要造一杯咖啡加牛奶、加糖等等需要计算最后价格。现在有咖啡类、牛奶类、糖类 场景2自己写个输入流装饰器将大写字母转成小写 两个装饰器叠加 思考
为什么装饰者和被装饰者需要基类相同
因为装饰者可以叠加可以互相装饰且装饰者可以替代被装饰者如上图中的ConcreteDecoratorA和ConcreteDecoratorB
构造设计模式关键点
基类相同 工厂模式
关键创建对象可能有些前置动作初始化某些字段等把这些实例化的细节放到【工厂对象】里去做 简单工厂
负责对象的实例化细节处理朴实无华
这样每次需要新对象时就在工厂对象里调用创建方法而不用关心创建的细节了. 抽象工厂模式
和工厂模式是两种模式
右边有很多产品族每种产品族实现自己的接口然后工厂里加上创建每种产品族实例的方法 单件模式
核心思想构造器私有 第一个关键解决【正确判断单例是否被创建不为null】的问题
public class Singleton{private volatile static Singleton uniqueInstance;private Singleton(){}public getInstance(){if(uniqueInstance null){synchronized(Singleton.class){if(uniqueInstance null){uniqueInstance new Singleton();}}}return uniqueInstance;}
} 命令模式
核心解耦动作请求者 和 动作执行者
我发现我已经用过了launchCheckHandler就是用的这个设计模式。上线检查时每个检查点的handler都要实现检查方法。
这里就简单跳过了 适配器模式
将一个类的接口转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。 public class 适配器 {private 被适配者;// 实现被适配者的方法void fun(){}...
} 外观模式
简化提供的接口
比如原来做一件事要提供很多接口外观模式 就是简化提供的接口将复杂的功能自己封装了下 模板方法模式
模板方法定义了一个算法的步骤并允许子类为一个或多个步骤提供实现。
模板方法模式在一个方法中定义一个算法的骨架而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下重新定义算法中的某些步骤。 定义的模板类基类 加钩子方法
