这是小学生才能写的。。我们不能这样
为什么不直接把加减乘除写到main里面？
不符合面向对面的设计思想:
复用性差：比如其他地方要用到这些方法，只能把代码拷贝过去，如果我封装好了，直接把类拷过去，根本看都不用看类里面写的是什么；
可拓展差、灵活性差：比如我要新增一个开根号方法，只能在这里面改动，如果打错了一个什么东西，原来的加减乘除都不能用了
还有一堆堆的，反正这种为了实现而实现的代码就是一堆烂代码。。
不是说这些代码有错，而是在以后开发项目中，很少也有单一的独立于项目的功能。。就算有，也最好符合面向对象设计思想去做，虽然做的时候比较慢，但是会慢慢形成一个习惯，人不可能一辈子去敲这些实现类的代码，为什么有的人代码量积累到一定程度，接手新项目能自己搭框架，快速开发，思路非常清晰，然后写实现无非是理清楚业务逻辑，然后复用以前的代码。 像github上的那些快速开发框架，我不相信他们能一次性写出一个完美的框架，我觉得都是在开始设计的时候，严格遵守设计思想，结合以往的经验，搭成一个架子，然后慢慢的实现，形成一个框架。。唠叨一下个人感悟。。
合理的设计方案
为什么要写一个运算类接口？
比如现在新增一个开根号方法，我只需要看下接口，按照接口的设计规范写实现就好了，完全不影响加减乘除，也不管有没有加减乘除这些方法，也不管上层模块（就是比如main方法里面调用）怎么去调用这些方法。
这应该就是面向对象（封装、继承、多态）、面向接口编程的好处吧，反正实际应用多了才会真的理解这些东西吧。。
这里的话，应该就是书里常说的依赖倒转原则：
（这个是书里的40页，PDF的话是58页的地方讲到，比较乱的话可以先忽略下面，以后再回来看）
倒转我也不理解为什么叫倒转
这里的高层模块就相当于main方法，底层模块就是加减乘除，高层模块调用底层模块，就是main里面调用加减乘除，
然后他们都应该依赖抽象的意思是说，他们都依赖于上图那个运算类的接口。
他们怎么实现这句话呢，都依赖抽象。。
（开启话唠模式）这里得先了解面向对象的转型：向上转型和向下转型：
Operation ：上图那个运算类接口
OperationAdd ：继承Operation 的加法
OperationSub ：继承Operation 的减法
向上转型：Operation mOperation = new OperationAdd();
就是父类的引用mOperation 指向子类对象new OperationAdd()
向下转型：OperationAdd mOperationAdd = （OperationAdd）mOperation ;
PS:引用、对象什么的可以去看看堆栈那些，基础的就行了，其实反正没啥用，理解一下就好了，在写代码的时候感觉比较透彻应该，不知道怎么形容，现在都太高级，各种封装，根本不必理解底层，想想，软件开发人员和程序员还是有很大区别的。
为什么要向上转型
就是为了实现上面说的依赖抽象，你看接下来只要调用mOperation.GetResult()，就能得出加法结果
如果我mOperation 指向的是new OperationSub()，那么mOperation.GetResult()的结果就是减法结果。
这种用父类引用指向子类对象有很多好处，这应该就是多态吧。
高层和底层都依赖抽象，就是他们都依靠一个准则来编程，不管你高层和底层怎么变，都不互相影响，这就是解耦了
还有就是面向接口的编程，先不去管实现，反正先调用，架子出来之后再去写具体实现，这样思路比较清晰，
PS:向下转型就是我传给你mOperation （父类的引用），实际我指向的是OperationAdd的对象，如果子类里面多了一个方法GetResultForAdd（），那么我用mOperation是访问不到这个方法，如果想要调用子类OperationAdd里面的方法（父类没有的方法），那么我必须先将他强制转换，才能调用子类的方法。
然后还有一个问题，就是我要怎么告诉计算机，我要new哪个对象呢？
这里当然可以用switch然后根据type去new，但是如果写在main里面，那么我们多加一个开根号的方法，那么肯定在改动上层代码main，这又违背了我们初始的原则，所以这里就有一个简单工厂模式，其实实质就是根据不同条件，我给你生成不同的子类对象给你。
PS：
1、那个原则的B，意思应该就是先不管实现，先写接口，让实现去根据接口来编程，如果为了实现而去改接口，那你这个接口肯定写得没意义了，
当然我们不是大神的话，写接口肯定没那么全面，还是有可能会为了实现去改接口，但那肯定是我们接口设计不合理~~
2、简单工厂模式结合策略模式，感觉更精简，策略模式就是根据不同的条件，去执行不同的策略，跟简单工厂模式很像，（在书里40页，PDF 60页，等看了再回来看一下）
不同的是是策略类里面持有父类，然后去调用父类方法。
比如策略类里持有一个Operation的引用mOperation，简单工厂生产出具体的加法类OperationAdd 后指向mOperation
策略类里面再封装一个方法去调用mOperation.GetResult()，这样的话main里面只要去调用策略类就可以了，连Operation和工厂类都不用去理会，
这样的封装个人觉得是得看场合吧，感觉不用封装得这么彻底的。。
其实我觉得你要先理解这些设计模式，然后再去看那些封装得很好的代码，才能觉得真的好，阅读性好，不然的话我觉得会越看越乱，比那种直接写实现的还乱。
但是为什么我们要学设计模式呢，这就比如有一台计算器能实现一个复杂算法，自己算的肯定也能实现，如果你不懂操作计算器，你肯定花的时间比自己算的时间长，
反之如果你懂应用这个计算器，那肯定杠杠的好用，人类之所以厉害，就是会用工具，设计模式就是工具，你看大神写的代码，看不懂，以为太乱，其实是自己基础太差。
大话设计模式还没看完，只是想做个笔记，应该有很多地方理解错了，如果发现，请见谅。。（麻烦跟我说声哈）
网友评论