今天完成的事情：

• 阅读了《设计模式之禅》的 第一部分，主要是六大设计原则的介绍，总结如下；

  • Single Responsibility Principle： 单 一 职 责 原 则 
    
    • 用于划定类的职责，在合适的尺度上划分不同类所承担的责任，争取一个接口只完成某个方面的职责，不同的职责划分给不同的类完成
  • Open Closed Principle： 开 闭 原 则 
    
    • 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。这是为了应对不断变化的需求，为升级扩展打下基础。有抽象类约束，元数据控制模块行为（如spring的配置文件）， 项目开发章程约束，对预计产生需求变更的部分进行封装（相同的变更封装在一个类或接口，不同的变更封装在不同的地方）
  • Liskov Substitution Principle： 里 氏 替 换 原 则 
    
    • 约束了父类与子类之间的关系，要求所有能使用父类的地方都必须能透明的使用其子类的对象。
    • 这要求： 
      
      • 子类完全实现父类的各个方法
      • 子类可以进一步增加自身特色
      • 覆盖或实现父类的方法时输入参数可被放大（如父类参数hashmap→子类参数map)
      • 覆写或实现父类的方法时输出结果可以被缩小（如父类方法返回值map→子类返回hashmap）
  • Law of Demeter： 迪 米 特 法 则 
    
    • 调包侠的真理：一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系。这是为了类之间的低耦合关系 
      
      • 只与直接的朋友类相关联。这里的朋友关系指组合，聚合，依赖等。
      • 通过访问控制标识（protected,private等）保持朋友类之间的距离
      • 如 果 一 个 方 法 放 在 本 类 中， 既 不 增 加 类 间 关 系， 也 对 本 类 不 产 生 负 面 影 响， 那 就 放 置 在本类中。
      • 谨 慎 使 用 Serializable 。在网络编程中一旦客户端或者服务端其中一者实现了访问权限变更，而另一端未能及时更新，就会报序列化失败

  • Interface Segregation Principle： 接 口 隔 离 原 则

    • 接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少
    • 接口尽量细化，同时接口中的方法尽量少
    • 专门的接口指什么？就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。

  • Dependence Inversion Principle： 依 赖 倒 置 原 则

    • 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
    • 抽象不应该依赖细节；.
    • 细节应该依赖抽象。

    • 依赖倒置原则在Java语言中的表现就是：

      • 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
      • 接口或抽象类不依赖于实现类；
      • 实现类依赖接口或抽象类。

RESTful API：

restful api是什么？

传统请求格式：http://.../queryItems?id=1

REST api: http://.../items/1

官方教程：https://spring.io/guides/gs/rest-service/

以Gradle构建为例：

在选定项目目录下建立目录结构：mkdir -p src/main/java/hello

在项目目录下建立一个build.gradle文件作为整个项目的配置文件：

接着创建资源表示类：

预期访问http://localhost:8080/greeting 返回json:

{ "id": 1, "content": "Hello, World!" ｝

接着创建资源管理类，映射到/greeting访问路径

java -jar build/libs/gs-rest-service-0.1.0.jar

遇到的问题：

收获：

设计模式的套路很多，理论指导实践，实践验证理论，对于在某些条件下的取舍能够做到心中有数