idealism_xxm的专栏

模式是在某情境（context）下，针对某问题的某种解决方案。 P579情景：应用某个模式的情况问题：你想在某情境下达到的目标，但也可以是某情境下的约束解决方案：一个通用的设计，用来解决约束、达到目标模式必须应用于一个重复出现的问题。 P581思考题配对下列模式和描述： P587装饰器模式：包装一个对象，以提供新的行为状态模式：封装了基于状态的行为，并使用委托在行为之间切换迭代器模式：在对象的集合之中游走，而不暴露集合的实现外观模式：简化一群类的接口策略模式：封装可以互换的行为

复合模式在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题。 P500思考题public interface Quackable { public void quack();}public class MallardDuck implements Quackable { public void quack() { System.out.println("Quack"); }}public class Goose { public

思考题如何设计一个支持远程方法调用的系统？你要怎样才能让开发人员不用写太多代码？让远程调用看起来像本地调用一样，毫无瑕疵？ P435已经接触过 RPC 了，所以就很容易知道具体流程：客户端调用目标类的代理对象（消费者）的方法，消费者内部将相关调用信息通过网络传到服务端对应的目标类的代理对象（生产者）中，生产者解析调用信息，然后真正去调用目标类的实际对象，并将返回结果回传给消费者，消费者再返回给客户端。 RPC 框架使用代理模式使得内部一系列处理及信息传输等对客户端和服务端是透明的，客户端会认为实际是本

思考题public class GumballMachine { final static int SOLD_OUT = 0; final static int NO_QUARTER = 1; final static int HAS_QUARTER = 2; final static SOLD = 3; int state = SOLD_OUT; int count = 0; public GumballMachine(int

思考题我们不仅仅要支持多个菜单，升值还要支持菜单中的菜单。你如何处理这个新的设计需求？ P355【提示】在我们的新设计中，真正需要以下三点： P354我们需要某种属性结构，可以容纳菜单、子菜单和菜单项我们需要确定能够在每个菜单的各个项之间游走，而且至少要像现在用迭代器一样方便我们也需要能够更有弹性地在菜单项之间游走。比方说，可能只需要遍历甜点菜单，或者可以遍历餐厅的整个菜单（包括甜点菜单在内）提供一个接口，统一菜单和菜单项的超类接口包含菜单和菜单项的共同方法，菜单中执行方法是依次执行

思考题public void printMenu() { PancakeHouseMenu pancakeHouseMenu = new PancakeHouseMenu(); ArrayList breakfastItems = pancakeHouseMenu.getMenuItems(); DinerMenu dinerMenu = new DinerMenu(); MenuItem[] lunchItems = dinerMenu.getMenuItems

模板方法模式在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。 P289特点主导算法框架，并且保护这个算法 P288最大化复用代码 P288算法只存在于一个地方，容易修改 P288专注算法本身，由子类提供完整的实现 P288模板方法本身和内部具体操作解耦 P289设计原则好莱坞原则：低层组件别调用高层组件，让高层组件调用低层组件。 P296优点防止依赖腐败（依赖腐败会使用户难以弄懂系统的设计） P2

思考题想想看，你在 JavaAPI 中遇到过哪些外观，你还希望 Java 能够新增哪些外观？ P262println、log 日志接口、JDBC 接口突然让想感觉想不出来，各种 API 都用得挺顺的，没有太麻烦的使用外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。 P264特点提供简化的接口的同时，依然将系统完整的功能暴露出来 P260将客户从组件的子系统中解耦 P260意图是提供子系统的一个简化接口 P260区别 P270

思考题你能想到真实世界中，还有哪些适配器的例子？ P236HDMI 转 VGA 转换器Type-C 转 3.5mm 线适配器模式解析客户使用适配器的过程： P241客户通过目标接口调用适配器的方法对适配器发出请求适配器使用被适配者接口把请求转换成被适配者的一个或多个调用接口客户接收到调用的结果，但并未察觉这一切是适配器在起转换作用（客户和被适配者是解耦的，一个不知道另一个）思考题如果我们也需要一个将鸭子转换成火鸡的适配器，我们称它为 DuckAdapter。请写下这个类。你如何处

命令模式将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。 P206特点使请求调用者和请求接收者解耦 P207适合用来建立有弹性的设计，维持开闭原则 （同装饰器模式 P104）使用宏命令可以一次执行其他一系列命令 P225缺点存大量具体的命令类思考题命令模式的设计如何支持请求调用者和请求接收者之间的解耦？ P207通过将请求接受者封装进一个命令对象，并将请求接收者的一系列动作封装成一个命令对象的方法，使得请求调用者只用持有命令

全局变量的缺点如果将对象赋值给一个全局变量，那么必须在程序一开始就创建好对象 P170和 JVM 实现有关，有些 JVM 的实现是：在用到的时候才创建对象思考题Choc-O-Holic 公司使用如下工业强度巧克力锅炉控制器public class ChocolateBoiler { private boolean empty; private boolean boiled; public ChocolateBoiler() { empty =

思考题如何将实例化具体类的代码从应用中抽离，或者封装起来，使它们不会干扰应用的其他部分？ P111将实例化具体类的代码放入一个对象中管理，通过不同入参决定实例化具体的类简单工厂不是23种GOF设计模式之一，而更像一种编程习惯。 P117[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zHM6pdNX-1610024779349)(https://github.com/idealism-xxm/reading-notes/raw/master/head-first-

装饰器（Decorator）模式思考题思考题思考题设计原则装饰器模式特点缺点思考题所思所想思考题有如下类设计：如果牛奶的价钱上扬，怎么办？新增一种焦糖调料风味时，怎么办？造成这种维护上的困难，违反了我们之前提过的哪种设计原则？ P82取出并封装变化的部分，让其他部分不收影响多用组合，少用继承思考题请为下面类的 cost() 方法书写代码。 P83抽象类：Beverage...

观察者（Observer）模式思考题观察者模式设计原则所思所想思考题在我们的一个实现中，下列哪种说法正确？（多选） P42public class WeatherDate { // 实例变量声明 public void measurementsChanged() { float temp = getTemperature(); flo...

策略（Strategy ）模式思考题使用接口方式的优缺点 `P6`优点缺点思考题设计原则设计原则“针对接口编程”即“针对超类型 (supertype) 编程” `P12`设计原则策略模式良好的OO设计具备的特性 `P32`所思所想当涉及到“维护”时，为了“复用”目的而使用继承，结局并不完美 P4对父类代码进行修改时，影响层面可能会很大思考题利用继承来提供 Duck 的行为，这回导...

《Head First 设计模式》- 00. 引子Head First 学习原则 `P xxx`学习方法 `P xxxiii`Head First 学习原则 P xxx可视化：图片使得学习效率更高，更易懂交谈式：第一人称交谈方式讲述学习内容更易引起注意多思考：自主思考练习题和拓展知识的问题保持注意力集中：将知识融合进有趣、亮眼的内容中，不断引起并保持注意力影响情绪：关心、好奇、有趣、...