好久没更新文章了，虽然没人催更，但还是想要捡起来。有些事就像怀孕，时间久了，才能看到结果。
本篇文章主要是向各位读者介绍设计模式在实际工程中的应用。笔者也是设计模式的获益者之一。不得不感叹，真是前人栽树后人乘凉，香！
这是一个丰收季节，希望你不要不开心了工厂模式和策略模式相信有过开发经验的人一定都听说过，这两种设计模式我个人认为也是比较贴近实际开发的，所以大家有必要掌握，并且有机会的话一定要用在实际的工程中。
笔者在展示实际的应用场景和应用代码之前，先带大家过以下这两种模式。首先是工厂模式，顾名思义，应该是从我们日常生活中的工厂得到的启发。在日常生活中，大家购买商品的时候一般不会去了解商品是如何被制造出来的，因为商品的制造涉及多个环节，比较复杂。但人们又需要这件商品，怎办？简单，只需要告诉有能力制作的工厂帮忙制作就好了。工厂模式也是同样的道理。那么我们平时写的较多的java应用中，有哪些是需要经常使用的呢？没错，就是各种各样的java对象，正是有了这些对象，才使得应用可以真正的对外提供服务，产生价值。像大家熟知的spring框架，其内部就可以看成是一个专门用来生产各种对象的大工厂，而作为甲方的我们只需要告诉spring需要怎样的对象即可，并不需要实际参与到对象的创建过程中。
谁说只有开头值得铭记，结尾也一样关于策略模式，笔者认为只用一句话就可以概括：见人说人话，见鬼说鬼话。说白了，就是在不同的场景下用不同的策略解决问题。
简单介绍完了两种模式后，笔者会用一个实际的生产案例帮助大家加深对这两种模式的理解。案例的背景就是需要对用户上传的文件进行校验，但是不同类型的文件对应的校验策略是不一样的。本案例所采用的框架是springboot。如果没有使用任何设计模式的情况下，写的代码可能是下面这种：
低质量程序员写出的代码上面的代码有优点也有缺点，优点就是足够简单，缺点就不罗列，不然又是一大段。如果学了工厂+策略的设计模式，上面的代码完全可以写的像诗一样。
首先定义一个专门用于负责校验的接口，在接口中定义相应的校验策略，以后所有文件的校验策略都要实现该接口，这个接口就是校验策略的总接口：
用接口来规范具体的校验策略类根据具体的业务需求实现校验策略接口，并实现里面的抽象方法。大家可能注意到了下面的接口实现类中标注了Component注解，并且还定义了这个bean在spring容器中的名称，大家可以先思考一下为什么要这么做，后面会为大家做出解答。
实现接口，完成具体的校验逻辑定义好了接口，并且写好了具体的校验逻辑，那接下来就是放心大胆的使用了，但如何使用是门学问，是一个程序员内功的体现。有两种方式，一种是一个月拿8k的程序员写出来的，而另一种则是拿10k的程序员写出来的：
8k程序员写的10k程序员写的对比上面的两种写法，大家应该明白了为什么要在类上标注Component注解了吧，其实就是为了省掉那一大段的ifelse代码块。我们需要什么样的校验策略，直接告诉spring容器，让它给我们返回就好了，至于这个类是如何返回的，作为甲方的我们需要关心吗？这不就是工厂模式的应用吗？用户上传什么类型的文件，就用什么样的校验策略，不就是策略模式的应用吗？
这样的夜，除了想你，无事可做代码和诗本来是两个世界的，但设计模式却让它们相遇了。这也是只有维护你代码的人才能读懂的浪漫。