比较先从一个最简单的模式，策略模式说起。
策略模式是指把策略的实现放到具体的类中，而不是直接写死到同一块if...else上。
在oop的实现中，策略被抽象成一个接口，也就是说这些策略类都要实现同一个策略接口。这样的好处是，使用策略和策略本身是解耦的，而且策略之间也是彼此独立的封装。新的策略可以随意被替换进来，而使用者“几乎”不用改什么代码。
在使用策略的类中，策略类作为使用策略类的一个属性，使用类直接调用策略类的execute方法，而这个策略到底被设置成了什么，此时此刻使用者并不知道，也并不需要知道。
我一直在想策略模式中，为啥要把策略做成一个属性，而非直接当成一个变量去使用，我想是因为属性能提供更多的功能吧，包括装饰器或者像spring的bean一样可以被配置。
最近要写一个系列的博客，总结设计模式。
首先我想展示我对设计模式的理解，它用来解决一个什么样的问题，同时它有哪些不足，还有我想表达一种思路就是作为支持面向对象的语言，是如何实现设计模式的。最后我想从python和java这两种语言比较设计模式的实现方式来说明这两种语言的特点。
这第一篇博客我要写一个总的概括，写一些我对设计模式的理解,后续的博客会详细讲解每一种设计模式，以及用python和java两种语言的实现方式。
我们常说的设计模式，其实是说的《Design Patterns: Elements of Reusable Object-Oriented Software》里面提到的23种设计模式，但实际上这些模式的思路在没有面向对象编程的时候，大多就已经有了，很多模式你可以从UNIX的设计思路上找到(参见《unix编程艺术》)。
这本书只能说是从面向对象的角度去实现设计模式。还有很多设计模式很常用，但是并没有出现在这23种，比如说我们常使用的表驱动模式（因为表驱动和面向对象无关）。
我其实上大学那会挺喜欢读鸡汤的，自从毕业之后才渐渐的有一种被鸡汤骗了的感觉，后来我发现很多同龄人其实也是排斥鸡汤的，当然还有一些每天依旧在喝鸡汤。
我想写一篇关于鸡汤的文章，但并不是批评鸡汤不好，我的博客的风格一直都是去尝试寻找一种原理和规律。所以写这篇博客的目的，就是想思考一下，为啥鸡汤让人这么喜欢读，它给了我哪些心理学上的思考。
需要注意的是，我所指的鸡汤，并不是网上那些随便给人鼓励，给人心灵启迪的文章，我认为在公众号上散播的大部分文章，都是鸡汤，或者是鸡汤的衍生产品。
首先我发现这些鸡汤都要有一个故事开头，如果这个鸡汤是一般鸡汤，那么故事可能就是个编出来故事，比如小男孩问雕刻家怎么知道天使就藏在石头里，再比如老鹰年纪大了要进行第二次重生，会把自己的羽毛都啄掉，再比如禅师给你的茶杯到热水。
它们的行文结构，也就是简单的：描述故事–>得出结论，类似：
最近有同事分享了一次java基础，里面提到了java基础类型的包装类型（比如Integer）和String都有自己的常量池,我突然想到在python中也有类似的东西，所以本来想写一篇关于分析python和java常量池的博客，但是后来我发现这里面的内容还挺多的，所以我决定先从整型常量池入手，下次再分析字符串的。
需要提到的是，我只是因为找到的有关python小整型池和大整型池的资料，才特意介绍python的。我并没有找到关于java大整型对象存储技术的文献，但是我猜都能猜到，如果java真有这方面的优化需求，是一定会有类似的东西，如果之后我了解到了，我会在自己的博客中再去介绍的。
首先是java的常量池，我搜索了java的常量池，大部分提到了，“java中基本类型的包装类的大部分都实现了常量池技术”这句话，它们都提到了对于Interger这样的对象（Byte，Short，Long，Character类似）在值小于127的时候，会默认使用内存池中已经创建好的数据。
这也就是为什么：
1 | Integer i1 = 100; |
的时候， i1 == i2会返回true，而在
1 | Integer i2 = 200; |
的时候， i1 == i2会返回False。
程序员们喜欢撕逼，他们会争论vim和emacs那个才是最牛逼的编辑器，会比较linux和Windows哪个更牛逼些，还会比较java和c#哪个更强大一些，因为他们总喜欢追寻自己的教条和信仰，跟别的队伍吵个不停。最近总听见有人在讨论关于编程语言的强弱类型，他们常常为某种语言是不是弱类型吵得不可开交。jser，PHPer们可能是因为被黑惯了,他们一般表现出”你说啥都行,弱类型就弱类型,无所谓，你们开心就好的心态。”但是pythoner不这么想，作为一个向往逼格的pythoner，如果有一个javaer跟他说：“python是弱类型，java是强类型”，那他一定会跟他争论个面红耳赤，再跟他讲“强类型，弱类型，静态语言，动态语言之间的区别与联系”。我原来就是这样的一个pythoner。但是最近我突然想起来大四的一节软件工程课上，老师谈到从第一代编程语言到第五代编程语言的区别，我发现分类方式和我在图书馆读到的不一样，所以我下课之后还去找他讨论了一番，但老师只是很平静的对我说，其实这个定义只是一个简单的分类说法，没什么严格标准的定义说某种语言就是第三代语言。这个经历让我突然想问自己，“我们在天天撕的强弱类型，它到底是个啥？”
目前而言，大部分人眼中c，java,C#这样的语言就被称为强类型语言，而php，js，python就被称为弱类型，因为他们认为像java这样的语言，任何一个变量在声明的时候，都要明确指定其类型，比如像这样：
1 | StringBuilder sb = new StringBuilder("SB!"); |
而python并不用在声明的时候，给它定义一个类型：
1 | s = "123" |
而且python的变量貌似看上去还可以随便赋值
1 | i = 1 |
所以他们就认为python是弱类型。
最近有一个需求，要跟踪一个计算机票报价系统的动作，这个系统会根据不同的策略做一些筛选，过滤，加减价之类的操作。最后再将这些报价打包成一个个的产品。因为不同的情况，计算出来的报价结果可能不一样，所以缺少某些报价的问题经常会让大家很头疼。也无法明确的排查为什么没有报价，也无法定位没有报价的原因。所以这个需求的目的，就是要能够明确的知道，我成功的计算出来了哪些报价，哪些报价被我过滤了，而且为什么被过滤了。
一开始我的思路是对每一个动作和操作打日志，然后收集这些日志。最后在展现它们，那么最终用户看到的效果就是这样：
1 | 2016 12 09 15:34:35 MU2323 U仓报价被过滤，原因非最低 |
这看上去像是一个标准的日志记录，在游戏中常见
1 | 2016 12 09 15:34:35 你打开了宝箱 |
但问题是这样散落到各处的日志并不好收集，而且也不容易对这些日志进行统计分析（自动化分析），还有这个设计并没有从用户的角度出发（从产品设计的角度出发），使用者并不想知道你系统的每一步执行步骤，你直接告诉他为什么没报价就好了，让不是让他自己找，让他自己分析，所以这个设计完全是一个技术实现。
还有一个更重要的问题是展示率的计算，展示率的公式是：实际展示的报价/应该展示的报价，那问题是我们在之前过滤掉了一些报价，但是这些过滤，有些原因是要算展示率的，有些则不算，如果你维护一个全局变量计数器，来根据不同的原因选择是否给分子加一，那你的程序一定非常容易出bug。