做一个商场收银软件，营业员根据客户所购买商品的单价和数量向客户收费。即简单的收银软件。
利用Java的GUI编程，作出一个可视化界面如下。这里利用了IntelliJ IDEA的GUI Designer来进行界面功能编写，会用的话还是挺方便的。
业务逻辑还是比较简单的，主要就是确定按钮和重置按钮的监听事件。源码配合注释如下:
import javax.swing.*; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; /** * Created by Mr.sorrow on 2017/6/30. */ public class Market { private JButton confirm; //确定按钮 private JButton reset; //重置按钮 private JTextField price; //单价文本框 private JTextField num; //数量文本框 private JLabel sumLable; //总计 private JPanel mainPanel; private JTextArea item; //商品条目 private JScrollPane itemScoller; private double totalPrice = 0.0; public Market() { confirm.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { double itemPrice = Double.valueOf(price.getText()); int itemNum = Integer.valueOf(num.getText()); totalPrice += itemPrice * itemNum; item.setText(item.getText() + "单价：" + price.getText() + "，数量：" + num.getText() + "，合计：" + itemPrice * itemNum + "\n"); sumLable.setText(totalPrice + ""); } }); reset.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { price.setText("0.00"); num.setText("0"); item.setText(""); sumLable.setText("0.00"); totalPrice = 0.0; } }); } public static void main(String[] args) { JFrame frame = new JFrame("Market"); frame.setContentPane(new Market().mainPanel); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.pack(); frame.setVisible(true); } }这样一个简单的收银软件，当某一天商品价格计算方式变了，比如打折、优惠券等等，我们必须手动更改代码才能够继续正确的计算。当不同的节日可能需要不同的折扣，优惠券的大小也每个人不尽相同。参照第一讲的简单工厂模式，我们可以写出各种不同的收费子类，比如打八折、满1000减300、满2件免单便宜的一件等等。 仔细想想，这样优化的缺点还存在一个小问题，每一种优惠方式都写一个收费子类，那么子类会越来越多，因为促销方式也会各种各样。所以，我们需要针对各种促销方式进行分类，同一类的只写一个子类。比如打五折和打八折是一类，只不过折数不同，需要我们在类的设计时将折扣数传进去，显然类的构造函数中添加参数即可轻而易举实现。
面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
收费基类Charge；
//收费抽象父类 public abstract class Charge { public abstract double acceptMoney(double productMoney); }正常收费子类ChargeNormal；
//正常收费直接返回商品价格 public class ChargeNormal extends Charge{ @Override public double acceptMoney(double productMoney) { return productMoney; } }折扣收费子类ChargeRebate；
//打折返回折扣价 public class ChargeRebate extends Charge { private double discount; public ChargeRebate(double discount) { this.discount = discount; } @Override public double acceptMoney(double productMoney) { return productMoney * discount; } }满减收费子类ChargeReturn；
//满xxx减xxx（并非每满xxx减xxx） public class ChargeReturn extends Charge{ private double moneyOver; private double moneyReturn; public ChargeReturn(double moneyOver, double moneyReturn) { this.moneyOver = moneyOver; this.moneyReturn = moneyReturn; } @Override public double acceptMoney(double productMoney) { if(productMoney >= moneyOver) return productMoney - moneyReturn; else return productMoney; } }收费工厂类。
//简单工厂 public class ChargeFactory { public static Charge createCharge(String chargeType){ Charge chargeInstance = null; switch (chargeType) { case "正常收费": chargeInstance = new ChargeNormal(); break; case "打8折": chargeInstance = new ChargeRebate(0.8); break; case "满100减20": chargeInstance = new ChargeReturn(100, 20); break; } return chargeInstance; } }简单工厂这种方法实现的UML图如下，可以看到工厂类和其他收费方式类是依赖关系，依赖关系一般不是成员变量，这一点在第二讲有详细提及。
可以看到这里利用简单工厂模式已经进行了一些优化，当商场推出新的促销政策，我们需要编写一个ChargeXxx收费子类继承自Charge，同时也需要在工厂类中添加一个switch分支用来生成实例对象。商场的频繁更换促销政策，我们需要不停的改动工厂类并且编译部署，这一点其实并不是很好。这么一想，第一讲的计算器程序是不是也存在这个问题？我猜大概是因为计算器运算符一共也就那么多，并不是随便自定义的，所以简单工厂模式问题不大。
面对算法的时常变动，应该有更好的办法(其他的设计模式)。
策略模式(Strategy):它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式的算法变化，不会影响到算法使用的客户。 商场收银时如何促销，用打折还是返利，其实都是一些算法，用工厂来生成算法对象，这并没有错，但算法本身只是一种策略，最重要的是这些算法是随时可能互相替换的。这些就是变化点，而封装变化点是面向对象的一种重要的思维方式。 策略模式的UML图如下:
Strategy:所有策略的基类StrategyA、StrategyB、StrategyC:三个策略子类Context:上下文，包含一个父类Strategy引用，指向具体的子类策略对象(聚合关系)策略模式的代码实现:
抽象算法基类(网上也有是用接口)
public abstract class Strategy{ public abstract void function(); }具体算法子类(B、C类似)
public class StrategyA extends Strategy{ public void function(){ ... } }Context类
public class Context{ private Strategy strategy; public Context(Strategy strategy){ this.strategy = strategy; } public void contextInterface(){ strategy.function(); } }客户端代码(GUI代码)
public static void main(String[] args){ Context context; context = new Context(new StrategyA()); context.contextInterface(); context = new Context(new StrategyB()); context.contextInterface(); }通过策略模式，客户端代码仅仅需要Context类的实例对象，而不需要去了解任意一种策略是如何实现的。当策略的改变，客户端也不用去理会，而是Context去解决。
原来写的Charge相当于抽象策略，而ChargeNormal、ChargeRebate和ChargeReturn则相当于具体的策略A、B、C，这些都可以原封不动的照搬过来。
需要重新实现的是Context类，代码如下:
public class ChargeContext{ private Charge charge; public ChargeContext(Charge charge){ this.charge = charge; } public double getResult(double productMoney){ return charge.acceptMoney(productMoney); } }客户端代码需要写switch语句来根据不同的折扣方式产生不同的折扣策略对象进而产生不同的ChargeContext对象，再通过调用getResult()方法来获得实际收银金额。
... ChargeContext cc; switch(String type){ case "正常收费": cc = new ChargeContext(new ChargeNormal()); break; case "打8折": cc = new ChargeContext(new ChargeRebate(0.8)); break; case "满100减20": cc = new ChargeContext(new ChargeReturn(100, 20)); break; } ... cc.getResult();现在，如果再增加一种折扣措施，客户端代码必然要进行更改——添加一个Switch分支，这好像又回到了第一讲出现的问题，这种问题最后是用简单工厂模式去解决的。所以，这里再巧妙的引入简单工厂模式与策略模式相结合，一定能解决这一问题。
引入简单工厂模式一定在是在Context类中实现，观察现有的代码，能动手术的地方应该就是构造函数这一块；
更改后的代码如下:
public class ChargeContext{ private Charge charge; public ChargeContext(String type){ switch(type){ case "正常收费": charge = new ChargeNormal(); break; case "打8折": charge = new ChargeRebate(0.8); break; case "满100减20": charge = new ChargeReturn(100, 20); break; } } public double getResult(double productMoney){ return charge.acceptMoney(productMoney); } }客户端代码现在则相对来说明显简单的多,从头至尾仅仅需要和ChargeContext有关，而任何策略类统统不用去管。
ChargeContext cc = new ChargeContext("打8折"); cc.getResult();