设计模式与面向对象

1.设计模式与面向对象

      模式即从经验中汇总出来的规律。

      好的面向对象设计是那些可以满足应对变化，提高复用的设计。

      由于程序设计模式在实现的时候需要不断的变化，不能像其他领域的设计模式具有较好的实现性，所以源代码即设计。

      设计模式应该具有很好的应用性，这需要对设计模式有十分清晰的理解，从模式到具体的实现是一段很长的距离。

      理解面向对象的相关概念与理解面向对象思想有时候是有很大区别的

      对象是可以被使用的公共接口。

      面向对象的一些要点：

          （1）针对接口编程，而不是针对实现编程：客户只需要知道对象中有你所想要的接口即可。

          （2）优先使用对象组合，而不是类继承。

          （3）封装变化点：实现对代码的分隔，在对一部分代码修改时，不影响其他部分代码。

          （4）使用重构得到模型：设计模式与项目之间并不是一一对应的关系，想要找到合适的设计模式就需要不断的对设计模式进行重构以切合项目的具体需求

    设计原则：

          （1）单一职责原则：一个类应该仅有一个引起它变化的原因。

          （2）开放封闭原则：类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）

          （3）Liskov替换原则（LSP）：子类必须能够替换它们的基类

          （4）依赖倒置原则（DIP）：高层模块不应该依赖于底层模块，二者都应该依赖于抽象。抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

          （5）接口隔离原则（ISP）：不应该强迫客户程序依赖于他们不用的方法。

 

2.《设计模式之禅》———六项基本原则：

1.单一职能原则：

         单一职责原则的定义是：应该有且仅有一个原因引起类的变更。

         接口一定要做到单一职责，类的设计尽量做到只有一个原因引起。

         每一个类实现的功能和作用要单一。实现逻辑操作的要重新生成一个类，不要在实体类中给出复杂业务逻辑的操作。调用到业务逻辑的服务操作也要重新生成一个类，边界尽量清晰。

2.里氏替换原则：

         子类可以继承父类的私有方法以外的所有方法和非私有的属性，重写可以覆盖掉父类中同名同参数的方法。

         子类必须完全实现父类的方法。

         子类可以有自己独立的属性和方法。

         覆盖或实现父类的方法时输入参数可能会被放大。（如果子类给的参数范围大于父类，不会被执行到，要求子类给参数类型必须等于父类）。

         覆盖或者实现父类的方法时输出可以被缩小范围。（父类的返回参数类型必须大于子类）

         代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。

         提高代码的重用性。

         子类可以形似父类，但又异与父类。

          注意：在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的实际已经违背了LSP原则。

          注意：如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

3.依赖倒置的原则：

          高层模块不应该依赖底层模块，两者都应该依赖其抽象。

          抽象不应该依赖细节。

          细节应该依赖抽象。

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

          接口或抽象类不依赖于实现类。

          实现类依赖接口或抽象类。

         在Java中，只要定义变量就必然要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是对象的类型。

         使用接口，就是面向接口编程。

         依赖是可以传递的。

4.接口隔离：

         实列接口（Object Interface），在Java中声明一个类，然后用new关键字产生一个实例，他是对一个类型的事物的描述，这是一种接口。

         类接口（Class Interface），Java中经常使用的interface关键字定义的接口。

         隔离的定义：

         客户端不应该依赖他不需要的接口。

         类间的依赖关系应该建立在最小的接口上。

         建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。

        接口实现的作用越简单越好，最好是只针对某一项相同对象的。

 

5.迪米特法则：

         注意：一个类之和朋友交流，不与陌生人交流，不要出现getA（）. getB（）. getC（）. getD（）这种情况（在一种极端的情况下允许出现这种访问，即每一个点号后面的返回类型都相同），类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。

         类之间的调用，最好不要知道被调用者中其他信息，只要知道对应的接口即可。具体如何实现不需要知道，或者越少越好。

 

6.开闭原则：

         开闭原则的定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

          一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

         注意：开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，底层模块的便更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

         使用extends(继承)的方法实现原有的类的方法以及扩展其中的应用，应用去系统升级，替换实现类即可，不需要太多变动。

 

3.UML -- 概述
概念:
      统一建模语言（UML） 是一种直观化 明确化 构建和文档化软件系统产物的通用可视化建模语言。作为一个支持模型化和软件系统开发的图形化语言，UML为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
UML规范用来描述建模的概念有：类(对象的)、对象、关联、职责、行为、接口、用例、包、顺序、协作，以及状态。

UML概念范围：静态结构，动态行为，实现构造，模型组织，拓展机制。

在UML系统开发中有三个主要的模型： 
      功能模型: 从用户的角度展示系统的功能，包括用例图。 
      对象模型: 采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类图、对象图、包图。 
      动态模型: 展现系统的内部行为。 包括序列图，活动图，状态图。

UML视图（视图是表达系统单个方面的UML建模结构的简单子集）：
     视图在最高层次可以划分为三个领域 ：结构性分类 ，动态行为和模型管理。
     结构性分类描述了系统中的事物和事物间的关系。分类视图包括静态视图 用例视图和实现视图。
     动态行为描述了系统时间上的行为。行为视图包括状态机图 活动图和交互图。
     模型管理描述了用层次式的单元对模型自身的组织。

这周主要学习了用例视图，静态视图。以下是其内容：
     静态视图对应用领域的概念建模，静态视图的主要组成部分是类和关系 ，关联， 继承和各种依赖。静态视图显示为类图，其主要概念是类， 关联， 概括， 依赖，实现 ，接口。
     用例视图对外部用户 --称为活动者 --所感知的系统功能进行建模。用例视图的目的是列举活动者和用例显示活动者在每个用例中的参与情况，用例视图显示为用例图，其主要概念是用例 ，活动者 ，关联，扩展 ，包含 ，用例概括。

 

心得体会：初步学习UML发现虽然它不是一门程序设计语言，但他的重要性是不可忽视的。他的重要性主要体现在：使复杂的软件设计更为简单。用理解起来可能更容易的图来描述，避免了大量的文字；使表达和交流概念或系统结构变得更容易；在一张图中就能够描绘出整个系统；程序员实用类图来描述实际需求时，可让问题更加清晰明了，实现起来更容易。