多态与设计模式之我的理解

最近因为开发一个项目的关系在研究《Head First设计模式》,想从中找到一些灵感,虽然之前也看过,但是每次学习,都会有新的理解和感悟,非常感谢作者提供了这样一本让我受益匪浅的书!

  面向对象程序设计(注意这里是面向对象,而不是基于对象)的一个很重要的设计原则就是:针对接口编程,而不是针对实现编程!可就是这样一句句很浅显的话,确包含了很多面向对象的知识在里面!

  “什么是针对接口编程呢?”,“针对接口编程的真正意思是”针对超类型编程“。所以这里的”接口“就不再仅仅指的是java中的interface,还包括了抽象类,”超类型“在这里就是指”interface“和”abstract“类,当然不包括普通用于继承的类,因为普通的类虽然可以继承但是无法实现”多态“。而”多态“,正是”针对接口编程“的关键之所在!

  ”什么是多态呢?“,多态(Polymorphism)按字面的意思就是“多种状态”,指同一个实体同时具有多种形式。在面向对象语言中,接口的多种不同的实现方式即为多态。引用Charlie Calverts对多态的描述——多态性是允许你将父对象设置成为和一个或更多的他的子对象相等的技术,赋值之后,父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作。简单的说,就是一句话:允许将子类类型的指针赋值给父类类型的指针。如果一个语言只支持类而不支持多态,只能说明它是基于对象的,而不是面向对象的。利用多态,程序可以针对”超类型“编程,执行时会根据实际状况执行到真正的行为,不会被绑死在超类型的行为上。

  以下是非多态和多态的对比:

  例子:假设有一个类Animal,有两个子类(Dog与Cat)继承Animal:

  针对实现编程是这样做的:


class Animal {
String name;
String sex;

public void Display()
{
  System.out.println("name =" + name + "sex =" + sex);
}
public void Sound()
{
  System.out.println("make sound!");
}
}

class Dog extends Animal{
public void Sound()
{
  System.out.println("wang...wang...wang...");
}
}

class Cat extends Animal{
public void Sound()
{
  System.out.println("miao...miao...miao...");
}
}

public class AnimalTest {
public static void main(String[] args)
{
  Dog dog = new Dog();
  dog.Sound();
  
  Cat cat = new Cat();
  cat.Sound();
}
}

在上面这种针对实现的做法中,dog的行为来自Animal超类的具体实现,或是重载后的Sound方法,这种依赖于”实现“的做法会被”实现“绑得死死的,没办法更改dog行为,除非在Dog中写更多的代码!

  而”针对接口/超类型编程"做法如下:


class Animal {
String name;
String sex;

public void Display()
{
  System.out.println("name =" + name + "sex =" + sex);
}
public void Sound()
{
  System.out.println("make sound!");
}
}

class Dog extends Animal{
public void Sound()
{
  System.out.println("wang...wang...wang...");
}
}

class Cat extends Animal{
public void Sound()
{
  System.out.println("miao...miao...miao...");
}
}

public class AnimalTest {
public static void main(String[] args)
{
  Animal animal = new Dog();
  animal.Sound();
  
  animal = new Cat();
  animal.Sound();
}
}

 

  在这个例子中,Animal animal = new Dog();表示我定义了一个Animal类型的引用,指向新建的Dog类型的对象。由于Dog是继承自它的父类Animal,所以Animal类型的引用是可以指向Dog类型的对象的。

  在这种方式中,程序在执行时会根据animal的实际状况(对应哪个子类的赋值)执行到真正的行为(哪个子类的方法),不会被绑死在超类型的行为上,这也就是“在运行时指定具体实现的对象”,这也是多态的宗旨!当然“多态”的真正含义并不仅仅限于此,而“针对接口编程”正是利用了面向对象的这种“多态”特征来达到其“接口和具体实现分离“这一目的的!

  多态总结:

  (1)多态是通过:

  1、接口 和 实现接口并覆盖接口中同一方法的几不同的类体现的

  2、父类 和 继承父类并覆盖父类中同一方法的几个不同子类实现的.

  (2)通过将子类对象引用赋值给超类对象引用变量来实现动态方法调用。

  (3)java 的这种机制遵循一个原则:当超类对象引用变量引用子类对象时,被引用对象的类型而不是引用变量的类型决定了调用谁的成员方法,但是这个被调用的方法必须是在超类中定义过的,也就是说被子类覆盖的方法。

  1、如果a是类A的一个引用,那么,a可以指向类A的一个实例,或者说指向类A的一个子类。

  2、如果a是接口A的一个引用,那么,a必须指向实现了接口A的一个类的实例。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-04 18:12:04

多态与设计模式之我的理解的相关文章

浅析php单态设计模式之单例模式的理解

1.单态设计模式含义: 单态模式的主要作用是保证在面向对象编程设计中,一个类只能有一个实例对象存在.作为对象的创建模式,单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统全局地提供这个实例.它不会创建实例副本,而是会向单例类内部存储的实例返回一个引用. 2.单台模式的三个关键点: ① 需要一个保存类的唯一实例的静态成员变量: ②构造函数和克隆函数必须声明为私有的,防止外部程序new类从而失去单例模式的意义: ③必须提供一个访问这个实例的公共的静态方法(通常为getInstance方法)

设计模式总结之没有结束的结尾

       设计模式是为程序代码优化而诞生的,目的是设计出易维护.容易拓展.易复用.灵活性好的程序.设计模式体现是面向对象的三大思想:封装.继承和多态.设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的:设计模式使代码编制真正工程化:设计模式是软件工程的基石脉络,如同大厦的结构一样.       学习设计模式的这段时间,写

设计模式总结之一三五

引言      什么是设计模式(What)?        设计模式是前人实际经验的积累和总结,都是着重解决实际的问题.        学习设计模式的目的(Why)?        通过学习设计模式来提高写出的代码的可维护性.可复用性.可扩展性和灵活性.也就是说让系统能够达到"高内聚.低耦合"的状态.        怎样学习设计模式(How)?        设计模式是前人的实践经验总结出来的,六大设计原则,23种设计模式:虽然每种模式都有固定的实现方式,但是设计的原则是活的,所以在学

C++设计模式编程中使用Bridge桥接模式的完全攻略_C 语言

桥接模式将抽象(Abstraction)与实现(Implementation)分离,使得二者可以独立地变化. 桥接模式典型的结构图为: 在桥接模式的结构图中可以看到,系统被分为两个相对独立的部分,左边是抽象部分,右边是实现部分,这两个部分可以互相独立地进行修改:例如上面问题中的客户需求变化,当用户需求需要从 Abstraction 派生一个具体子类时候,并不需要像上面通过继承方式实现时候需要添加子类 A1 和 A2 了.另外当上面问题中由于算法添加也只用改变右边实现(添加一个具体化子类),而右边

项目管理大法归档 - 思维导图、原型工具、接口测试、设计模式、版本管理、单元测试、持续集成、代码审查、Bug 跟踪

项目管理大法归档 - 思维导图.原型工具.接口测试.设计模式.版本管理.单元测试.持续集成.代码审查.Bug 跟踪 太阳火神的美丽人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作公用协议 转载请保留此句:太阳火神的美丽人生 -  本博客专注于 敏捷开发及移动和物联设备研究:iOS.Android.Html5.Arduino.pcDuino,否则,出自本博客的文章拒绝转载或再转载,谢谢合作. 项目管理大法归档: 1.思维导

探索MVP(Model-View-Presenter)设计模式在SharePoint平台下的实现

对于SharePoint Developers来说,往往会过多的去关注SharePoint平台和工具,而把设计模式和代码的可测试性放在了一个较低的优先级.这并不是说SharePoint Developers对设计模式不感兴趣,而是缺乏在SharePoint平台下使用设计模式的经验.所以本篇Blog正如题目所示:探索MVP(Model-View-Presenter)设计模式在SharePoint平台下的实现.利用MVP设计模式,可以尽量让我们的项目分离关注点.易测试.可重用.在实现MVP时,我也会

J2EE基础:MVC模式和Struts模式的理解

MVC方式通常在Smalltalk中用于建立用户接口.通过对MVC中蕴藏的设计模式可以帮你理解我们所说的"模式"的含义. MVC包括三类对象,Model是应用对象.View为其屏幕表示.Controller定义了对用户输入的处理(反应)方式.在应用MVC方式以前,通常将这三个对象的功能合到了一起,应用MVC分离了它们,为设计提供了灵活性和可重用性. MVC通过在view和model之间建立Subscribe/Notify协议,分离了view和model对象.View对象必须保证它的表示

从手工打造到工厂设计模式的演变历程

自定义View系列教程00–推翻自己和过往,重学自定义View 自定义View系列教程01–常用工具介绍 自定义View系列教程02–onMeasure源码详尽分析 自定义View系列教程03–onLayout源码详尽分析 自定义View系列教程04–Draw源码分析及其实践 自定义View系列教程05–示例分析 自定义View系列教程06–详解View的Touch事件处理 自定义View系列教程07–详解ViewGroup分发Touch事件 自定义View系列教程08–滑动冲突的产生及其处理

常用的Javascript设计模式

<Practical Common Lisp>的作者 Peter Seibel 曾说,如果你需要一种模式,那一定是哪里出了问题.他所说的问题是指因为语言的天生缺陷,不得不去寻求和总结一种通用的解决方案. 不管是弱类型或强类型,静态或动态语言,命令式或说明式语言.每种语言都有天生的优缺点.一个牙买加运动员, 在短跑甚至拳击方面有一些优势,在练瑜伽上就欠缺一些. 术士和暗影牧师很容易成为一个出色的辅助,而一个背着梅肯满地图飞的敌法就会略显尴尬. 换到程序中, 静态语言里可能需要花很多功夫来实现装饰