设计模式开篇闲谈

所有编程初学者都会有这样的问题,就是碰到问题就直觉地用计算机能够理解的逻辑来描述和表达待解决的问题及具体的求解过程。这本身没有错,但这样的思维却使得我们的程序只为满足实现当前的需求,程序不容易维护,不容易扩展,更不容易复用。

中国古代四大发明,另三种都是科技的进步,伟大的发明或发现。只有活字印刷术较之之前的刻板印刷是思想的成功。所以它跟面向对象编程思想有很多相似之处:第一,要改,只需要改要改之字,此为可维护;第二,这些字并非用完一次就无用了,完全可以在后来的印刷中重复使用,此为可复用;第三,要印刷的文章要加字,只需要另刻字加入即可,此为可扩展;第四,字的排列可能是横排也可能是竖排,此时只需要将活字移动就可以满足排列需求,此为灵活性好。面向对象编程思想要考虑通过封装、继承、多态把程序的耦合度降低,传统印刷术的问题就在于所有的字都刻在同一版面上造成耦合度太高所致,要考虑用设计模式使得程序更加的灵活、易于修改、易于复用

编程是一门技术,更加是一门艺术,不能只满足于写完代码运行结果正确就完事,时常要考虑如何让代码更加简练,更加易于维护,易于扩展,易于复用,只有这样才可以真正的提高,只有追求完美才可以真正提高。写出优雅的代码真是很爽的事情。UML类图是理解面向对象的开始。

设计模式:是指在软件开发中,经过验证的,用于解决在特定环境下,重复出现的,特定问题的解决方案。设计模式起源于建筑行业,一位叫Alexander的建筑师发现并总结了一些建筑行业的设计模式。在1995年,由Erich Gamma、Richard Helm、Ralph Johnson、Jhon Vissides合著的《设计模式—可复用面向对象软件的基础》一书拉开了软件业设计模式的序幕,这四人就是大家熟知的GoF(Gang of Four 四人帮)

时间: 2024-10-05 12:47:52

设计模式开篇闲谈的相关文章

JS学习十五天----设计模式开篇

JS设计模式开篇 前言 作为小小程序员一枚,除了敲个hello,world以后啥都不会了,最近发现设计模式这个东西挺好,想搞一下,声明,本屌不是一个看见什么好,什么新潮就追什么的人,本屌还是一个比较实际的人,一般不会说什么好要什么,学设计模式完全是个人的爱好,看一看做是无聊打发时间的消遣吧. 什么是设计模式呢?既然是个模式,就说明可以套用这个模式,套用你知道是什么意思吧?一本万利明白吧?差不多就是这个意思,等你熟练掌握了所有的设计模式之后,你就可上九天揽月,可下五洋捉鳖.手握日月摘星辰,世间无我

【转】JS设计模式开篇

(原文地址:http://blog.chinaunix.net/uid-26672038-id-3904513.html) 本文主要讲述一下,什么是设计模式(Design pattern),作为敲键盘的我们要如何学习设计模式.设计模式真的是一把万能钥匙么? 各个代码的设计模式几乎每个人都知晓,就算不会那也一定在一些装逼的大牛(部分而已)口中听过.但可能很少有人知道设计模式的由来: 设计模式该术语源自Erich Gamma等人在上世纪90年代从建筑设计领域引入到计算机科学的(很难想象到底有多大关联

设计模式开篇

/** * 设计模式四要素: * 1. 模式名称 * 2. 问题 * 3. 解决方案 * 4. 效果 * 设计模式分为三种类型: * 1. 创建型模式: * 1.1 简单工厂模式 * 1.2 工厂模式 * 1.3 抽象工厂模式 * 1.4 单例模式 * 1.5 原型模式 * 1.6 建造者模式 * 2. 结构型模式: * 2.1 适配器模式 * 2.2 桥接模式 * 2.3 装饰模式 * 2.4 组合模式 * 2.5 外观模式 * 2.6 享元模式 * 2.7 代理模式 * 3. 行为型模式:

【HeadFirst设计模式——开篇】

最近在看HeadFirst,接下来的一段时间会陆续更新有关HeadFirst设计模式相关的文章.记得很久之前在学习大话设计模式的时候,只是走马观花的大致走过一遍,至于里面很多东西都掌握的不是很好.恰巧又接触了HeadFirst,想着还是把设计模式好好的整理一下,至于是大话设计还是HeadFirst,个人看来是无关紧要的.本着学习的目的,而且都是设计模式,只不过一个是C#,一个是Java. 本来第一篇文章想着从观察者模式开始讲起,但是想着想着,还是把UML的类图的关系捋一下吧,不然的话类图都看不懂

Java设计模式(第一讲):设计模式开篇

刚进入职场,那时的我们充满期望,心中满是对技术的渴望,我们计划白天完成工作,晚上学习技术,奈何事与愿违,实际情况是这样的:身边的大牛很快的完成工作,顺利的通过测试,早早的收拾包回家,还能拿到你不知道的高额工资:而你却加班到天亮,修复着重复出现的BUG,写出的代码自己看着都感觉累,拿到的工资缺不知道是大牛的几分之一. 原因是什么?我们都在寻找,我们也期望的自己变成大牛,我只能告诉你不要急,大牛也是从菜鸟虐起来的,永远不要放弃你那颗追求技术的心,让我们来看看菜鸟进阶大牛的第一步-设计模式. 设计模式

javascript设计模式开篇:Javascript 接口的实现

javascript语言不像java. c#. c++等面向对象语言那样有完备的接口支持,在javascript中,接口的实现有三种方式,分别为注释描述.属性检查.鸭式变形.注释描述实现起来最为简单,但是,接口约定的遵守纯靠自觉,而且也没有很好的度量措施,说到底,它主要还是属于程序文档范畴.其实,类是否申明自己支持哪些接口并不重要,只要它具有这些接口中的方法就行了.鸭式变形(这个名称来自James Whitcomb Riley的名言:"像鸭子一样嘎嘎叫的就是鸭子")正式基于这种认识.

设计模式开篇综述(Java)

设计原则是规范,设计模式是技巧.如果在项目中能够灵活运用这些基础知识,那么我相信一定会得到意想不到的收获. 接下来的时间里,我将继续学习设计模式,将对每一个设计模式从以下几点进行分析和学习,如有不妥当或者理解错误的地方,欢迎大家指正和批评: (1) 定义:描述该模式是什么,有什么样的作用: (2) 问题描述:该模式是针对什么样的问题而出现的,由开发中遇到的问题而引入: (3) 解决方案:给出合适的解决方案,进一步解释该模式的定义: (4) 结构图:根据定义,绘制相关栗子的UML结构图: (5)

设计模式——开篇

终于决定写设计模式这个系列的文章了,从事软件开发这3年多来,面对纷繁的技术,却慢慢迷失了自己,看的多了,学的多了,到头来每种都会一点,却每种都是一知半解,于是下定决心寻找软件世界最本质的东西——软件的哲学.决定先从设计模式下手,从软件最细小的颗粒着手,慢慢领悟软件架构的威力.熟悉设计模式首先得对UML类图有深入的了解,下面的图解是为了帮助我能更好的记住他们. UML中描述对象和类之间的关系包括:依赖,关联,聚合,组合,泛化,实现等. 依赖(Dependency):B的变化影响A,反之则不成立,那

设计模式开篇--设计模式六大原则

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