- DesignPattern
- 分类
- Apr 4, 2018
设计模式小记&重温数据结构
前几篇将使用工作中到的设计模式进行一些归纳，设计模式只是一些套路、招式，可以用来简化代码，提高代码阅读性； 提高代码的阅读性这一点 对于编写代码的人一开始可能会有异议，感觉有时候用了设计模式反而把代码变得更复杂，频繁的使用继承、实现、多态，可能让人懵逼。 对于查看代码的人来说，使用了设计模式的代码，结构更清晰，更方便别人和自己后期的修改 在使用上，不需要强行硬套模式，一般都是先实现了功能，然后发现哪个地方有可以改进的地方，尝试着使用模式简化提炼一下，时间久了应该就能写出好看的代码了，至少我是这样鼓励自己的…… 下一步，准备将之前看的Python版数据结再复习一遍；用Java和c实现数据结构比较麻烦，国外现在数据结构这门课都用Python来讲解，附上一本好书的在线连接《Problem Solving with Algorithms and Data Structures using Python》
Read More - Apr 4, 2018
设计模式——单例模式中的DCL运用
单例模式如果说最常用到的，应该就是枚举吧，枚举中的构造器即是单例，并且枚举的每个实例在实现上都是静态的； 或者手写单例，通过静态内部类或者双检索； 双检索 双检索实现的单例，主要是因为该实现方式是基于懒汉式，而懒汉又有线程安全问题，比如以下场景：某次活动发放了数张邀请码，每个邀请码只能用一次，在竞态环境下如何保证该邀请码只能被使用一次 package com.git.toolbox.util; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; /** * Created by poan on 2017/11/03. */ class InviteCode { /** * 1 已经使用 0...
Read More - Apr 3, 2018
设计模式——代理模式与装饰者的关系
基于包装者的代理 代理模式，实际上和前一篇的装饰者模式有些相似，实际上都是对既有方法的一些扩展；对于如果实现，两者也是类似的： 将被代理（被装饰）的类，作为代理类（装饰类）的构造器参数 在构造器中将被代理（被装饰）的类初始化 由代理类的方法对被代理类做扩展 package com.git.poan; /** * Created by poan on 2018/04/03. */ public class ProxyTest { public static void main(String[] args) { Clerk clerk = new Clerk(new...
Read More - Apr 3, 2018
设计模式——装饰者模式IO流
装饰者模式…… 一般来说，基于被装饰的类增加一些扩展，最常见的就是Java中IO流的Api了 DataInputStream dataInputStream = new DataInputStream(new FileInputStream(new File("text.txt"))); 装饰者和代理模式有那么丢丢的类似，所以这里提一下；实现上只要在装饰类的构造器上指定被包装的类，并初始化就ok了。
Read More - Apr 2, 2018
设计模式——观察者模式&朋友圈女神
非竞态下的观察者 如果某个类中的一个状态经常会变化，并且每次变化都需要一些类对其做特殊的处理，就可以用状态模式； 《Head Fisrt》里面和各个论坛都喜欢用天气预报板块举例，个人不太理解那个场景； 这里用朋友圈的女神举例：女神自然有一堆关注者，每次她的状态一更新，其跟随者各种大开脑洞为博女神眼球。这里使用观察者模式实现； package com.git.poan.designparttern; import java.util.ArrayList; import java.util.List; import java.util.Random; // 1. 将女神的状态发布抽象为接口 interface GoddessFollower { void post(PostType type); } // 2. 将女神的状态类型使用枚举列举处理 enum PostType { Image(1,...
Read More - Apr 2, 2018
设计模式——策略模式与service接口
对于web项目来说，service或business层（业务逻辑层），规范来说一般都会先书写接口，再写实现，只不过对于一般的CRUD功能的service层来说，service接口一般都只有单实现； 实际上，就算是单实现，也是属于“策略模式了”； 稍微复杂一些的service接口，底下可能会有几个service实现类，比如以下场景： 一个支付功能——PayBusiness接口，有几种支付方法：微信支付，支付宝支付，银行卡支付；对应了三个支付实现类wechatPayBusiness、aliPayBusiness、unionPayBusiness；根据用户选择的支付类型，调用对应的支付实现类； 所以就算service/business层底下只有一个实现，也还是别省去接口这一步，也算是策略模式了~ 只不过是单一策略而已；复杂业务下面如果有多个实现类，就是多策略咯
Read More - Apr 2, 2018
设计模式——责任链模式使用枚举实现
责任链模式，用于对用一个资源，链式处理的场景，比如Logger的log()方法，Filter的doFilter()方法； 责任链的运用不是很复杂，相对于以注册的方式指定链中的下一个处理对象，这里主要记录一种用枚举实现责任链的方式 package com.git.poan.designparttern; /** * Created by poan on 2018/04/02. */ public enum ResponsibilityChain { FIRST { @Override public void dose() { System.out.println("我要说，123456789； 然后接下来有请下一位"); } }, SECOND { @Override...
Read More - Apr 1, 2018
享元模式与Integer的valueOf方法
在Patterns网站上，举出了一个运用享元模式的栗子，自己试了一遍感觉还是比较陌生，还好它有列举哪些地方也使用了享元模式，比如Integer的valueOf()方法； Integer的valueOf(int i)方法，会判断传入的i是否在指定的范围内： public static Integer valueOf(int i) { if (i >= IntegerCache.low && i <= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); } 这里的low和high是-128和127（high在跟踪源码中可以看到可以通过java.lang.Integer.IntegerCache.high设置的值获取） IntegerCache是个静态内部类，会在该类中，为-128～127的int值创建好对应的封装类型； private static class...
Read More - Apr 1, 2018
设计模式——适配器模式与大黄蜂
适配器模式的使用场景，举个栗子就是，大黄蜂的声带坏了，每次都去找其他能发音的喇叭代替；虽然发出的声音有点怪，总归能发声了～ 在Java中如何实现呢，比如现在有一声卡，只能发出女人的声音；而大黄蜂这个类，想带上这个声卡从而说话，如何实现？ 将WomenSoundCard的speak()方法，抽象到SoundCard接口的speak中 WomenSoundCard实现SoundCard接口 BigBee的属性中，设置一个SoundCard的属性，并赋值为WomenSoundCard的类型，并且实现SoundCard接口，然后实现speak方法，在speak方法中，只需要调用SoundCard属性的speak方法即可； 实现以上三部，大黄蜂就能发出女人的声音了～ package com.git.poan.designparttern; class WomenSoundCard implements SoundCard { @Override public void speak() { System.out.println("婴婴婴～"); } } interface SoundCard { void speak(); } public class BigBee...
Read More - Apr 1, 2018
设计模式——Monad模式与参数校验
monad模式不是四人帮的设计模式之一，在Pattern中有介绍， 适用于线性代码执行上，比如在web项目中，通常会在controller层校验参数的合法性；通常的写法是： if (Objects.requireNoneNul(param1)){ throw new CommonException(50001,"err"); } if(StringUtils.isNotEmpty(param2)) { // ... throw new CommonException(50002,"err"); } // todo:校验其他参数 对于以上操作，在很多controller中会有重复代码，为了简化上述情况中的代码，可以使用monad模式： package com.git.toolbox.util; import com.git.toolbox.exception.CommonException; import org.apache.commons.lang3.StringUtils; import java.io.Serializable; import java.util.ArrayList; import...
Read More - Apr 1, 2018
设计模式——建造者模式
这个模式比较简单，基于包装模式之上，使用连缀方式，创建常用类的实例。 具体栗子，引用自https://github.com/ihaolin/wepay项目。 下面是一个用户建造者的栗子： /** * Created by poan on 2017/11/23. * <p> * 用户构建器，实际上是包装模式， * 使用连缀的方式设置用户的属性 */ public class UserBuilder { private User user; public static UserBuilder BUILDER() { User...
Read More - Mar 31, 2018
设计模式——模版方法个人总结
使用场景：IDEA中提示这一段代码重复出现了很多次，而这些代码中间有少部分的代码是与各自业务有关，这部分与业务有关的代码夹杂在一堆重复代码中；例如： 模版方法 public class A{ public void aMethod(){ // dosomething 1 // todo：A类业务的代码 // dosomething 2 } } public class B{ public void bMethod(){ // dosomething 1 // todo：B类业务的代码 //...
Read More