设计模式(总纲)

概念:设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

以下是对上面有下划线的关键字的通俗解释:

  1. 反复使用:在实际的开发中被使用的次数太多了,比如:单例模式、外观模式、工厂模式等
  2. 多数人知晓:作为一个程序员即使没看过相关书籍不了解所有设计模式的具体内容也会知道一些非常常见的几种设计模式,而且有些设计模式即使你不知道,在日常的代码开发中也会使用。
  3. 分类编目:就是说可以找到一些特征去划分这些设计模式,从而进行分类。
  4. 代码设计经验:代码写多了,就会积累代码设计的经验,设计模式就是从这些经验中总结出来的用来解决一些特定场景中的问题的方法。

优点:

  设计模式可以帮助我们改良项目的代码,增强代码的健壮性、可扩展性,为以后开发和维护铺平道路。有过开发经验的人都知道一个项目的代码设计好坏对之后开发的影响,特别是从事维护项目工作的人应该有更深的体会(虽然我并未从事过维护= 。=),可以想象当一个看起来很简单的需求,但是由于项目设计问题,并没有考虑到这个需求的变更时或则由于需求不断变更导致代码变得臃肿,而导致当你修改其中一处可能导致其他功能出现异常,加深了维护代码的难度,这是一个非常严重的后果。

注意点:

  设计模式是可以改善项目的设计,但过多的使用甚至滥用将会导致项目变得复杂,难以读懂。所以当我们第一次设计一个系统时,请将你确定的变化点处理掉,不确定的变化点千万不要假设它存在,如果你曾经这么做过,那么请改变你的思维,让这些虚无的变化点在你脑子中彻底消失。因为我们完全可以使用另外一种方法来处理那些不确定的变化点,那就是重构。至于重构等讨论完设计模式后再进行探讨。

原文地址:https://www.cnblogs.com/guohaien/p/8297154.html

时间: 2024-08-14 01:45:09

设计模式(总纲)的相关文章

设计模式总纲

开闭原则:一个软件实体应当对扩展开放,对修改关闭. 就是说在不修改的前提下,仅依靠添加新代码来改变这个模块的行为. 通过扩展已有的软件系统提供新的行为满足对新需求,使变化中的软件系统有一定的适应性和灵活性.另外,重要的抽象层模块不能修改,使得变化中的软件系统具有一定的稳定性和延续性. 个人理解就是软件系统的取舍之道,在不失重心的前提下最大化的支持功能拓展. 里氏替换原则:所有引用基类的地方必须能透明的使用其子类的对象. 这个模式是为了更好的使用继承.使用继承也会增加模块之间的耦合度甚至会引发不可

设计模式总纲——单例设计模式

前两天写了设计模式总纲,今天就来讲讲我们在工程代码中最最最常用的设计模式了——单例设计模式,这个模式在工程代码上的出现率几乎为99.99999%,但是虽然很常用,但是用的好的人却不多,今天我们就来深入的说一说单例设计模式. 在学习一项新的知识之前,我们都要向自己提出三个问题,为什么要用这个知识,这个知识用在哪里,这个知识怎么用?既 why,where,how,3W模式,我们先来谈谈为什么需要单例设计模式,先来想想,如果一个工具类,比如一个读取配置文件的工具类,这类工具只是特定的功能类,既读取指定

设计模式总纲——工厂模式

前几天写了个单例模式,反响平平,可能是因为网上的设计模式实在是烂大街了,无法get到读者的点,不过也算是自己对自己知识的总结,今天我们换种角度来说一下这个工厂模式,工厂模式,目前主要的有三种,简单工厂,普通工厂,抽象工厂模式,今天我们就不谈抽象工厂模式了,我们来说说简单工厂和普通工厂的设计模式.今天我们要引入另外一个主角,他的名字就是——小陈. 小陈是个设计师,他很喜欢自己做些小玩意,那些小玩意都很精美,有一天,他的好朋友来家里玩,看到了小陈做的那些小东西,喜欢的不得了,就纷纷拜托小陈做些小玩意

设计模式总纲——抽象工厂模式

话说,上次小陈自从把生产线从小作坊换成中大型工厂之后,业绩是一日千里,小陈更是财源滚滚,订单是一件接着一件,正直NBA火热,特别是NBA系列的产品卖得相当火热,这时有件事情让小陈犯难了,因为在这边,小陈目前的生产线只是进行单一的进行生产,队徽工厂生产着队徽,球衣工厂生产的球衣,球鞋工厂生产着球鞋,而小陈在业绩提高的同时,他对业绩进行了大数据分析,他发现了,购买了骑士队队徽的人有99.99999%的人会购买骑士队服,和印有骑士队标的球鞋,同理购买了雷霆队徽的人也会购买雷霆队的队服和雷霆队的篮球.

(四) 工厂方法模式

转载: http://www.cnblogs.com/zuoxiaolong/p/pattern5.html 本章我们继续讨论新的设计模式,工厂方式模式,在这之前,LZ决定先给出引自其它地方的标准定义以及类图.  定义:工厂方法(Factory Method)模式的意义是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类当中.核心工厂类不再负责产品的创建,这样核心类成为一个抽象工厂角色,仅负责具体工厂子类必须实现的接口,这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色

设计模式详解(总纲)

转载:http://www.cnblogs.com/zuoxiaolong/p/pattern1.html <简介> 说到设计模式,当初第一次听到时,第一反应就是很深奥,完全理解不了这个概念到底是什么意思,下面我先从网上摘录一份定义. 设计模式(Designpattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结. 上面是百度当中的解释,来解释一下这句简单的话的含义,几个关键词.  反复使用:这个不用过多解释,设计模式被使用太多了,上个系列spring源码当中就出现了

设计模式的六大原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

重温设计模式

设计模式,及软件设计中的"套路".每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题解决方案的核心,这样,你就能一次又一次的使用该方案而不必做重复的劳动.设计模式大约有20多种,它们使人们可以更加简单方便的复用成功的设计和体系结构,提高系统维护的有效性.与设计模式密切相关的是6大设计原则,那么就从这些设计原则开始设计模式重温之旅吧.(ps:内容有点小多) 一.6大设计模式 1.单一职责原则 核心思想:应该有且仅有一个原因引起类的变更 问题描述:假如有类Class1完成职责T1

设计模式六大原则

设计模式 六大法则:(尽量符合,高内聚低耦合) 1: 单一职责(Single Responsibility Principle) :  一个类尽量只完成一个功能 .  职责扩散在程序上有可能会导致类不能完全实现单一职责. 2:  里氏替换原则(Dependence Inversion Principle):      所有引用基类的地方必须能透明地使用其子类的对象                                        通俗解释: 子类可以扩展父类的功能,但不能改变父类原有