1       编程语言的实质

编程的目的是：用计算机来解决现实世界的问题。

编程的过程：即在计算机所能理解的"模型”( 解空间)和现实世界(问题空间)之间，建立一种联系。

编程语言是一种"抽象”的机制，问题是对“谁”来抽象:





2       面向对象相关概念

面向对象三要素：封装（隐藏实现）、继承（接口的重用）、多态（对象互换）。

面向对象编程：面向对象编程不是使用面向对象的编程语言进行编程，而是利用多态特性进行编程。

面向对象分析：面向对象分析是将客观世界，即编程的业务领域进行对象分析。

贫血模型：

贫血模型是指使用的领域对象中只有setter和getter方法（POJO），所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层。





充血模型：

充血模型将大多数业务逻辑和持久化放在领域对象中，业务逻辑只是完成对业务逻辑的封装、事务和权限等的处理。





领域驱动设计DDD：

       领域模型是领域内的概念类或现实世界中对象的可视化表示，又称为概念模型或分析对象模型，它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

      领域模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。

3       软件设计的“坏味道”

僵化性( Rigidity) :很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分

的改动。如果单一的改动会导致依赖关系的模块中的连锁改动，那么设计就是僵化的，必须要改动的模块越多，设计就越僵化。

脆弱性(Fragility) :对系统的改动会导致系统中和改动的地方无关的许多地方出现问题。

出现新问题的地方与改动的地方没有概念上的关联。要修正这些问题又会引出更多的问题，从而使开发团队就像一只不停追逐自己尾巴的狗一样。

牢固性( Immobility) :很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

设计中包含了对其他系统有用的部分，而把这些部分从系统中分离出来所需的努力和风险是巨大的。

粘滞性(Viscosity) :做正确的事情比做错误的事情要困难。

面临一个改动的时候，开发人员常常会发现会有多种改动的方法。有的方法会保持系统原来的设计，而另外一些则会破坏设计，当那些可以保持系统设计的方法比那些破坏设计的方法跟难应用时，就表明设计具有高的粘滞性，作错误的事情就很容易。

       不必要的复杂性(Needless Complexity) :设计中包含有不具任何直接好处的基础结构

如果设计中包含有当前没有用的组成部分，他就含有不必要的复杂性。当开发人员预测需求的变化，并在软件中放置了处理那些潜在变化的代码时，常常会出现这种情况。

不必要的重复( Needless Repetition) :设计中包含有重复的结构，而该重复的结构本

可以使用单- -的抽象进行统一。

当copy, cut, paste 编程的时候，这种情况就会发生。

晦涩性(Opacity) :很难阅读、理解。没有很好的表现出意图。

代码可以用清晰、富有表现力的方式编写，也可以用晦涩、费解的方式编写。一般说来，随着时间的推移，代码会变得越来越晦涩。

4       面向对象设计的目的

面向对象设计的目的：高内聚、低耦合。

从而使系统易扩展、更强壮、可移植、更简单。

5       面向对象的设计原则

5.1     开-闭原则（Open-Closed Principle,OCP）

封装的问题 - 对可变性封装    一个软件实体应当对扩展开放，对修改关闭。你添加新功能的时候应该只是向代码集中添加新的代码不应该修改原来的代码。

5.2     里氏代换原则（Liskov Substitution Principle, LSP）

职责的问题 - 如何进行继承      LSP原则要求子类可以无条件的替代父类，子类不能对父类没有暴露的接口进行扩展，客户要调用功能只能通过父类暴露的接口来调用用不能擅自向子类调用。

5.3     依赖倒转原则（dependence inversion principle, DIP）

耦合度问题 - 针对接口编程       依赖倒转原则就是要实现依赖于抽象，抽象不要依赖于实现。要针对接口编程，不要针对实现编程。





5.4     合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP）

复用问题 - 尽量使用组合/聚合、尽量不使用继承       在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用这些对象的目的。

5.5     迪米特法则（Law of Demeter，LoD）

耦合度问题 - 不要和陌生人说话。       一个软件实体应当尽可能少的与其他实体发生相互作用。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

5.6     接口隔离原则（interface separate principle, ISP）

职责单一 - 恰当的划分角色和接口。       使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上。