《Head.First设计模式》 读书笔记大全

第一篇：《Head.First设计模式》 读书笔记大全

目录

1、创建型设计模式........................1

1.1工厂方法Factory Method【类】与抽象工厂Abstract Factory【对象、chapter 4】...1

1.2单件Singleton【chapter5、对象】...................22、结构型设计模式........................2

2.1适配器Adapter【chapter7、类/对象】...................2

2.2组合Composite【chapter9、对象】.................2

2.3装饰者Decorator【chapter3、对象】.....................2

2.4外观Facade【chapter7、对象】................3

2.5代理Proxy【chapter11、对象】................33、行为型设计模式........................3

3.1模板方法Template Method【chapter8、类】...............3

3.2命令Command【chapter6、对象】..................3

3.3迭代器Iterator【chapter9、对象】..................4

3.4观察者Observer【chapter2、对象】...............4

3.5状态State【chapter10、对象】.................4

3.6策略Strategy【chapter1、对象】.....................44、与设计模式相处........................51、创建型设计模式

1.1工厂方法Factory Method【类】与抽象工厂Abstract Factory【对象、chapter 4】

(1)工厂方法Factory Method：

定义：由子类决定要实例化的类是哪一个。让类把实例化推迟到子类。

实例：拓展披萨工厂，有各地风味的加盟店。

实现：分为Product(产品类 披萨)和Creator(创建者类 PizzaStore)两个类层级，都有许多具体的子类，每个子类都有自己特定的实现。

相关：“依赖倒置原则Dependency Inversion Principle”【6】。要依赖抽象，不要依赖具体类。PizzaStore是高层组件、比萨实现是低层组件，前者依赖后者。

(2)抽象工厂Abstract Factory：

定义：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

实例：原料（产品家族）工厂，每个子类都使用其区域的供货商来实现这些原料。相关：每个原料代表一个产品，由抽象工厂的工厂方法产生。

1.2单件Singleton【chapter5、对象】

定义：确保一个类只有一个实例，并提供一个全局访问点。独一无二的对象。实例：只有一个巧克力锅炉在用。

相关：处理多线程的情况。

2、结构型设计模式

2.1适配器Adapter【chapter7、类/对象】

定义：将一个类的接口，转换成客户期望的另一个。【对象适配器】

实例：交流电适配器、包装了鸭子适配器的火鸡（火鸡就是被适配者插座）实现：类适配器不是使用组合，而是继承被适配者和目标类，需要多重继承。相关：将枚举适配到迭代器

2.2组合Composite【chapter9、对象】

定义：允许将对象组合成树形结构来表现“整体/部分”层次结构，能让客户以一致的方式处理个别对象和对象组合。

实例：添加甜点子菜单、菜单组件和菜单项、素食菜单

相关：组合和迭代器凑在一起的魔力„

2.3装饰者Decorator【chapter3、对象】

定义：动态地将责任附加到对象上，若要拓展功能，装饰者比继承更有弹性。实例：星巴克咖啡的饮料订单（含摩卡、奶泡等各种配料）

实现：“开放-关闭原则”【5】，类应该对扩展开放、对修改关闭。

相关：给爱用继承的人一个全新的设计眼界。

2.4外观Facade【chapter7、对象】

定义：提供一个统一的接口，简化子系统中的一群接口。

实例：家庭影院 简化观赏电影

相关：“最少知识Least Knowledge”原则【7】，只和密友谈话，减少对象之间的交互。

2.5代理Proxy【chapter11、对象】

定义：为另一个对象提供一个替身或占位符以控制对这个对象的访问。

实例：糖果机的监视器、显示CD封面（加载中，请稍后…）、对象村的配对

相关：虚拟代理控制访问实例化开销大的对象，有许多变体：缓存代理、防火墙代理等。远程代理 Java RMI、虚拟代理、动态代理、写入时复制代理、同步代理等。

3、行为型设计模式

3.1模板方法Template Method【chapter8、类】

定义：在一个方法中定义一个算法的骨架，将部分步骤延迟到子类中。

实例：星巴克咖啡和茶的冲泡方法融合、排序鸭子….、一个Swing的窗口程序

实现：定义了一个算法的步骤，允许子类为各步提供实现。使用钩子，让子类选择要不要覆盖某步。

相关：“好莱坞原则”【8】，别调用（打电话给）我们，我们会调用（打电话给）你。工厂方法是模板方法的一种特殊版本。代码复用的重要技巧！

3.2命令Command【chapter6、对象】

定义：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其它对象。也支持可撤销undo()的操作。

实例：家电自动化遥控器、命令相当于对象村餐厅的订单

实现：调用者Invoker（女招待、遥控器）

相关：将发出请求的对象和执行请求的对象解耦；宏命令运行调用多个命令。

3.3迭代器Iterator【chapter9、对象】

定义：顺序访问一个聚合对象中的各个元素，而不暴露其内部的表示。

实例：对象村餐厅和煎饼屋合并之后，菜单实现

实现：菜单项的存储方式不同，包括数组、Arraylist

相关：“单一责任”【8】，一个类应该只有一个引起变化的原因。内聚cohesion。

3.4观察者Observer【chapter2、对象】

定义：定义了对象之间一对多依赖，当一个对象改变状态时，所有依赖者都会得到通知并自动更新。

实例：气象监测站、布告板更新

实现：主题对象、许多观察者Observable类

相关：“松耦合原则”【4】，为了交互对象之间的松耦合设计而努力。

3.5状态State【chapter10、对象】

定义：允许对象在内部状态改变时改变它的行为，对象看起来像是修改了它的类。实例：糖果机的控制

实现：每个状态都封装成一个类，并实现State接口。Context上下文会随着状态的改变将行为委托给当前状态对象。

相关：应用在条件语句繁多的场景。

3.6策略Strategy【chapter1、对象】

定义：定义了算法族，分别封装起来，让它们之间可以相互替代。

实例：鸭子飞、呱呱叫

实现： 使用组合相关：

“封装变化”【1】，Duck类内的fly()会随着鸭子的不同而改变。“针对接口编程”【2】，而不是针对实现编程。

“多用组合”【3】，少用继承。

4、与设计模式相处

不要为了使用而使用；保持简单且有弹性Keep it Simple/KISS。非僵化的教条；应需而变。

让你的团队拥有共享词汇，能够最大化沟通的价值！

模式是“被发现”，而非“被发明”。

模式被认为是历经验证的OO设计经验；真模式必须通过“三次规则”。良好的OO设计必须具备：可复用、可扩充、可维护三个特性。

第二篇：丰田模式读书笔记2

《丰田模式》读书笔记2

20120830

《精益生产》中，把精益制造定义为包含五个步骤的流程：

定义顾客的价值

定义机制的流程

建立连续的作业流程

拉动式

努力追求卓越

想成为一个精益的制造者，首先思维模式必须着重使产品的生产变成连续的附加值流程（亦即单件流），然后采取根据下游顾客需求而决定上游环节产量的拉动式生产方式——亦即上游环节只生产补充后续环节在短期间要领取的物料和零部件，最后关键在于建立一种努力追求持续改善的公司文化。

丰田的生产方式具有很强的灵活性，当你把前置期缩短，并注重维持生产线的弹性时，实际上就能提升质量，对顾客需求做出更佳的回应，提高生产力，改善设备和空间的利用率。

丰田对某些问题的解决方法，往往看似增加浪费，而非杜绝。这些看似矛盾的解决方法得自大野耐一亲自观察工厂作业以后，对“未能创造价值的浪费”所获得的特殊理解：它和充分运用劳工与机器设备没有太大关联，主要的影响因素是把原料转化为可售商品的流程。

精益生产需要工具如：快速的设备切换、职务工作的标准化、拉动式生产方式，防错技术等，更重要的是需要丰田生产方式背后真正的力量：该公司的管理层能够持续投资于“人”，并倡导持续改善的公司文化。丰田模式包含的不只是“准时生产”之类的精益生产工具而已。许多公司误把一套特定的精益生产工具当成深层的精益思维，其实，丰田模式中的精益思维涉及更深入、更普遍及渗透的文化转型，大多数公司根本未设想到这一点。

企业应该从推动一两个方案以刺激全体员工热忱为切入点。成熟确立的生产单位，解决问题的员工团队，公司制造特定的员工解决问题实践与奖励诱因，为员工设立学习资源中心。

丰田公司在建立组装线时，只挑选最优秀、最聪明的员工，并鼓励他们通过不断解决问题，在自己的领域实现成长。同样，丰田的销售、工程采购、财务、人力资源等所有部门的员工都是经过精挑细选的，公司要求他们设法改善自己的作业流程，找出满足顾客的创新方法。

如何显著改善作业流程？

杜绝与资源的浪费浪费

在工作场所的体制中内建质检

寻找低成本但可靠的方法以替代昂贵的新技术

力求作业流程的尽善尽美

建立追求持续改善的文化

第三篇：《丰田模式》读书笔记3

《丰田模式》读书笔记3

20120831

杜绝浪费——丰田生产方式的核心

什么是浪费？创造价值的活动是有意义的，对顾客而言，未能创造价值的活动就是浪费，这里的顾客包括工作中下个流程的工作人员。

八大未能创造价值的浪费：

丰田公司找到了七大类未能创造价值的浪费，但本书的作者在深刻理解了丰田模式的基础上提出了第八类浪费，笔者认为其反应了丰田模式最深层次的内涵——发挥员工不断持续改善的创造力，形成精益生产的企业文化。

不只是生产线，包括产品研发流程、接受订单及办公流程等，都可以区别出这七类浪费情形：

1.生产过剩 ：生产出尚未有订单的项目，造成人员过剩和过多存货导致的存储与输送等成本的浪费

2.在现场等待的时间：员工只是在一旁监看自动化机器，或必须站在一旁等候下一个处理步骤、工具、供应、零部件，等等，或是因为存货用完、整批处理延迟、机器设备停工、产能瓶颈等因素造成员工暂时没有工作可做。

3.不必要的运输:长距离搬运在制品；缺乏效率的运输；进出仓库或在流程之间搬运远物料、零件或最终成品。

4.过度处理或不正确的处理：采取不必要的步骤以处理零部件；因

为工具与产品设计不良，导致不必要的动作及产生瑕疵而造成缺乏效率的处理；当提供超出必要的较高质量产品时也会造成浪费。

5.存货过剩：过多原料、在制品或最终成品，导致较长的前置期、陈旧过时品、毁损品、运输与存储成本延迟。才外，过多存货还会造成其他隐形问题，如生产不均衡、供应者延迟递送、次品率上升、机器设备停工、拉长整备期（setup time）。

6.不必要的移动搬运：员工在执行工作的过程中，任何浪费、不必要的的动作，如寻找、前往取得，或是在堆放零件、工具等。此外，走动也是浪费。

7.瑕疵：生产出次品或必须修改的东西、修理或重做、报废、更换生产、检验等，意味着成本、时间和精力的浪费。

8.未被使用的员工创造力：由于未使员工参与投入或未能倾听员工意见而造成未能善用员工的时间、构想、技能，使员工失去改善与学习的机会。

其中过量生产是最严重的浪费，因为其他的浪费大多由其导致，所以作为精益生产，很关键的一点是避免生产过剩产生的浪费。

根据精益生产的概念，对任何流程，你应该做的第一件事是根据材料（或是文件、信息）的行进流程路径来规划价值流程，最好的方法是按照此流程路径进行实地操作，以获得充分的实际经验。你可以画出这条流程路径，计算花费的实践与行进的距离，然后赋予其一个高度技术性的名词——“复式线路图”（spaghetti diagram）网上一般

称为“意粉图”百度翻译为“意大利面图”。详细关于spaghetti diagram 的制作与展示将会在以后呈现。

以人为核心

丰田生产方式并不是一套工具，他并非只是包含准时生产、作业小组、5S、看板等内容的一套精益工具，它是一种高度发达的生产制度，结合了所有部分而成为一个完整的体制。

这个完整的生产体制，其根本在于支持与鼓励员工持续改善他们的工作流程。不幸的是，许多关于精益生产的书籍把丰田生产制度误解为提高员工工作效率的一套工具，致使这些工具迷失了方向，也忽略了丰田生产方式核心的精髓。更广义、全面地来看，丰田生产方式其实是应用丰田模式的原则，最初的中心放在生产环节上，但事实上，其原则涉及更广泛层面，完全可以应用于工程、行政管理、后勤服务等环节。

第四篇：丰田模式读书笔记1

《丰田模式》读书笔记（1）

丰田模式其成功的秘诀在于：以闻名世界的工具及质量改善方法做为基础，其中包括，准时生产、改善单件流、自动化、均衡化等工具，更为重要的是以了解和激励员工来成功实行这些工具的企业经营理念。换句话说，丰田的成功根源在于：它能培养领导力、团队与文化；而且它能有效地制定战略、建立坚实的供应商关系；以及建立并维持一个学习型组织。

丰田的14项原则可以分为四大类，简称4P：

A.理念（philosophy）B.流程（process）

C.员工/合作伙伴（people/partners）D.解决问题（problem solving）理念：管理决策以长期理念为基础，即使牺牲短期财务指标也在所不惜 流程：建立连续的作业流程以使问题浮现

利用“拉动系统”避免生产过剩

平抑工作量（均衡化）

出现质量问题即停止生产（自动化）

为实现持续改善将任务标准化

通过可视化管理使问题无所隐藏

只采用可靠的、经过充分验证的技术

员工/合作伙伴：培养深蕴公司哲学理念的领袖

尊重、培养并挑战你的员工和团队

尊重、挑战并帮助你的供应商

解决问题：利用“改善”使组织保持学习

亲临现场，彻底了解情况

制定策略时要稳健，穷尽所有的选择并征得一致同意

实施决策时要迅速

精益生产的影响力极大，但大多数企业在应用实施此方法时的做法相当肤浅，因为他们过度注重工具,不了解完整的精益生产制度必须渗透至组织文化中。大多数实施精益生产的公司，其资深管理层并未参与日常运营作业与持续改善行动，这些都是精益生产制度中极为重要的部分。

真正的精益企业应当是把丰田生产方式应用于业务所有的层面所获得的结果。

第五篇：企业应用架构模式读书笔记

企业应用架构模式读书笔记

主要说明的问题

 企业级程序分层

 构建领域的业务分层







 构建用户界面 将内存模块影谢到关系型数据表 在无状态下处理会话状态 分布原则

系统架构：

架构是专家级项目开发人员对系统设计的一些可以共享的理解。这种理解可以表现为系统主要部分组成部分及这些部分的之间的交互关系。

企业应用的特点

1.数据持久：程序多次运行都必须用到他们。

2.大容量存储：巨大的数据量导致数据的管理成为系统的主要工作

3.多人同时访问：要确保多人正确的访问数据就一定存在问题。即使人数不多要确保2个人同时操作同一数据项也可能存在问题。（事务管理工具可以处理以上问题但对开发者不透明）

4.存在大量用户操作界面

5.很少有单独存在的一般与其他周边系统相互集成关于性能

1.响应时间：系统完成一次外部请求的时间。响应性是系统的一个重要指标它表明系统响应请求的速度。如果响应性太慢用户难以忍受。尽管响应时间不慢。如果在处理请求期间系统一直处于等待状态，则系统的响应时间与响应性是相同的，然而如果在处理完成之前给出一些信息表明系统已经接受到请求则响应性会好些

2.等待时间：是获取系统响应的最小时间。

3.吞吐率：给定时间内能够处理的最大的请求数。对于企业应用来说通常用每秒事务数(tps)来度量。该指标依赖于事务的复杂的程度

4.负载：系统当前负荷的表述。可以用当前有多少用户连接来表述。负载也可以作为其他指标的参造。

5.负载敏感：响应时间随负载变化的程度.(可用衰减来表述)

6.容量：最大有效负载或吞吐量的指标。它可以是一个绝对最大值或性能衰减至低于一个可以接受的一个值之前的临界点

7.可伸缩性：度量向一个系统中增加资源（一般理解为硬件）对系统资源的影响。一个可伸缩的系统允许在增加新的硬件后能够提高若干性能。垂直伸缩性指的是提高单个服务器的性能。水平伸缩性指的是增加服务器的个数。在企业应用中关注硬件的可伸缩性比关注容量和效率更重要。

系统分层

用分层观点来考虑系统时可将各子系统按多层蛋糕的形式来组织，每层都依赖其下层之上。在这种组织上上层使用其下层定义的服务，下层对上层一务所知。宁外每一层对其上层仍长 其下层的细节。

分层的好处：

1.在无需了解其他层次的基础上可以将某一层作为一个有机整体来理解。

2.可以替换某层具体实现。只要提供服务相同即可。

3.可以讲层次的依赖性减低到最低。

4.分层有利于标准化工作

分层的缺点

1.层次不能封装所有的东西有时带来联级修改。

2.过多的层次影响性能

3.很难决定建立那些层次及层次的职责

分层的历史

20世纪90年以前没有分层

20世纪90服务器|客户端系统：这种系统2个层次客户端包括用户界面和其他应用代码。服务器端基本上为关系型数据库。这种方式将业务逻辑写在客户端显得十分笨拙不易重用。其二：将业务逻辑写到服务器上作为存储过程。但是存储过程只提供有限的结构化机制这将再次导致结构笨拙。关系型数据库重要特点是标准sql，允许更换不同的关系型数据库。单存储过程是各个数据库厂商私有的不能兼容。在服务器|客户端普及的时期出现面向对象方式。面向对象为领域逻辑的问题找到答案：转向多层结构。在这个结构下表现层表现为用户界面。在领域层表现领域逻辑，在数据层存取数据。这种方式将复杂的业务逻辑独立出来单独放入中间层可以加以建模和组织。

三个基本层次

1.表现层：提供服务、显示信息。处理用户与软件的交互。主要职责是向用户显示信息并

从用户那里获取信息理解解释为领域层或数据层上的动作。

2.领域层：系统业务逻辑。它是应用必须做的所有领域工作：包括根据输入数据或已有的数据进行计算。对从表现层输入的数据进行数据有效的认证以及根据从表现层接受的命令调度那些数据层资源。

3.数据源层：与数据库、消息系统、事务管理器及其他软件通讯。主要关注与其他系统的交互。这些系统将代表应用完成相关的任务。对大多少企业应用来说就是数据库。主要永久存储数据。

层次的表现形式：

1.领域层对表现层完全影厂。

2.表现层对数据源层直接操作。

表现层可以解释用户的命令通过数据源层将相关数据从数据库中提出来让领域层在向用户显示前作相关的处理

表现层可能与数据源层一样出现很多接口。因为他们都是可能是系统的外部接口它就是

【wiki】模式的背后逻辑：它将任何系统都视为由到外部系统的接口。

分层的普遍原则：领域层或数据层绝对不依赖于表现层。也就是说在领域层和数据层代码中部要出现调用表现层代码。这条规则简化在相同基础上替换表现层的代价。也使表现层的修改带来的连锁反应尽可能的小。

如何区分领域逻辑: 假想向系统中新增一个完全不同的新层次，如果需要重复实现某项功能则说明该功能是本该在领域层实现。

领域逻辑的组织

组织领域逻辑的三种模式：事务脚本、领域模式、表模块。

1.事务脚本：保存领域模式的最简单的方式。它从表现层获取输入、进行校验证、计算处

理、将数据保存到数据库中、以及调用其他系统的操作等。然后该过程将更多的数据返回给表现层。基本的组织方式是让每个过程对应用户的可能做的一个动作。

优点：大多数人都能理解的简单过程

能够使用行数据入口或表数据入口

很容易表述事务的边界

缺点：

当如干事务需要做相类似的操作时通常脚本里包含相同的代码。通过这些相同的代码可以组成公共函数可以消除次现象，但在很多时候消除副本或检测副本都困难这样使得程序结构不清晰。

领域模式：在整个过程中不是由一个过程来完成某一业务逻辑，而是在过程中产生若干对象由每个对象都承担一部分相关逻辑。

表模块：它与领域模式类似。关键区别在与领域模式对数据表中的每条记录有一个相应的实例而表模式只要一个综合实例。它是事务脚本与领域模式的一个中间者，它围绕表而非直接围绕过程组织领域逻辑，提供更多的结构、而且更容易发现冗余代码。它最大的优点就是与软件架构中已有的部分衔接。