Design Patterns

定义 工厂模式可分为三类： 简单工厂模式 工厂方法模式 抽象工厂模式 简单工厂模式 属于创建型模式，不属于 23 种 GOF 设计模式之一，由一个工厂对象决定创建出哪一种产品类实例，逻辑为定义一个工厂类，根据传入的参数不同返回不同的产品实例，被创建的实例具有共同的父类或接口。 工厂方法模式 跟简单工厂模式的区别就是，定义了一些工厂子类，每个工厂子类都可以创建相对应的产品类实例，而不用工厂父类去根据参数创建，一般在产品类比较多的情况下，不想太多复杂的逻辑封装在工厂父类里面，可以用这种模式。 抽象工厂模式 顾名思义，把工厂抽象出来，根据具体的业务需求组合工厂创建产品实例的逻辑，通常为创建多个产品实例类。抽象工厂一旦要增加创建产品实例的逻辑，就需要修改抽象工厂接口的具体产品组合逻辑，所以并不符合开闭原则，如果是需要频繁增加（修改）产品实例的话，要衡量是否采用这种模式 基本结构 工厂模式从源码上总的来说可以分为 4 部分： 抽象产品： 通过声明接口（特性），定义了产品的业务方法。 具体产品： 通过 implement 接口（特性），定义了业务方法的具体逻辑。 抽象工厂： 按照相应的业务逻辑，声明了创建产品对象的业务方法（多数为组合方式）。 具体工厂： 通过 implement 接口（特性），定义了创建产品对象的具体逻辑。 结构设计的关键点： 产品只负责产品对象的创建，其他什么都不关心，

思考题 有如下类设计： 如果牛奶的价钱上扬，怎么办？新增一种焦糖调料风味时，怎么办？ 造成这种维护上的困难，违反了我们之前提过的哪种设计原则？ P82 取出并封装变化的部分，让其他部分不收影响 多用组合，少用继承 思考题 请为下面类的 cost() 方法书写代码。 P83 抽象类：Beverage public class Beverage { public double cost() { double totalCost = 0.0; if (hasMilk()) { totalCost += milkCost; } if (hasSoy()) { totalCost += soyCost; } if (hasMocha()) { totalCost += mochaCost; } if (hasWhip()) { totalCost += whipCost; } return totalCost; } } 具体类：DarkRoast public class DarkRoast extends Beverage { public DarkRoast() { description = "Most Excellent Dark Roast"; } public double cost() { return baseCost + super.cost(); } } 思考题

本文源码见： https://github.com/get-set/get-designpatterns/tree/master/mediator 调停者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性的。这种模式提供了一个调停者类，用来充当“中心化”或“总线化”的角色，与各个对象通信，从而避免了其他对象之间的互相通信，从而降低了耦合度。 例子 生活中，调停者模式的例子是相当常见的，比如： 一个是讲到调停者模式就避不开的关于同事之间沟通的例子。当我们身处一个大的团队中的时候，如果工作内容涉及许多同事，那么再互相沟通显然成本比较高。比如张三要结婚请婚假，手中的工作要暂时交接给李四、王五等五六个同事，分别跟他们单独沟通多麻烦，那么直接告知组长或经理就好了，由组长或经理协调一下工作给其他同事即可； 你可能会说，沟通软件拉个群通知一下不行吗，当然可以，那这个时候，这个群就相当于一个“调停者”，任何人发送的消息都汇总到群里，其他群会员都可以收到消息。 《Java与模式》中提到了关于WTO这种国际组织的例子，如果各个国家之间互相贸易，则互相耦合，结构复杂，如果都通过一个统一的贸易组织WTO来协调，则更加简单高效。下边两个图也是书中的，方便理解： 没有中心化的贸易组织时，各个国家直接互相耦合，为网状结构。 有了中心化的贸易组织后，各个国家不直接沟通，统一与WTO耦合

开篇 【java设计模式】-01设计模式简介 创建型模式： 【java设计模式】-02工厂模式（Factory Pattern） 【java设计模式】-03抽象工厂模式（Abstract Factory Pattern） 【java设计模式】-04单例模式（Singleton Pattern） 【java设计模式】-05建造者模式（Builder Pattern） 【java设计模式】-06原型模式（Prototype Pattern） 结构型模式： 【java设计模式】-07适配器模式（Adapter Pattern） 【java设计模式】-08桥接模式（Bridge Pattern） 【java设计模式】-09组合模式（Composite Pattern） 【java设计模式】-10装饰器模式（Decorator Pattern） 【java设计模式】-11外观模式（Facade Pattern） 【java设计模式】-12享元模式（Flyweight Pattern） 【java设计模式】-13代理模式（Proxy Pattern） 行为型模式： 【java设计模式】-14责任链模式（Chain of Responsibility Pattern） 【java设计模式】-15命令模式（Command Pattern） 【java设计模式】-16解释器模式

This page provides an overview of Pod , the smallest deployable object in the Kubernetes object model. Pod是Kubernetes 对象模型中最小的可部署对象。 Understanding Pods A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. A Pod represents a running process on your cluster. A Pod encapsulates an application container (or, in some cases, multiple containers), storage resources, a unique network IP, and options that govern how the container(s) should run. A Pod represents a unit of deployment: a single instance of an application

问题： When looking beyond the RAD (drag-drop and configure) way of building user interfaces that many tools encourage you are likely to come across three design patterns called Model-View-Controller , Model-View-Presenter and Model-View-ViewModel . 当超越 RAD （拖放和配置）构建用户界面的方式时，许多工具鼓励您使用三种设计模式，分别称为 Model-View-Controller ， Model-View-Presenter 和 Model-View-ViewModel 。 My question has three parts to it: 我的问题包括三个部分： What issues do these patterns address? 这些模式解决了哪些问题？ How are they similar? 它们有何相似之处？ How are they different? 它们有何不同？ 解决方案： 参考一： https://stackoom.com/question/XA/MVP和MVC有什么区别 参考二： https:/

问题： When looking beyond the RAD (drag-drop and configure) way of building user interfaces that many tools encourage you are likely to come across three design patterns called Model-View-Controller , Model-View-Presenter and Model-View-ViewModel . 当超越 RAD （拖放和配置）构建用户界面的方式时，许多工具鼓励您使用三种设计模式，分别称为 Model-View-Controller ， Model-View-Presenter 和 Model-View-ViewModel 。 My question has three parts to it: 我的问题包括三个部分： What issues do these patterns address? 这些模式解决了哪些问题？ How are they similar? 它们有何相似之处？ How are they different? 它们有何不同？ 解决方案： 参考一： https://stackoom.com/question/XA/MVP和MVC有什么区别 参考二： https:/

作者 | 张建飞 阿里巴巴高级技术专家 导读 ：针对业务在不同场景下的差异，我们常常会习惯性地使用 if-else 来实现不同的业务逻辑，久而久之代码越来越难以维护。那么如何消除这些 if-else？面对复杂业务应如何思考和分析？本文分享阿里高级技术专家张建飞（Frank）关于复杂业务治理的方法论，介绍一种多维度分析问题的方法：矩阵分析法。 You should not be a if-else coder, should be a complexity conquer. ——Frank 这篇文章，是对之前我在 《阿里高级技术专家方法论：如何写复杂业务代码？》 说的“自上而下的结构化分解 + 自下而上的抽象建模”方法论的升级。因为在之前的方法论中，我们缺少一个多维度看问题的视角，这种维度思维的缺失，可能会导致 miss 掉一些重要的业务信息，从而使我们制定软件设计策略的时候，陷入困难。 有了维度思维，我们便可以更加方面的去看清业务的全貌，更加全面的掌握业务信息，从而帮助我们更加体系化的去治理复杂性。 从 if-else 说起 我经常说，我们不要做一个 if-else coder。这里的 if-else，不是说我们在 coding 的时候不能使用 if-else，而是说我们不应该简陋地用 if-else 去实现业务的分支流程，因为这样随意的代码堆砌很容易堆出一座座“屎山”。

数据结果的物理结构，只有数组和链表，其它都是逻辑结构 链表：一块内存中有一部分是真实数据，一部分是指向下一个内存地址，如此循环成链表 数组 VS 链表 插入（中间）：链表 添加（尾部）：链表（因为数组刚好达到容器的上限时，需要扩展比较浪费时间） 删除： 链表 随机访问：数组 扩展： 链表 Iterator 内部实现 有一个Iterator接口，里面有两个方法一个，每个容器去实现Iterator，然后内部自己去遍历自己的值，如下图 接口： 接口调用： iterator 图形结构 /designPatterns/src/com/feiyu/Iterator /v5 来源： oschina 链接： https://my.oschina.net/u/3616084/blog/4455255

一个软件系统中往往包含了很多的类，这些类之间会存在互相的调用，随着系统的升级、功能的扩展，这些相互调用关系会变得非常复杂，，大量的相互连接使得这样一个类型系统不太可能在没有其他类支持的情况下独立完成工作，久而久之这些类将变得像一个不可分割的整体，内部有着错综复杂的关联。这会导致后期维护特别困难，对系统或模块的任何较大的变动都可能造成无法预知的问题。 中介者模式 中介者模式可以解决这种问题。它通过提供一个中介类，来处理不同类之间的通信，这样可以降低多个类之间的通信复杂度，使代码更易于维护。中介者模式属于行为型模式。通过应用Mediator模式，可以将类与类之间的多对多的关系转化成一对多的关系，从而降低了类之间的耦合。 GOF对中介者模式描述为： Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.. — Design Patterns : Elements of Reusable Object-Oriented