静儿就职的是新美大的基础架构部门，做的是基于k8s的容器调度开发。k8s只是个工具，真正技术的上就是和网络打交道要多些。需要对网络中的数据流向有清晰的认识。大多数时间还是在做平台，事情很跟业务很相似，也主要是工程。
之前记得有同事说过，设计的东西都被框架封装好了，设计模式基本用不上。但是静儿怎么觉得天天在用设计模式呢？
举个栗子🌰，这不快过年了吗，近来年一过年各种运势测算就来了。记得《花千骨》热播那年有个根据姓名“测测你是《花千骨》里的谁？”。产品给了这个任务，对大多数程序员来说too easy。
先说说产品给的设计：
输入：姓名
输出：对应的人物和介绍
计算方法：模6，将姓名的ascii码值除于6。得到的对应余数输出下面答案。
0.花千骨
她是世间最后一个神，也是百年难得一见的天煞孤星，她善良而坚强执着，对待朋友真心实意。她是爱上了一个人，即使被伤的体无完肤，却依然深爱的不肯放弃的人，但并不是要这个人，只是要得到对方的认可。她有这样的执着，而你也有这样的执着，所以性格上，有一点像花千骨。
1.白子画
长留上仙白子画，是一个超凡而孤高，冰凉而淡漠，温润如玉又云淡风清的人。他本无情，却最终为花千骨操碎了心。在花千骨放出妖神闯下大祸后，毅然为她承担起大部罪责，花千骨囚禁海底，亦相伴左右16年。可是最终为了天下，辜负了爱情。你是白子画，是因为你也会选择事业，不会选择爱情。
2.杀阡陌
他是妖魔之王，掌控整个妖界。长得极为好看，很自恋，是六界最美的人。他在开始只是把花千骨当做妹妹保护，但是最后和她相处久了，便喜欢上了她。仙界之战中，曾为她杀上长留，对抗整个仙界。如果你爱上了一个人，也是会逆流而上，不会隐忍自己的感情的人哦。
3.轻水
轻水是一个很普通的女孩子，她温柔贤淑，心地善良，简直是在众仙，众妖中的一股清流。她对爱情也是比较坚持的，为了爱的人，愿意放弃成仙的机会，虽然后来也嫉妒花千骨，差点做错事，但是及时意识到自己的错，总之是一个普通的常人，却依然有自己的亮点。
4.东方彧卿
他气质出尘，肤质白皙，拥有一双月牙眼，笑起来春暖花开像只狐狸。他为人有一些风流不羁，幽默风趣，玩世不恭，为人豁达。只对花千骨万般宠爱和温柔深情，喜欢上花千骨，也愿意为她做所能做的一切。最后为心爱的人挡下一掌，粉身碎骨。为人风趣的你，对爱有牺牲精神，正似东方彧卿。
5.夏紫薰
原本是仙界的紫薰仙子，上仙之一，却因爱上白子画而成为堕仙，坠入魔道。紫薰仙子是一个很有个性的角色，她只羡慕鸳鸯不羡仙，为了爱情，并不在乎是否是仙还是妖，最后成为堕仙，进入了魔道。虽然你现实生活中不可能这么极端，但是你也是这类有个性的人，不走寻常路啊。
最简单粗暴的设计方法：在程序里switch case完工！
用设计模式的话，这里用工厂模式是比较合适的。每一个答案是一个类，定义一个方法，可以叫：requireFortuneTellingResult。
开发小哥哥抱怨说：明明这么简单一件事情，用工厂模式我多写好几个类呢。看上去也没什么好处啊。回忆一下设计模式的六大原则就可以知道设计模式解决的是维护性和扩展性的问题(也叫：写出看的懂的代码)，而不是多几个少几个复制粘贴的开发问题。这些开发成本是可以通过工具解决的。
用了工厂模式后，作为后来的开发者requireFortuneTellingResult里具体的内容可以不关心。只是主方法足以说明主题。
伪代码如下：
Map fortuneTellings = {
0:花千骨.class,
1:白子画.class,
2:杀阡陌.class,
3:轻水.class,
4:东方彧卿.class,
5:夏紫薰.class}};
String fortuneTellByName(String name) {
LOG.info("用户的姓名:{}",name)//此行伪代码相当重要，因为获取到的信息是产品的价值之一！
return fortuneTellings.get(name.val/6).requireFortuneTellingResult();
}
看，主函数一行代码足以说明整个意图。
产品上线后，传播很快。运营MM将这一报告反馈给产品，产品MM就想了：用这么一个低成本的产品获取了大票流量，我真是太聪明了！不过有个问题，就是除了名字，用户的其他信息没有获取到啊。我怎么能通过这个产品获取用户的一些个人偏好，有针对性对其进行推送呢？
于是，产品MM基于这个产品，需要在保留老产品的基础上新开发一个产品。这个产品先让用户做几个判断题，根据选择题的结果得到你是《花千骨》里的谁。设计如下：
输入：选择题答案
1.你喜欢粉色还是蓝色？//判断性别
A.粉色 B.蓝色
2.随着年龄增长，你从一个精神主义者变成了彻底的物质至上者了吗？//判断年龄
A.是 B.不是
3.旅游一般是选择国内还是国外？//判断收入
A.国内 B.国外
输出：对应的人物和介绍
计算方法：题目1的答案A为1分，B为2分；题目2的答案A为3分，B为4分；题目3的答案A为5分，B为6分；将分数加和模6。
因为上面的工厂方法，我不用把一堆switch case拷贝一遍来改。而是非常简单的再添加一条策略：
String fortuneTellByName(int anwser1, int anwser1, int anwser1) {
LOG.info("题目1答案:{},题目2答案:{},题目3答案:{}",anwser1,anwser2,anwser3)//此行伪代码相当重要，因为信息是产品的价值之一！
int sum=anwser1+anwser2+anwser3；
return fortuneTellings.get(sum/6).requireFortuneTellingResult();
}
策略模式大功告成！策略模式封装了不同的算法，根据需求灵活选用，很好的解决了逻辑的复用问题，是平时开发中的一个好帮手。
上面两个测试如果比如用了同一个微信号测试的，那就能将名字和其他信息做一个关联了。互联网开发产品完成后一定要做的事情：大数据分析开始了。首先建立用户画像。
建立一个UserProfileBuilder。里面有withName、withGender、withAge、withIncome，最后有个build()方法，来完成整体信息的展示。
建造者模式完工！将UserProfileBuilder代替前面的log打印。在后台统计页面可以生成漂亮的用户画像图。
前些日子金庸老先生去世了。为了蹭个热点，聪明的产品MM告诉开发小哥说再开发一个产品：把《花千骨》主题换下来，换成“测测你是金庸小说里的谁”。当然，互联网原则：原产品不下线，继续保留。只保留不维护。
用工厂模式，又生成了一堆requireFortuneTellingResult()方法的子类之后，怎么和策略模式里生成的两个策略做衔接呢？
这时候只需要将 Map fortuneTellings 封装一下。一个是《花千骨》工厂的map，一个是《金庸小说》工厂的map。另写一个指挥官类。根据需要来指定是哪个工厂即可！
桥接模式就是这么简单！
静儿文中没有对具体的设计模式内容对介绍，网上一大堆，这种场景下都不用纠结用谷哥还是度娘。本文的要点是设计模式应该是自己平时开发中时时刻刻都在用的。意识很重要。
