面向对象的技术

1、面向对象的基本概念

面向对象＝对象（object)+类（class)+继承（inhentance)+消息通信（communication with message）

多态性与重载：

多态，多种状态

多态分为两类：通用的（参数，包含）特定的（过载的，强制的）分别为：

重载（过载多态）指一个函数名称有多种不同的实现方式，在编译时通常通过类型签名来区分各个重载函数的名称。

覆盖（包含多态）：是重载的特殊形式。只发生在父类与子类中，通常签名相同，内容不一样。

多态变量（强制多态或赋值多态）声明为一种类型，但实际上可以包含另一种数值类型的变量。 如：Parent p=new child();

泛型（模板或参数多态)创建通用工具的方法，可以在特定的场合将其特化。

泛型，即“参数化类型”。一提到参数，最熟悉的就是定义方法时有形参，然后调用此方法时传递实参。那么参数化类型怎么理解呢？顾名思义，就是将类型由原来的具体的类型参数化，类似于方法中的变量参数，此时类型也定义成参数形式（可以称之为类型形参），然后在使用/调用时传入具体的类型（类型实参）。

泛型的本质是为了参数化类型。也就是说在泛型使用过程中，操作的数据类型被指定为一个参数，这种参数类型可以用在类、接口和方法中，分别被称为泛型类、泛型接口、泛型方法。

消息与消息通讯

为对象间相互交互提供一个方法。

如2016年上半年

第37题：在面向对象方法中，（37）是父类和子类之间共享数据和方法的机制。子类在原有父
类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现称为（38）。
A. 封装
B. 继承
C. 覆盖
D. 多态

答：这道题答错，没审好题呀，父类与子类间，只有  继承

第二空，覆盖，更适合。

2、面向对象程序设计

this指针：其实是代表着当前的对象。静态的变量函数才是class的，其他的都是对象的函数或变量，就要用this来代替。

继承成员访问控制机制：

一个类的私有成员是不能够被访问的。

类的对象的访问权限相当于其他类，只能访问公有的类（public),protected\privita不能被访问。

1、其他类（或类型对象）对此类中各个成员的访问权限如下表所示：

 2、派生类对基类的继承访问控制

访问控制机制在继承中的应用，实际上就是要看派生类能够继承基类的哪些成员以及这些成员的访问控制。

分析上表可以看出，派生类不能够继承基类的private成员； 

3、面向对象分析与设计方法

OOA（面向对象分析）OOD（面向对象设计）

OOA五个层次：主题、对象类、结构、属性和服务

五个活动：标识对象类、标识结构与关联、划分主题、定义属性和定义活动。

OOD就是OOA五个层次的结果包括四个部分：问题域部件、人机交互部件、任务管理部件、数据管理部件。

注：看到这里想起了MVC，项目用的架构？忘记了……。

 

MVC要实现的目标是将软件用户界面和业务逻辑分离以使代码可扩展性、可复用性、可维护性、灵活性加强。

View层是界面，Model层是业务逻辑，Controller层用来调度View层和Model层，将用户界面和业务逻辑合理的组织在一起，起粘合剂的效果。所以Controller中的内容能少则少，这样才能提供最大的灵活性。
 

我们知道在写程序时，业务逻辑的重复使用是经常要面对的场景。 如果业务逻辑写在控制器中， 要重用它的唯一方法就是将它提升到父类之中，通过继承来达到代码复用的效果。但这么做会带来一个巨大的副作用，违背了一项重要的面向对象设计原则：接口隔离。 

什么是接口隔离，我在这里简单的讲述一下。通俗一点讲，接口隔离就是当一个类需要继承另一个类时， 如果被继承的类中有继承的类用不到的方法或者属性时，就不要去实现这个继承。如果真的情非得已必须要继承，那么也需要从被继承的类中再提取出一个只包含需要部分功能的新类型，最终去继承这个新类型才是正确的做法。 换句话说，实现继承的时候，不要去继承那些用不到的事物。

回到之前的话题，通过继承父控制器的方式复用业务逻辑时，往往会出现为了重用一个方法而继承来一大堆用不到的方法，表面上看起来似乎没什么问题，但是这会使代码变的难以理解，
长此以往， 软件的代码会朝着不健康的方向发展。 

要知道，使用继承的条件是很苛刻的，我们学习面向对象变编程继承特性时，第一课就是只有满足IS-A（是一个）关系时才可以使用继承，如果仅仅是复用代码，并不是我们使用继承的理由。使用组合是复用代码提倡的方式，也就是所谓的HAS-A（有一个）的关系，相信每个程序员都听过“少用继承，多有组合”这句话，这句话是软件开发业的先驱们千锤百炼总结出来的，值得我们去遵循。
各Model之间是可以相互调用的， Controller也可以无障碍的调用Model，因此将业务逻辑放在Model中可以灵活的使用组合的方式复用代码。

众所周知，GoF总结过23个设计模式，这23个设计模式是某些特定的编程问题的特效药，这是业内公认的。 

MVC是一种模式，但却在GoF总结出来的这个23个设计模式之外，确切的说它不是一种设计模式，它是多种设计模式的组合，并不仅仅只是一个单独的一个模式。 

组成MVC的三个模式分别是组合模式、策咯模式、观察者模式，MVC在软件开发中发挥的威力，最终离不开这三个模式的默契配合。 那些崇尚设计模式无用论的程序员，请了解只要你们使用MVC，就离不开设计模式。 

注意，以下内容以这三个设计模式的知识为基础，如果对这三个设计模式没概念，或许会阅读困难。

先说组合模式在MVC中扮演什么样的角色。 

组合模式只在视图层活动， 视图层的实现用的就是组合模式，当然，这里指的实现是底层的实现，是由编程框架厂商做的事情，用不着普通程序员插手。

组合模式的类层次结构是树状的， 而我们做Web时视图层是html页面，html的结构不正是树状的吗，这其实就是一个组合模式的应用，只是浏览器厂商已经把界面相关的工作帮我们做掉了，但它确确实实是我们应用MVC的其中一部分，只是我们感觉不到罢了，这也是我们觉得View是实现起来最简单最没有歧义的一层的原因。

除网页以外的其他用户界面程序，如WPF、Android、http://ASP.NET等等都是使用树状结构来组织界面控件对象的，因为组合模式就是从界面设计的通用解决方案总提炼出来的。所以与其说MVC选择了组合模式，还不如说组合模式是必定会存在MVC中的，因为只要涉及到用户界面，组合模式就必定存。事实上即使不理解组合模式，也不影响程序员正确的使用MVC，组合模式本就存在于程序员接触不到的位置。 

然而，观察者模式和策略模式就显得比较重要，是实实在在MVC中接触的到的部分。

观察者模式有两部分组成，被观察的对象和观察者，观察者也被称为监听者。对应到MVC中，Model是被观察的对象，View是观察者，Model层一旦发生变化，View层即被通知更新。View层和Model层互相之间是持有引用的。 我们在开发Web MVC程序时，因为视图层的html和Model层的业务逻辑之间隔了一个http，所以不能显示的进行关联，但是他们观察者和收听者的关系却没有改变。当View通过http提交数据给服务器，服务器上的Model接受到数据执行某些操作，再通过http响应将结果回送给View，View（浏览器）接受到数据更新界面，这不正是一个接受到通知并执行更新的行为吗，是观察者模式的另一种表现形式。

但是，脱离Web，当通过代码去纯粹的表示一个MVC结构的时候，View和Model间无疑是观察者和被观察的关系，是以观察者模式为理论基础的。即使在Web中因为http壁垒的原因导致真正的实现有点走样，但是原理核心和思路哲学却是不变的。

最后是策略模式。策略模式是View和Controller之间的关系，Controller是View的一个策略，Controller对于View是可替换的， View和Controller的关系是一对多，在实际的开发场景中，也经常会碰到一个View被多个Controller引用，这即使策咯模式的一种体现，只是不那么直观而已。

总结一下，关于MVC各层之间关系所对应的设计模式

View层，单独实现了组合模式

Model层和View层，实现了观察者模式

View层和Controller层，实现了策咯模式

MVC就是将这三个设计模式在一起用了，将这三个设计模式弄明白，MVC将毫无神秘感可言。如果不了解这三个设计模式去学习MVC，那不管怎么学总归是一知半解，用的时候也难免不会出问题。

再次回到最前面讨论的业务逻辑应该放在Controller还是Model的问题上，从设计模式的角度讲，策略模式中的策略通常都很小很薄，不会包含太多的内容， Controller是一个策略， 自然不应该在里面放置过多的内容，否则要替换一个新的会相当麻烦，与此同时也会破坏View-Model的观察者模式，仿佛View-Controller之间即实现了策略模式又实现了观察者模式，这种混乱是罪恶的根源，是制造焦油坑让程序员陷入其中无法自拔的罪魁祸首。切忌，应当避免。
 

---

booch方法：螺旋上升的过程。包括以下几个步骤：

1、通过问题识别出对象，然后抽象出类。2、确定他们的含义3、找出类与类之间的关系对象与对象之间的关系。进行组合实现一些功能。4、进行详细的细化，从而发现问题，又进入第一个过程。

分为静态模型（侧重于系统构成与结构）动态（系统在执行过程中的行为）。

 

OMT方法：定义了三种模型：

对象模型：静态模型；用对象图来描述。对谁做的问题

动态模型：系统时序而改变状态。用状态图描述：何时做的问题。

功能模型：做什么的问题用数据流图来描述。

OMT建模四个活动：分析（建立可理解的现实世界模型，从问题的陈述入手，通过与客户交互以及与现实事件背景的了解，反映系统的三个本质特征（对象、类、及关系，数据流及变换），构造出现实世界的模型。）、系统设计（系统的体系结构，整个问题的求解结构形成高层的策略）、对象设计（在分析的基础上建立设计模型）和实现（转成特定的程序语言）。

4、设计模式：描述的是一个普遍发生的问题的相对稳定的解决方案。抽象出来的

要素：名称，问题、解决方案、效果

模式分类：按目的分（按应用是在哪个阶段完成）创建型、结构型、行为型

按范围分，类还是对象。

怎么使用设计模式：重要思想理念

1、通常是对接口进行编程，不对实现编程

2、对类功能的扩展要多用组合，少用继承。

创建型模式：对象如何创建，组合，表示一个对象

单身模式，类只产生一个对象。

结构型模式：如何组合类和对象，产生更大的结构。采用多重继承将一个类组合一个结果类。

适配器模式：使一个接口与其他接口相匹配。

装饰模式：给一个对象添加某些功能。

行为型模式：涉及到算法及行为间职责分配。描述的是动态变化的情况。类用继承，对象用复用机制

观察者模式：用户界面与业务逻辑分离。