xinlingmen的专栏

内部结构图栈帧示意图存储信息每个栈帧中存储着：局部变量表（Local Variables） 操作数栈（Operand Stack）（或表达式栈） 动态链接（Dynamic Linking）（或指向常量池的方法引用） 方法返回地址（Return Address）（或方法正常返回和异常返回的定义） 一些附加信息...

执行顺序静态代码块>构造代码块>构造方法静态代码块1、静态代码块是随着类的加载而加载；2、执行一次，优先于主函数；3、静态代码块是和类一起的，优先级最高，类加载的同时，静态代码块同时也执行，但只执行一次，所以作用一般是用来加载一些配置代码，或者加载某些文件配置。代码示例如图静态方法，在main方法之前执行，证明了静态代码优先于主函数执行。构造代码块构造代码块的作用同样是给对象进行初始化。对象一建立就运行构造代码块了，而且优先于构造函数执行。这里要强调一

常量池对于String常量，它的值是在常量池中的。而JVM中的常量池在内存当中是以表的形式存在的， 对于String类型，有一张固定长度的CONSTANT_String_info表用来存储文字字符串值，注意：该表只存储文字字符串值，不存储符号引用。说到这里，对常量池中的字符串值的存储位置应该有一个比较明了的理解了。在程序执行的时候,常量池会储存在Method Area,而不是堆中。常量池中保存着很多String对象; 并且可以被共享使用，因此它提高了效率使用String不一定创建对象举例

栈中的数据栈中有基本类型和对象句柄，基本类型又叫值类型，对象句柄又叫引用类型；java中的方法值中传值时，就有了值传递和引用传递。基本类型Java中有8中基本类型，int, short, long, byte, float, double, boolean, char；引用类型比如：Object o=new Object();o就是引用类型，o是一个指针，指向堆中的变量。代码分析值传递打印结果内存模型1、main方法中变量a的初始值是123，没有发

问题引入OA系统采购审批需求 学校OA系统的采购审批项目：需求是 1) 采购员采购教学器材 2) 如果金额 小于等于5000, 由教学主任审批 （0<=x<=5000） 3) 如果金额 小于等于10000, 由院长审批 (5000<x<=10000) 4) 如果金额 小于等于30000, 由副校长审批 (10000<x<=30000) 5) 如果金额 超过30000以上，有校长审批 ( 30000<x) 请设计程序完成采购审批项目

问题引入鸭子问题编写鸭子项目，具体要求如下: 1) 有各种鸭子(比如 野鸭、北京鸭、水鸭等， 鸭子有各种行为，比如 叫、飞行等) 2) 显示鸭子的信息传统方案问题分析1) 其它鸭子，都继承了Duck类，所以fly让所有子类都会飞了，这是不正确的 2) 上面说的1 的问题，其实是继承带来的问题：对类的局部改动，尤其超类的局部改 动，会影响其他部分。会有溢出效应 3) 为了改进1问题，我们可以通过覆盖fly 方法来解决 => 覆盖解决 4) 问题又.

问题引入App抽奖活动问题状态模式基本介绍1) 状态模式（State Pattern）：它主要用来解决对象在多种状态转换时，需要对外 输出不同的行为的问题。状态和行为是一一对应的，状态之间可以相互转换 2) 当一个对象的内在状态改变时，允许改变其行为，这个对象看起来像是改变了 其类原理类图对原理类图的说明-即(状态模式的角色及职责) 1) Context 类为环境角色, 用于维护State实例,这个实例定义当前状态 2) State 是抽象状态角色,.

问题引入四则运算问题 通过解释器模式来实现四则运算，如计算a+b-c的值，具体要求 1) 先输入表达式的形式，比如 a+b+c-d+e, 要求表达式的字母不能重复 2) 在分别输入a ,b, c, d, e 的值 3) 最后求出结果：如图传统方案解决四则运算问题分析 1) 编写一个方法，接收表达式的形式，然后根据用户输入的数值进行解析，得到结果 2) 问题分析：如果加入新的运算符，比如 * / ( 等等，不利于扩展，另外让一个方法来 解析会造成程序结构混乱，不

游戏角色状态恢复问题 游戏角色有攻击力和防御力，在大战Boss前保存自身的状态(攻击力和防御力)，当大 战Boss后攻击力和防御力下降，从备忘录对象恢复到大战前的状态传统的设计方案(类图) 传统的方式的问题分析 1) 一个对象，就对应一个保存对象状态的对象， 这样当我们游戏的对象很多时，不 利于管理，开销也很大. 2) 传统的方式是简单地做备份，new出另外一个对象出来，再把需要备份的数据放到 这个新对象，但这就暴露了对象内部的细节 3) 解决方案： => 备忘

智能家庭项目需求1) 智能家庭包括各种设备，闹钟、咖啡机、电视机、窗帘 等 2) 主人要看电视时，各个设备可以协同工作，自动完成看电视的准备工作，比如流 程为：闹铃响起->咖啡机开始做咖啡->窗帘自动落下->电视机开始播放传统方案类图传统的方式的问题分析1) 当各电器对象有多种状态改变时，相互之间的调用关系会比较复杂 2) 各个电器对象彼此联系，你中有我，我中有你，不利于松耦合. 3) 各个电器对象之间所传递的消息(参数)，容易混乱 4) 当系.

天气预报项目需求 天气预报项目需求,具体要求如下： 1) 气象站可以将每天测量到的温度，湿度，气压等等以公告的形式发布出去(比如 发布到自己的网站或第三方)。 2) 需要设计开放型API，便于其他第三方也能接入气象站获取数据。 3) 提供温度、气压和湿度的接口 4) 测量数据更新时，要能实时的通知给第三方普通方案问题分析1) 其他第三方接入气象站获取数据的问题 2) 无法在运行时动态的添加第三方 (新浪网站) 3) 违反ocp原则=>观察者模式.

看一个具体的需求编写程序展示一个学校院系结构：需求是这样，要在一个页面中展示出学校的院系 组成，一个学校有多个学院，一个学院有多个系。如图：传统的设计方案传统的方式的问题分析1) 将学院看做是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分 层次的 2) 实际上我们的要求是 ：在一个页面中展示出学校的院系组成，一个学校有多个 学院，一个学院有多个系， 因此这种方案，不能很好实现的遍历的操作 3) 解决方案：=> 迭代器模式迭代器模式.

测评系统的需求 传统方式的问题分析 1) 如果系统比较小，还是ok的，但是考虑系统增加越来越多新的功能时，对代码改 动较大，违反了ocp原则， 不利于维护 2) 扩展性不好，比如 增加了 新的人员类型，或者管理方法，都不好做 3) 引出我们会使用新的设计模式 – 访问者模式访问者模式基本介绍1) 访问者模式（Visitor Pattern），封装一些作用于某种数据结构的各元素的操作， 它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。 2) 主要将.

智能生活项目需求1) 我们买了一套智能家电，有照明灯、风扇、冰箱、洗衣机，我们只要在手机上安装app就 可以控制对这些家电工作。 2) 这些智能家电来自不同的厂家，我们不想针对每一种家电都安装一个App，分别控制，我 们希望只要一个app就可以控制全部智能家电。 3) 要实现一个app控制所有智能家电的需要，则每个智能家电厂家都要提供一个统一的接口 给app调用，这时 就可以考虑使用命令模式。 4) 命令模式可将“动作的请求者”从“动作的执行者”对象中解耦出来. 5) 在我们

豆浆制作问题编写制作豆浆的程序，说明如下: 1) 制作豆浆的流程 选材--->添加配料--->浸泡--->放到豆浆机打碎 2) 通过添加不同的配料，可以制作出不同口味的豆浆 3) 选材、浸泡和放到豆浆机打碎这几个步骤对于制作每种口味的豆浆都是一样的模板方法模式基本介绍 1) 模板方法模式（Template Method Pattern），又叫模板模式(Template Pattern)，z 在一个抽象类公开定义了执行它的方法的模板。它的子类可以按需要重.

代理模式的基本介绍 1) 代理模式：为一个对象提供一个替身，以控制对这个对象的访问。即通过代理 对象访问目标对象.这样做的好处是:可以在目标对象实现的基础上,增强额外的 功能操作,即扩展目标对象的功能。 2) 被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象 3) 代理模式有不同的形式, 主要有三种 静态代理、动态代理 (JDK代理、接口代 理)和 Cglib代理 (可以在内存动态的创建对象，而不需要实现接口， 他是属于 动态代理的范畴) 。 静态代码模式的

网站项目需求小型的外包项目，给客户A做一个产品展示网站，客户A的朋友感觉效果不错，也希 望做这样的产品展示网站，但是要求都有些不同： 1) 有客户要求以新闻的形式发布 2) 有客户人要求以博客的形式发布 3) 有客户希望以微信公众号的形式发布传统方案解决网站展现项目传统方案解决网站展现项目-问题分析1) 需要的网站结构相似度很高，而且都不是高访问量网站，如果分成多个虚拟空间来 处理，相当于一个相同网站的实例对象很多，造成服务器的资源浪费 2) 解决思路：整合.

影院管理项目组建一个家庭影院： DVD播放器、投影仪、自动屏幕、环绕立体声、爆米花机,要求完成使用家庭影院的 功能，其过程为： • 直接用遥控器：统筹各设备开关 • 开爆米花机 • 放下屏幕 • 开投影仪 • 开音响 • 开DVD，选dvd • 去拿爆米花 • 调暗灯光 • 播放 • 观影结束后，关闭各种设备传统方式解决影院管理传统方式解决影院管理问题分析1) 在ClientTest 的main方法中，创建各个子系统的对象，并直接去调用子系

学校院系展示需求 传统方案解决学校院系展示(类图) 传统方案解决学校院系展示存在的问题分析 1) 将学院看做是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分 层次的 2) 实际上我们的要求是 ：在一个页面中展示出学校的院系组成，一个学校有多个 学院，一个学院有多个系， 因此这种方案，不能很好实现的管理的操作，比如 对学院、系的添加，删除，遍历等 3) 解决方案：把学校、院、系都看做是组织结构，他们之间没有继承的关系，而是 一个树形结构，可以更好的

星巴克咖啡订单项目（咖啡馆）：1) 咖啡种类/单品咖啡：Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式 咖啡)、Decaf(无因咖啡) 2) 调料：Milk、Soy(豆浆)、Chocolate 3) 要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便 4) 使用OO的来计算不同种类咖啡的费用: 客户可以点单品咖啡，也可以单品咖 啡+调料组合。方案1-解决星巴克咖啡订单项目方案一问题分析1) Drink 是一个抽象类，表示饮

手机操作问题传统方案解决手机操作问题 传统方案解决手机操作问题分析 1) 扩展性问题(类爆炸)，如果我们再增加手机的样式(旋转式)，就需要增加各个品 牌手机的类，同样如果我们增加一个手机品牌，也要在各个手机样式类下增加。 2) 违反了单一职责原则，当我们增加手机样式时，要同时增加所有品牌的手机，这 样增加了代码维护成本. 3) 解决方案-使用桥接模式基本介绍1) 桥接模式(Bridge模式)是指：将实现与抽象放在两个不同的类层次中，使两个层 次可以独立改变。

基本介绍1) 适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表 示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同 工作。其别名为包装器(Wrapper) 2) 适配器模式属于结构型模式 3) 主要分为三类：类适配器模式、对象适配器模式、接口适配器模式工作原理1) 适配器模式：将一个类的接口转换成另一种接口.让原本接口不兼容的类可以兼 容 2) 从用户的角度看不到被适配者，是解耦的 3) 用户调用适配器转化出来

建造者模式盖房项目需求1) 需要建房子：这一过程为打桩、砌墙、封顶 2) 房子有各种各样的，比如普通房，高楼，别墅，各种房子的过程虽然一样，但是 要求不要相同的. 3) 请编写程序，完成需求.传统方式解决盖房需求问题分析1) 优点是比较好理解，简单易操作。 2) 设计的程序结构，过于简单，没有设计缓存层对象，程序的扩展和维护不好. 也就 是说，这种设计方案，把产品(即：房子) 和 创建产品的过程(即：建房子流程) 封 装在一起，耦合性增强了。 3) 解决方案：将产

原型模式克隆羊问题现在有一只羊tom，姓名为: tom, 年龄为：1，颜色为：白色，请编写程序创建和tom 羊 属性完全相同的10只羊。传统解决方式代码：// TODO Auto-generated method stub//传统的方法Sheep sheep = new Sheep("tom", 1, "白色");Sheep sheep2 = new Sheep(sh...

抽象工厂模式需求披萨项目新的需求：客户在点披萨时，可以点不同口味的披萨，比如 北京的奶酪pizza、 北京的胡椒pizza 或者是伦敦的奶酪pizza、伦敦的胡椒pizza。 传统模式思路使用简单工厂模式，创建不同的简单工厂类，比如BJPizzaSimpleFactory、 LDPizzaSimpleFactory 等等.从当前这个案例来说，也是可以的，但是考虑到项目的 ...

简单工厂模式一个需求看一个披萨的项目：要便于披萨种类的扩展，要便于维护 1) 披萨的种类很多(比如 GreekPizz、CheesePizz 等) 2) 披萨的制作有 prepare，bake, cut, box 3) 完成披萨店订购功能。传统方式类图：分析：定义一个抽象类披萨，奶酪披萨、芝士披萨都继承披萨类；订购披萨的客户端有很多，不同的客户端都能完成相应...

单例设计模式基本介绍所谓类的单例设计模式，就是采取一定的方法保证在整个的软件系统中，对某个类 只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法(静态方法)。 比如Hibernate的SessionFactory，它充当数据存储源的代理，并负责创建Session 对象。SessionFactory并不是轻量级的，一般情况下，一个项目通常只需要一个 SessionFa...

类之间的六大关系 有些朋友可能和我一样，写了不少的代码，很少去思考，类之间的关系有哪些呢？今天学习后一并总结分析。依赖我们说类中用到了对方，那么他们之间就存在依赖关系。举例：public class PersonServiceBean { private PersonDao personDao;//类 public void save(Person person){} ...

设计原则核心思想7大设计原则单一职责原则 接口隔离原则 依赖倒转原则 里氏替换原则 开闭原则 迪米特法则 合成复用原则核心思想找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起； 针对接口编程，而不是针对实现编程； 为了交互对象之间的松耦合设计而努力。...

迪米特法则 基本介绍1) 一个对象应该对其他对象保持最少的了解 2) 类与类关系越密切，耦合度越大 3) 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的 越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内 部。对外除了提供的public 方法，不对外泄露任何信息 4) 迪米特法则还有个更简单的定义：只与...

开闭原则基本介绍 示例

里氏替换原则继承带来的问题1) 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契 约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实 现的方法任意修改，就会对整个继承体系造成破坏。 2) 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵 入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继...

依赖倒转原则 基本介绍依赖倒转原则(Dependence Inversion Principle)是指： 1) 高层模块不应该依赖低层模块，二者都应该依赖其抽象 2) 抽象不应该依赖细节，细节应该依赖抽象 3) 依赖倒转(倒置)的中心思想是面向接口编程 4) 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的 多。以抽象为基础搭建的架构比以细节为基础...

接口隔离原则基本介绍 客户端不应该依赖它不需要的接 口，即一个类对另一个类的依赖 应该建立在最小的接口上； 如果接口不能最小，就会出现实现类要实现对自己无用的方法，代码维护性就差； 如果确实需要在接口中增加方法，就想办法拆分接口，确保接口实现的最小化； ...

单一职责原则基本介绍​​​​​​​对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。 当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为 A1，A2实现细节​​​​​​​降低类的复杂度，一个类只负责一项职责。 提高类的可读性，可维护性 降低变更引起的风险 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才...