网站建设费用应该开专票还是普票,网站建设的运用场景,建设执业资格注册中心官方网站,客户开发软件工具1.1 吃羊肉串#xff01; 烧烤摊旁边等着拿肉串的人七嘴八舌地叫开了。场面有些混乱#xff0c;由于人实在太多#xff0c;烤羊肉串的老板已经分不清谁是谁#xff0c;造成分发错误#xff0c;收钱错误#xff0c;烤肉质量不过关等。 外面打游击烤羊肉串和这种开门店做烤…1.1 吃羊肉串 烧烤摊旁边等着拿肉串的人七嘴八舌地叫开了。场面有些混乱由于人实在太多烤羊肉串的老板已经分不清谁是谁造成分发错误收钱错误烤肉质量不过关等。 外面打游击烤羊肉串和这种开门店做烤肉哪个更赚钱 这很难讲毕竟各有各的好在外面打游击好处是不用租房不用上税最多就是交点保护费但下雨天不行、大白天不行、太晚也不行一般都是傍晚做几个钟头顾客也不固定像刚才那个由于人多造成混乱于是就放跑了我们这两条大鱼其实他的生意是不稳定的。大白天城管没下班呢怎能容忍他如此安逸。超过晚上11点夜深人静谁还愿意站在路边吃烤肉。但开门店就不一样了不管什么时间都可以做生意由于环境相对好所以固定客户就多看似好像房租交出去了但其实由于顾客多而且是正经做生意所以最终可以赚到大钱。
1.2 烧烤摊vs.烧烤店 因为要吃烤肉的人太多都希望能最快吃到肉串烤肉老板一个人所以有些混乱。 还不止这些老板一个人来的人一多他就未必记得住谁交没交过钱要几串需不需要放辣等。 是呀大家都站在那里没什么事于是都盯着烤肉去了哪一串多、哪一串少、哪一串烤得好、哪一串烤得焦看得清清楚楚于是挑剔也就接踵而至。 这其实就是我们在编程中常说的什么 我想想你是想说紧耦合 哈不错不枉我的精心栽培。 由于客户和烤羊肉串老板的紧耦合所以容易出错也容易产生挑剔。 说得对这其实就是行为请求者与行为实现者的紧耦合。我们需要记录哪个人要几串羊肉串有没有特殊要求放辣不放辣付没付过钱谁先谁后这其实都相当于对请求做什么 对请求做记录啊应该是做日志。 很好那么如果有人需要退回请求或者要求烤肉重烤这其实就是 就相当于撤销和重做吧。 OK所以对请求排队或记录请求日志以及支持可撤销的操作等行为时行为请求者与行为实现者的紧耦合是不太适合的。你说怎么办 哈这是最终结果不是这个意思我们是烤肉请求者烤肉的师傅是烤肉的实现者对于开门店来说我们用得着去看着烤肉的实现过程吗现实是怎么做的呢 哦我明白你的意思了我们不用去认识烤肉者是谁连他的面都不用见到我们只需要给接待我们的服务员说我们要什么就可以了。他可以记录我们的请求然后再由他去通知烤肉师傅做。 而且由于我们所做的请求其实也就是我们点肉的订单上面有很详细的我们的要求所有的客户都有这一份订单烤肉师傅可以按先后顺序操作不会混乱也不会遗忘了。 收钱的时候也不会多收或少收。 优点还不止这里比如说服务员我们那十串羊肉串太多了改成六串就可以了。 好的服务员答道。 你注意看他接着做了什么 他好像在一个小本子上划了一下然后去通知烤肉师傅了。 这其实是在做撤销行为的操作。由于有了记录所以最终算账是不会错的。 对对对这种利用一个服务员来解耦客户和烤肉师傅的处理好处真的很多。
1.3 紧耦合设计
代码结构图 package code.chapter23.command1;public class Test {public static void main(String[] args) {System.out.println(**********************************************); System.out.println(《大话设计模式》代码样例);System.out.println(); Barbecuer boy new Barbecuer();boy.bakeMutton();boy.bakeMutton();boy.bakeMutton();boy.bakeChickenWing();boy.bakeMutton();boy.bakeMutton();boy.bakeChickenWing();System.out.println();System.out.println(**********************************************);}
}//烤肉串者
class Barbecuer{//烤羊肉public void bakeMutton(){System.out.println(烤羊肉串);}//烤鸡翅public void bakeChickenWing(){System.out.println(烤鸡翅);}
} 很好这就是路边烤肉的对应如果用户多了请求多了就容易乱了。那你再尝试用门店的方式来实现它。 我知道一定需要增加服务员类但怎么做有些不明白。 嗯这里的确是难点要知道不管是烤羊肉串还是烤鸡翅还是其他烧烤这些都是烤肉串者类的行为也就是他的方法具体怎么做都是由方法内部来实现我们不用去管它。但是对于服务员类来说他其实就是根据用户的需要发个命令说有人要十个羊肉串有人要两个鸡翅这些都是命令…… 我明白了你的意思是把烤肉串者类当中的方法分别写成多个命令类那么它们就可以被服务员来请求了 是的说得没错这些命令其实差不多都是同一个样式于是你就可以泛化出一个抽象类让服务员只管对抽象的命令发号施令就可以了。具体是什么命令即烤什么由客户来决定吧。
1.4 命令模式 命令模式Command将一个请求封装为一个对象从而使你可用不同的请求对客户进行参数化对请求排队或记录请求日志以及支持可撤销的操作。DP 命令模式Command结构图 package code.chapter23.command0;import java.util.ArrayList;
import java.util.Date;
import java.text.SimpleDateFormat;public class Test {public static void main(String[] args) {System.out.println(**********************************************); System.out.println(《大话设计模式》代码样例);System.out.println(); Receiver receiver new Receiver();Command command new ConcreteCommand(receiver);Invoker invoker new Invoker();invoker.setCommand(command);invoker.executeCommand();System.out.println();System.out.println(**********************************************);}
}//抽象命令类
abstract class Command {protected Receiver receiver;public Command(Receiver receiver){this.receiver receiver;}//执行命令public abstract void excuteCommand();
}//具体命令类
class ConcreteCommand extends Command{public ConcreteCommand(Receiver receiver){super(receiver);}public void excuteCommand(){receiver.action();}
}class Invoker{private Command command;public void setCommand(Command command){this.command command;}public void executeCommand(){command.excuteCommand();}}class Receiver{public void action(){System.out.println(执行请求);}
} Command类用来声明执行操作的接口。 ConcreteCommand类将一个接收者对象绑定于一个动作调用接收者相应的操作以实现executeCommand。 Invoker类要求该命令执行这个请求。 Receiver类知道如何实施与执行一个与请求相关的操作任何类都可能作为一个接收者。 客户端代码创建一个具体命令对象并设定它的接收者。
1.5 松耦合设计
代码结构图 package code.chapter23.command2;public class Test {public static void main(String[] args) {System.out.println(**********************************************); System.out.println(《大话设计模式》代码样例);System.out.println(); //开店前的准备Barbecuer boy new Barbecuer();//烤肉厨师Command bakeMuttonCommand1 new BakeMuttonCommand(boy); //烤羊肉串Command bakeChickenWingCommand1 new BakeChickenWingCommand(boy); //烤鸡翅Waiter girl new Waiter(); //服务员//开门营业girl.setOrder(bakeMuttonCommand1); //下单烤羊肉串girl.notifyCommand(); //通知厨师烤肉girl.setOrder(bakeMuttonCommand1); //下单烤羊肉串girl.notifyCommand(); //通知厨师烤肉girl.setOrder(bakeChickenWingCommand1); //下单烤鸡翅girl.notifyCommand(); //通知厨师烤肉System.out.println();System.out.println(**********************************************);}
}//抽象命令类
abstract class Command {protected Barbecuer receiver;public Command(Barbecuer receiver){this.receiver receiver;}//执行命令public abstract void excuteCommand();
}//烤羊肉命令类
class BakeMuttonCommand extends Command{public BakeMuttonCommand(Barbecuer receiver){super(receiver);}public void excuteCommand(){receiver.bakeMutton();}
}//烤鸡翅命令类
class BakeChickenWingCommand extends Command{public BakeChickenWingCommand(Barbecuer receiver){super(receiver);}public void excuteCommand(){receiver.bakeChickenWing();}
}//服务员类
class Waiter{private Command command;//设置订单public void setOrder(Command command){this.command command;}//通知执行public void notifyCommand(){command.excuteCommand();}
}//烤肉串者
class Barbecuer{//烤羊肉public void bakeMutton(){System.out.println(烤羊肉串);}//烤鸡翅public void bakeChickenWing(){System.out.println(烤鸡翅);}
}很好很好基本都把代码实现了。但没有体现出命令模式的作用。比如下面几个问题第一真实的情况其实并不是用户点一个菜服务员就通知厨房去做一个那样不科学应该是点完烧烤后服务员一次通知制作第二如果此时鸡翅没了不应该是客户来判断是否还有客户哪知道有没有呀应该是服务员或烤肉串者来否决这个请求第三客户到底点了哪些烧烤或饮料这是需要记录日志的以备收费也包括后期的统计第四客户完全有可能因为点的肉串太多而考虑取消一些还没有制作的肉串。这些问题都需要得到解决。 这这怎么办到呀 重构一下服务员Waiter类尝试改一下。将private Command command改成一个ArrayList就能解决了。
1.6 进一步改进命令模式
package code.chapter23.command3;import java.util.ArrayList;
import java.util.Date;
import java.text.SimpleDateFormat;public class Test {public static void main(String[] args) {System.out.println(**********************************************); System.out.println(《大话设计模式》代码样例);System.out.println(); //开店前的准备Barbecuer boy new Barbecuer();//烤肉厨师Command bakeMuttonCommand1 new BakeMuttonCommand(boy); //烤羊肉串Command bakeChickenWingCommand1 new BakeChickenWingCommand(boy); //烤鸡翅Waiter girl new Waiter(); //服务员System.out.println(开门营业顾客点菜);girl.setOrder(bakeMuttonCommand1); //下单烤羊肉串girl.setOrder(bakeMuttonCommand1); //下单烤羊肉串girl.setOrder(bakeMuttonCommand1); //下单烤羊肉串girl.setOrder(bakeMuttonCommand1); //下单烤羊肉串girl.setOrder(bakeMuttonCommand1); //下单烤羊肉串girl.cancelOrder(bakeMuttonCommand1); //取消一串羊肉串订单girl.setOrder(bakeChickenWingCommand1); //下单烤鸡翅System.out.println(点菜完毕通知厨房烧菜);girl.notifyCommand(); //通知厨师System.out.println();System.out.println(**********************************************);}
}//抽象命令类
abstract class Command {protected Barbecuer receiver;public Command(Barbecuer receiver){this.receiver receiver;}//执行命令public abstract void excuteCommand();
}//烤羊肉命令类
class BakeMuttonCommand extends Command{public BakeMuttonCommand(Barbecuer receiver){super(receiver);}public void excuteCommand(){receiver.bakeMutton();}
}//烤鸡翅命令类
class BakeChickenWingCommand extends Command{public BakeChickenWingCommand(Barbecuer receiver){super(receiver);}public void excuteCommand(){receiver.bakeChickenWing();}
}//服务员类
class Waiter{private ArrayListCommand orders new ArrayListCommand();//设置订单public void setOrder(Command command){String classNamecommand.getClass().getSimpleName();if (className.equals(BakeChickenWingCommand)){System.out.println(服务员鸡翅没有了请点别的烧烤。);}else{this.orders.add(command);System.out.println(增加订单className 时间getNowTime());}}//取消订单public void cancelOrder(Command command){String classNamecommand.getClass().getSimpleName();orders.remove(command);System.out.println(取消订单className 时间getNowTime());}//通知执行public void notifyCommand(){for(Command command : orders)command.excuteCommand();}private String getNowTime(){SimpleDateFormat formatter new SimpleDateFormat(HH:mm:ss);return formatter.format(new Date()).toString();}
}//烤肉串者
class Barbecuer{//烤羊肉public void bakeMutton(){System.out.println(烤羊肉串);}//烤鸡翅public void bakeChickenWing(){System.out.println(烤鸡翅);}
}
1.7 命令模式的作用 我觉得第一它能较容易地设计一个命令队列第二在需要的情况下可以较容易地将命令记入日志第三允许接收请求的一方决定是否要否决请求。 还有就是第四可以容易地实现对请求的撤销和重做第五由于加进新的具体命令类不影响其他的类因此增加新的具体命令类很容易。其实还有最关键的优点就是命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。DP 但是否是碰到类似情况就一定要实现命令模式呢 这就不一定了比如命令模式支持撤销恢复操作功能但你还不清楚是否需要这个功能时你要不要实现命令模式 要万一以后需要就不好办了。 其实应该是不要实现。敏捷开发原则告诉我们不要为代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式一般就不要着急去实现它事实上在需要的时候通过重构实现这个模式并不困难只有在真正需要如撤销恢复操作等功能时把原来的代码重构为命令模式才有意义。R2P
