![](https://img-blog.csdnimg.cn/20201014180756925.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
设计模式
JMasterJ
这个作者很懒,什么都没留下…
展开
-
设计模式中类的关系
在java以及其他的面向对象设计模式中,类与类之间主要有6种关系,他们分别是:依赖、关联、聚合、组合、继承、实现。他们的耦合度依次增强。1. 依赖(Dependence) 依赖关系的定义为:对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。定义比较晦涩难懂,但在java中的表现还是比较直转载 2015-05-19 13:25:51 · 484 阅读 · 0 评论 -
23种设计模式之【工厂方法模式】
定义:定义一个用于创建对象的接口,让子类决定将哪一个类实例化。工厂方法使一个类的实例化延迟到其子类。讲解:工厂方法模式对简单工厂模式进行了抽象,根据依赖倒转原则,工厂方法模式把工厂和产品做了抽象处理,抽象出了抽象工厂(抽象类或接口)和抽象产品(抽象类或接口)。产品类的实例化由实现了抽象工厂的具体工厂来实现。类图:角色:抽象工厂类(Creator):抽象类或接口,定义原创 2015-05-22 23:49:15 · 537 阅读 · 0 评论 -
23种设计模式之【简单工厂模式】
定义:简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。讲解:简单工厂模式作为入门级的设计模式,并未收录在GoF的23种设计模式之中。然而在其23种设计模式中总会看到简单工厂模式的影子,所以笔者有必要在这里介绍一下。类图:角色:工厂类(Creator):具体类,提供一个静态的方法来创建产品。抽象产品(Product):接口或抽象类,抽象出产品共有的方法。具体原创 2015-05-22 14:41:53 · 501 阅读 · 0 评论 -
23种设计模式之【建造者模式】
定义:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。讲解:一个对象(产品),可能有几部分组成。比如一辆汽车,主要由车身、发动机、轮胎、传动系统等组成。这些部件或系统就是对象的表示。而建造者模式将汽车这个复杂对象的构建过程与它的表示分离。也就是说客户只需要告诉建造者模式我想要什么样的汽车(小轿车或大卡车)就可以了。至于汽车是如何生产出来了,客户并不关心。同样的原创 2015-05-25 18:11:25 · 648 阅读 · 0 评论 -
23种设计模式之【前篇】
23种设计模式,目前在网上各大论坛和相关书籍中,已经有很多资料可以参考。但是,笔者还是希望通过自身的学习,总结出自己对23种设计模式的理解,下面笔者会对这23种设计模式中的每一种模式进行单独的梳理和总结。Duang~开启设计模式之旅!三大分类1.创建型模式,共五种:(工厂方法模式)、工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。2.结构型模式,共七种:适配器模式、装饰器模原创 2015-05-22 10:19:57 · 481 阅读 · 0 评论 -
23种设计模式之【单例模式】
定义:保证一个类仅有一个实例,并提供一个访问它的全局访问点。讲解:让类自身负责保存它的唯一实例,这个类可以保证没有其他实例可以被创建,并且它可以提供一个访问(获取)该实例的方法。单例类应满足以下特点:单例类只能有一个实例。单例类必须自己创建自己的唯一实例。单例类必须给所有其他对象提供这一实例。类图:角色:单例类(Singleton):自己实例化自己的唯一原创 2015-05-25 14:10:13 · 572 阅读 · 0 评论 -
谈一谈自己对依赖、关联、聚合和组合之间区别的理解
在学习面向对象设计对象关系时,依赖、关联、聚合和组合这四种关系之间区别比较容易混淆。特别是后三种,仅仅是在语义上有所区别,所谓语义就是指上下文环境、特定情景等。他们在编程语言中的体现却是基本相同的,但是基本相同并不等于完全相同,这一点在我的前一篇博文《设计模式中类的关系》中已经有所提及,下面就来详细的论述一下在java中如何准确的体现依赖、关联、聚合和组合。首先看一看书上对这四种关系的定义转载 2015-05-19 13:43:19 · 457 阅读 · 0 评论 -
设计模式六大原则(1):单一职责原则
定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责P2功能。这样,当修改类T1时,不会使职责P2发生故障风险;同理,当修改T转载 2015-05-19 17:10:22 · 303 阅读 · 0 评论 -
设计模式六大原则(5):迪米特法则
原文地址:http://blog.csdn.net/zhengzhb/article/details/7296930定义:一个对象应该对其他对象保持最少的了解。问题由来:类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。解决方案:尽量降低类与类之间的耦合。 自从我们接触编程开始,就知道了软件编程的总的原则:低耦合,高内聚转载 2015-05-20 17:04:14 · 288 阅读 · 0 评论 -
设计模式六大原则(2):里氏替换原则
肯定有不少人跟我刚看到这项原则的时候一样,对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年,由麻省理工学院的一位姓里的女士(Barbara Liskov)提出来的。定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子转载 2015-05-19 18:11:36 · 310 阅读 · 0 评论 -
设计模式六大原则(4):接口隔离原则
原文地址:http://blog.csdn.net/zhengzhb/article/details/7296921定义:客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法。解决方案:将臃肿的接口I拆分为独立的几个转载 2015-05-20 16:08:47 · 338 阅读 · 0 评论 -
设计模式六大原则(6):开闭原则
原文地址:http://blog.csdn.net/zhengzhb/article/details/7296944定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。问题由来:在软件的生命周期内,因为变化、升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试。解决方案:当软件需要转载 2015-05-20 17:24:35 · 342 阅读 · 0 评论 -
设计模式六大原则(3):依赖倒置原则
定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接转载 2015-05-20 09:42:10 · 333 阅读 · 0 评论