东莞做网站推广的公司WordPress的分類顯示插件

当前位置： 首页 > news >正文

东莞做网站推广的公司,WordPress的分類顯示插件,便民信息发布平台,江门建站网站模板OO原则是我们的目标#xff0c;而设计模式是我们的做法。 策略模式 (Strategy) 在软件开发上#xff0c;一直不变的真理是“change”。不管软件设计的多好#xff0c;一段时间之后#xff0c;总是要成长与改变#xff0c;否则软件就会“死亡”。 策略模式(Strategy)#… OO原则是我们的目标而设计模式是我们的做法。 策略模式 (Strategy) 在软件开发上一直不变的真理是“change”。不管软件设计的多好一段时间之后总是要成长与改变否则软件就会“死亡”。 策略模式(Strategy)定义算法族分别封装起来让它们之间可以互相替换此模式让算法的变化独立于使用算法的客户。代码关键点某个行为设计为接口行为的具体实现由具体类来完成。书中例子鸭子与鸭子的行为以组合的方式组织鸭子的行为以接口表示接口可能有多个具体的实现形式。具体的鸭子类可以动态的设置行为的具体方式。封装变化找出应用中可能需要变化之处把它们独立出来不要和那些不需要变化的代码混在一起。把会变化的部分取出并“封装”起来好让其他部分不会受到影响。针对“接口”编程而不是针对实现编程。多用组合少用继承。建立可维护的OO系统要诀就在于随时想到系统以后可能需要的变化以及应付变化的原则。良好的OO设计必须具备可复用、可扩充、可维护三个特性。大多数的模式和原则都着眼于软件变化的主题。大多数的模式都允许系统局部改变独立于其他部分。我们常把系统中会变化的部分抽出来封装。 观察者模式 (Observer) 设计原则为了交互对象之间的松耦合而努力 观察者模式定义了对象之间的一对多依赖这样一来当一个对象改变状态时它的所有依赖者都会收到通知并自动更新。被观察者是真正拥有数据观察者是其依赖者在数据变化时更新这样比起让许多对象控制同一份数据可以得到更干净的OO设计。代码关键点在被观察者类/数据类中加入了观察者类的注册list成员列表在列表中的成员为注册成员接收数据通知。“拉”数据的模式还要求观察者类中包含一个被观察者成员变量。推Push与拉Pull观察者获取数据的方式是通过notifyObserver(Object)进行传输或观察者调用被观察者的getData()获取数据。一般认为“推的方式更正确” [观点例如数据的变动很频繁让观察者拉数据不一定能够满足要求各个观察者所获取的数据也可能是不一致的]。消息传递链条(方法调用步骤) 数据源数据变化调用自身的setData(…);调用数据改变方法setChanged();//便于控制消息通知调用notifyObservers(Obj);//推与拉的关键仅仅在于Object是否传输for each O in Observers , .o.update()一对多松耦合若调用java.util.Observerable不要依赖于观察者被通知的次序。观察者和可观察者之间用松耦合方式结合可观察者不知道观察者的细节只知道观察者实现了观察者接口update()。有多个观察者时不可以依赖特定的通知次序。Java有多种观察者模式的实现包括了通用的java.util.Observerable.此模式被应用在许多地方例如许多的GUI框架/SwingJavaBeans、RMI。 //被观察者 public class WeatherData implements Subject {private List observers;//关键点1private Object data;private boolean changed;public WeatherData() {observers new ArrayList();}public void registerObserver(Observer o) {…}//注册public void removeObserver(Observer o) {…}//移除spublic void setData(Object data) {//更新数据this.data data;dataChanged();}public void dataChanged() {setChanged();if(是否达到推送更新数据条件) {notifyObservers();}}public void setChanged() {//数据已改变changed true;}/*** arg即为所要传送的数据如果为拉模式argnull, 数据在所传输的this被观察者对象中/public void notifyObservers(Object arg) {if(changed) {for(Observer observer : observers) {observer.update(this, arg);}changed false;}} }public class OneObserver implements Observer {private Subject weatherData;//关键点2private Object data;public OneObserver(Subject s) {//构造器注册this.weatherData s;weatherData.registerObserver(this);}public void update(Object observerable, Object arg) {//更新数据接口this.data arg;} } 装饰者模式 (Decorator) 给爱用继承的人一个全新的设计眼界 开放-关闭原则类应该对扩展开放对修改关闭。装饰者模式动态地将责任附加到对象上。若要扩展功能装饰者提供了比继承更有弹性的替代方案。 装饰者和被装饰对象有相同的超类型。在任何需要原始对象的场合可以用装饰过的对象替代它。可以用一个或多个装饰者包装一个对象。用装饰来包裹一个对象动态的扩展功能装饰者可以在被委托装饰者的行为之前与/或之后加上自己的行为已达到特定的目的。对象可以在任何时候被装饰所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。Java库中的装饰者模式 Java I/OReader/Writer装饰者模式缺点常常造成设计中有大量的小类数量实在太多可能造成使用此API程序员的困扰。要点 继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式。在我们的设计中 /** 被装饰者基类/ public abstract class BaseBeverage {String description Unknown Beverage;public String getDescription() {return description;}public abstract double cost(); }/** 装饰者基类/ public abstract class BaseCondimentDecorator extends BaseBeverage {public abstract String getDescription(); }/** 被装饰者实体类/ public class Espresso extends BaseBeverage {public Espresso() {description Espresso;}Overridepublic double cost() {return 1.99;} }/** 装饰者实体类*/ public class Mocha extends BaseCondimentDecorator {BaseBeverage beverage;public Mocha(BaseBeverage beverage) {this.beverage beverage;}Overridepublic String getDescription() {return beverage.getDescription() , Mocha;}Overridepublic double cost() {return 0.2 beverage.cost();} }/**

• 装饰者使用方法 */ public class StarBuzzCoffee {public static void main(String[] args) {BaseBeverage beverage new Espresso();System.out.println(beverage.getDescription() beverage.cost());BaseBeverage beverage2 new Espresso();beverage2 new Mocha(beverage2);beverage2 new Mocha(beverage2);System.out.println(beverage2.getDescription() beverage2.cost());} } 工厂模式 (Factory) 除了new操作符之外还有更多制造对象的方法。实例化这个活动不应该总是公开地进行也会认识到初始化经常造成“耦合”问题。 理解关键点工厂方法是将对象实例化延迟在具体子类中实现返回不同的产品抽象工厂模式公共接口会抽象类是为了创建产品家族实现不同的工厂制造出不同的产品、不同的区域、不同的操作系统、不同的外观及操作。 工厂方法模式定义了一个创建对象的接口但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。依赖倒置原则要依赖抽象不要依赖具体类。几个避免你违反 依赖倒置 的指导方针 - 变量不可以持有具体类的引用。如果使用new就会持有具体类的引用。你可以改用工厂来避开这样的做法。 - 不要让类派生自具体类。如果派生自具体类你就会依赖具体类。请派生自一个抽象——接口或抽象类 - 不要覆盖基类中已实现的方法。如果覆盖基类已实现的方法那么你的基类就不是一个真正适合被继承的抽象。基类中已实现的方法应该由所有的子类共享不能让高层组件依赖低层组件而且不管高层或低层组件“两者”都应该依赖于抽象。工厂方法用来处理对象的创建并将这样的行为封装在子类中。这样客户程序中关于超类超类的代码就和子类对象创建代码解耦了。工厂方法模式通过让子类决定该创建的对象是什么来达到将对象创建的过程封装的目的。 /**
• 工厂方法模式 */ public abstract class ProductFactory {//获取对象public Product getProduct(String type) {Product product;product createProduct(type);//call product same methodproduct.prepare();product.bake();product.cut();product.box();return product;}//工厂方法public abstract Product createProduct(String type); }public abstract class Product {String name;void prepare() { }void bake() { }void cut() { }void box() { } }abstract Product factoryMethod(String); /**
• 1. 工厂方法是抽象的所以依赖子类来处理对象的创建
• 2. 工厂方法必须返回一个产品。超类中定义的方法通常使用到工厂方法的返回值。
• 3. 工厂方法将客户和实际创建具体产品的代码分隔开来。
• 4. 工厂方法可能需要参数来指定所要的产品。 */抽象工厂模式提供一个接口用于创建相关或依赖对象的家族而不需要明确指定具体类。抽象工厂使用对象组合对象的创建被实现在工厂接口所暴露出来的方法中。 /**
• 抽象产品类 */ public abstract class Product {String name;String source;abstract void prepare(); }/**
• 抽象原料工厂 */ public abstract class ProductIngredientFactory {void createSource() { } }/**
• 具体产品类 */ public class RealProduct extends Product {//生产产品所需的某种原料的工厂ProductIngredientFactory ingredientFactory;public RealProduct(ProductIngredientFactory ingredientFactory) {this.ingredientFactory ingredientFactory;}Overridevoid prepare() {source ingredientFactory.createSource();} } 单件模式 (Singleton) 用来创建独立无二的只能有一个实例的对象的入场券 全局变量的缺点必须在程序一开始就创建好对象万一这个对象非常耗费资源而程序在这次的执行过程中又一直没用到它不就形成浪费了吗.(某些JVM在用到的时候才创建对象).例如线程池、缓存、对话框、处理偏好设置和注册表的对象、日志对象充当打印机、显卡等设备的驱动程序的对象这些对象只能有一个。单件模式常被用来管理共享资源例如数据库连接或线程池。单件模式 确保一个类只有一个实例并提供一个全局访问点。在java中实现单件模式需要私有构造器、一个静态方法和一个静态变量。确定在性能和资源上的限制然后小心地选择适当的方案来实现单件以解决多线程问题。如果你使用多个 类加载器 可能导致单件失效而产生多个实例。 /**
• 未考虑并发的单件模式 */ public class Singleton {private static Singleton uniqueInstance;private Singleton() {}public static Singleton getInstance() {if (uniqueInstance null) {uniqueInstance new Singleton();}return uniqueInstance;} } /**
• 考虑并发的单件模式
• 较好方式双重检查加锁
• 注意要使用volatile-synchronized(不适用于java1.4或更早之前的版本) *
• 1. 采用“急切”创建实例即在声明处就创建对象。如果对象在创建和运行时很繁重不推荐此种方法。
• 2. 单纯使用synchronized设置整个方法为同步方法。性能较差 */ public class SupportParrallSingleton {private volatile static SupportParrallSingleton uniqueInstance;public static SupportParrallSingleton getInstance(){if (uniqueInstance null) {synchronized (SupportParrallSingleton.class) {if (uniqueInstance null) {uniqueInstance new SupportParrallSingleton();}}}return uniqueInstance;} } 命令模式 (Command) 把方法调用封装起来 命令模式 将“请求”封装成对象以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。命令模式将发出请求的对象和执行请求的对象解耦。在被解耦的两者之间是通过命令对象进行沟通的。命令对象封装了接受者和一个或一组动作。调用者通过调用命令对象的execute()发出请求这会使得接受者的动作被调用。调用者可以接受命令当做参数甚至在运行时动态地进行。命令可以支持撤销做法是实现一个undo()方法来回到execute()被执行前的状态。宏命令是命令的一个简单延伸允许调用多个命令。宏方法可以支持撤销。实际操作中很常见使用“聪明”命令对象也就是直接实现了请求而不是将工作委托给接收者。命令也可以用来实现日志和事务系统。命令模式的更多用途 队列请求 例如日程安排、线程池、工作队列等。想象有一个工作队列你在一端添加命令然后另一端则是线程。线程进行下面的动作从队列中取出一个命令然后调用它的execute()方法等待这个调用完成然后将此命令对象丢弃再取出下一个命令……日志请求 例如系统检查点后的一系列操作事务处理Transaction /**
• 思考餐厅的下单过程 */ /**
• 接口命令对象
• 例如顾客交给服务员的订单遥控器按钮所传输的对象
• 注意命令对象是个接口将请求的对象和执行请求的对象进行沟通关联在实现中 */ public interface Command {public void execute(); }/**
• 注意将请求的对象和执行请求的对象进行沟通关联在实现中 / public class LightOnCommand implements Command {Light light;//执行请求的对象public LightOnCommand(Light light) {this.light light;}Overridepublic void execute() {//执行请求的对象调用的方法light.on();} }/** 执行请求的对象类似餐厅厨师/ public class Light {public void on() {System.out.println(light on);} }/** 动作发起者类似餐厅顾客*/ public class SimpleRemoteControl {Command slot;public void setCommand(Command command) {//顾客下单this.slot command;}public void buttonWasPressed() {//提交订单slot.execute();} }/**
• 执行流程 */ public class CommandPatternTest {public static void main(String[] args) {SimpleRemoteControl remote new SimpleRemoteControl();Light light new Light();LightOnCommand lightOnCommand new LightOnCommand(light);remote.setCommand(lightOnCommand);remote.buttonWasPressed();} } //TODO MORE 总结 封装变化多用组合少用继承针对接口编程不针对实现编程为交互对象之间的松耦合而努力类应该对扩展开放对修改关闭依赖抽象不要依赖具体类 转载于:https://www.cnblogs.com/AbelZone/p/10049974.html