抽象语法树

概念：

抽象语法树（abstract syntax code，AST）是源代码抽象语法结构的树状表示，树上的每个节点都表示源代码中的一种结构，之所以说语法是’抽象’的，是因为这里的语法不会表示出真实语法中出现的每个细节。

在这里先补充一个概念：具象语法树(Concret Syntax Tree, 简称CST)。
什么是具象语法树呢？
我们知道一颗解析树是包含代码所有语法信息的树形结构，它是代码的直接翻译，所以解析树也被称为具象语法树。抽象语法树实际只是解析树的一个精简版。

避免混淆，我们来简化一下概念：

解析树 = CST = 具象语法树
抽象语法树 = AST

那么抽象语法树到底是什么样的呢？我们可以来看一个简单的例子：

我们来写一段最简单js代码 20 + (15 - 3)*2，没错，这是一个简单的四则运算表达式，那么它的抽象语法树应该表现为什么样呢，在看AST(抽象语法树)之前，我们先来看一下它的解析树:

但是我们看到这样的一颗解析树显然是有些冗余的，那么我们可不可以对这颗解析树去繁取简呢，当然是可以的：

这里我们得到了一棵最简洁的树，去除了冗余的描述和符号，很直观的就可以看出树上每一个阶段节点之间的关系，从而也更能容易的推断出原表达式的样子，此时我们所得到的这颗树就是我们最终要得到的 20 + （15 - 3）*2 表达式的抽象语法树。

这里只是简单的对抽象语法树概念的简单理解，当然还有从分析树到抽象语法树的具体的转化过程以及具体的表现形式，如果有需要请自行查阅相关资料。
上述文章或许有理解错误，请不吝赐教！

序

        这么多天里，我已经读完了《大话设计模式》。放寒假了，没有了通过学业考试的重担，阅读技术书籍的时间页多出来了不少。

        在今天我刚阅读了《kafka权威指南》的第一章，关于介绍kafka这个消息发布与订阅系统的概念。在之前的一份实习中，我曾经接触到了kafka，但是我一知半解，也没有深入的了解为什么会有kafka的存在。恰巧前几天我在市图书馆看到一本名为《kafka权威指南》的书，于是就看了一小会。回来的时候意犹未竟，但也没有借回来，于是从网上找了本电子书继续学习。

        好了，现在切入正题，先总结外观模式。

外观模式

        书中在P108页给出的定义是这样的：外观模式为子系统的一组接口提供了一个一致的界面，此模式定义了一个高层接口，这个接口使得这一个子系统更加容易使用。结构图如下：

        外观类包含了所有的子系统的方法或者属性，进行组合，方便其他人进行调用。外观模式是之前的迪米特法则和依赖倒转原则的很好体现。

        依赖倒转原则是指：高层模块不应该依赖低层模块，高层模块和低层模块都应该依赖于抽象。抽象不应该依赖于细节，而细节应该依赖于抽象。

        迪米特法则也叫最少知识原则，迪米特法则（LoD）的和心思想是如果两个类不用通信，那么这两个类就不应当发生直接的相互作用。但如果其中一个类必须要调用另一个类的某个方法的时候，需用第三者转发这个调用，及尽量可能的将成员函数和成员设置成private类型。

        外观模式可以用来解耦合，对于一个不是太大的项目，他的代码已经有坏掉的味道时（尤其是我以前写的那些项目，啊哈哈哈，有空我想根据设计模式的思想改一下），可以用外观模型进行重构和解耦合。即使用面向对象的方法，将许多功能函数归到一类里去，尤其是变量都是差不多的那些功能函数，建立起包含了成员和成员函数的类。之后，再考虑用工厂模式等方式进行进一步改进。

        或者，遇到一个较复杂的项目，也可以用外观模式进行设计，用来给原来的一楼代码提供比较清晰简单的接口。这样不用改动原来的代码，也能提供新的功能，且能降低耦合度。

建造者模式

        建造者模式是在创建复杂对象算法应该独立于该对象的组成部分时，且创建复杂对象的步骤独立于装配该对象时。书中举了装配小人玩具的例子，装配小人玩具的步骤都是装脑袋、身体、胳膊和大腿这些步骤，不同的地方是脑袋、身体、胳膊和大腿是不一样长不一样外观这样，但步骤都是一样的，装配方式也是一样的，于是就可以使用建造者模式。换到代码中，我们实际上只要重写人物建造的抽象类的抽象方法即可。

        书中P115页给出的定义如下所示：建造者模式将一个复杂对象的构建与他的表示分离，使得同样的构建过程可以创建不同的表示。

        建造者模式的好处在于使得建造小人的代码与表示小人结构的代码分离，由于建造者隐藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要定义一个具体的建造者就可以了。

观察者模式

        观察者模式又叫发布-订阅模式，观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使得他们能够自己更新自己。（书P131）

        观察者模式结构图如下所示：

        为什么GoF会想到观察者模式呢？当许多类组成一个相互协同作用的系统时，程序员必然需要维护各个不同，但相关的类之间的一致性。于是这就形成了一种紧耦合的类间关系，维护这样的代码会很累，这是我们所不期望出现的，于是就有了观察者模式。

        通过设定一个抽象观察者类，进而具体化出各种形形色色的观察者类，用于生成一个个不同的观察者。每一个观察者拥有一个update成员函数（方法），用于更新被观察对象的状态。Subject类则是提供了添加观察者的方法Attach和绑定观察者与被观察者的方法Detach，以及一个Notify方法用于通知所有相关的被观察者。所谓”相关的被观察者是用引用的方法将其写入subject的具体类中里来实现的。所以，当情况有变化时，就可以通过Notify方法通知所有相关的“被观察者”。

抽象工厂模式

        先给出书上P149页的定义：抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。抽象工厂结构图如下所示：

         抽象工厂模式是对工厂方法模式的进一步改进。当有两种不同的、且类似的子类时使用。就像让一条流水线生产两种或者多种类似的商品一样，如果可以对流水线进行模块化设计，当要生产另一种商品时，能通过切换模块进行迅速转换生产对象。

        如果你不理解这句话，你就想想这个具体的例子，当一个Django项目本来用默认的SQLite写的，然后某个不写代码的又能管事的，要求你改用MySQL或者Oracle、SQL server、Access。诸如此类的事情一旦发生，对于一个没有事先使用抽象工厂模式的项目（或者那时候编码者还不知道这个模式的存在），那一定会被气的抓狂。尤其是从MySQL改成SQL server时，这意味着好多不支持的SQL语句都得修改，还得一句句的找，绝对气死人又累死人（哈哈哈好吧不吐槽了，切入正题）。

        如果项目一开始摸不准会不会中途换数据库，那就用抽象工厂模式就对了！它的思路与从简单工厂模式到工厂方法模式的想法是类似的！就是进一步细分，如图所示，设置一个工厂抽象类，用于具体化出不同的工厂，对于上一自然段的例子来讲，例如MySQL工厂、SQLserver工厂等等。该工厂类可以进而生成创建MySQL对象的“创建用户方法”。于是使用MySQL就创建MySQL对象，使用SQLserver就创建SQLserver对象。

        然后，Client也是抽象类，用于抽象出具体的用户类，例如MySQL用户类。可以用写各个具体的增删改查操作的方法了。由于各个数据库的SQL语句有差异，因此在这里分开来写就可以解决问题了。

以上就是这么多。最近几天一是有点累，但主要的是忙。是教资复习繁忙，主要是背诵很难搞，又要练物理题，实在是累死了，所以没有太多时间继续写博客。好在这篇博客分了好几天，终于是写完了。

END

如何梳理和重构_含复杂性度量

两个例子:

例子1: 一个 ftp 下载器

例子2: 支付参数

总结:

   1. 接口和实现. 父类和子类, 组合都能实现 抽象,层级.

   2.要达到最好的泛化.最好是无参数,无返回值.所有都是变成 field.

   3.组合的赋值是立体的.(一个嵌套一个的赋值,不可能是 abstract class), 继承的new 实例的赋值是拉平的.( 每一层都赋值,不过容易搞不清楚每一层需要赋值哪些参数.)

方法论:

   1.思考每个层级需要哪些字段

     1.1 这些字段是否可枚举化. (可枚举化的放 field,不可枚举化的放到接口里)

        这样的好处是最下层的bean 都可以通过 spring 容器来管理. 父类的 bean 该 autowired 的也可以 autowired.

       父类不能autowired

   1.2 最终的 spring bean.

如无必要,勿增实体,延迟具体化.卡姆剃刀法则

成功的设计

配合 spring 的动态配置获取. 因为要根据可变参数具体化(实例),所以无法利用 spring 的配置了.

无法固定的东西通过参数传递. 但是一旦有了形参,通用性就降低了.

如果要更好的使用 spring 的容器,那么设计的时候就要明确可固化和不可固化参数.

例如:ftp 下载.前缀可固化. 文件名依赖 Date 可变.

设计的时候可以用字段, 如果该层级的具体化类能赋值的用 field.

如果具体化类不能赋值的最好用abstract getField()方法. 这样能避免继承者忘记掉赋值相关属性.

不过如果想用组合的方式,那么就无法用 abstract 了.

不算成功的设计1:

ftp 下载基本配置: host ,userName

ftp 下载器: 1.下载地址,2.本地文件保存地址. 3.ftp 下载基本配置

渠道下载器 1.remotePrePath 2.localPrePath

业务下载器: 1.midPath (远程和本地保持一致) 2. 文件名(远程和本地保持一致)

具体化:

phoenix 渠道下载器 继承 <渠道下载器>: 无自有属性. 把 userName 和远程remotePrePath初始化.

phoenixPay 渠道下载器 ?

问题来了:

    phoenixPay 渠道下载器 到底是继承 <phoenix 渠道下载器> 还是 <业务下载器>?

答: 如果具体化没有新增的字段,那么暂时先别具体化.把渠道和业务具体化放到一起.少一个类.

解决方案(解决双继承问题):

   phoenix 渠道下载器 继承 业务下载器:

   phoenixPay 渠道下载器 继承 phoenix 渠道下载器

支付参数的具体化却不同.

  支付宝参数和微信参数不同.

   都是渠道的具体化,各自支付宝和微信的biz 子类,都要各自演化. 无法有一个通用的 biz子 类.