作为初来乍到的笔者第一次写公众号文章，首先感谢群主大腿的帮助，感谢群主的平台，感谢人民，感谢国家，感谢关注并查看文章的各位父老乡亲。
论写代码笔者是真的渣渣（认识我的人都知道），不过论吹牛皮笔者可是专业的。大概下图就是真实程序员的写照吧。
如果能从代码的灵活性和复用拓展性上能能做出一些整理的话，这样我们是不是就可以高效的完成需求，愉快的早早下班回家了呢？
到底有没有必要在我们制作功能需求的时候多次对代码进行重构调优呢？我认为优良的程序结构设计并不是为了作秀和花哨，反倒是在不断的应对新需求和更改时发挥着巨大的作用。稍微挑拣几个内容探讨下低耦合的程序设计手段。（大佬轻喷！）
1. 设计模式之单一职责原则
高内聚和低耦合通常是密不可分的，面向对象的本质是对对象的抽象，类又是对对象抽象结果的具体表达。对于一个类而言应该尽可能的让你成为一个或者一类对象。且只负责处理该对象所包含的操作内容。对于具体的设计模式而言是这样定义的：
正因为一个类只负责了其自己的功能使得模块功能尽可能的单一，那么供其它模块调用的机会就少。从而达到了高内聚低耦合的设计目的。
2. 设计模式之迪米特法则
很多情况下，我们的类与类之间，模块功能与模块功能之间是需要沟通去功能完成一些职责的。这样在表达上就不免A模块在调用B模块的方法，B模块也同样在耦合着A模块。太过紧密的联系会让两个模块的通用性和扩展性更差。其实迪米特法则很早就给出了这样的解决方案。内容如下：
这就需要我们在类的结构设计上，每一个类都应当尽量降低成员的访问权限。两个类或者模块之间只通过编写接口方法供其调用。这样就会使得类的耦合变弱更利于复用。
3. 架构模式之MVC
MVC 模式代表 Model-View-Controller（模型-视图-控制器） 模式。这种模式用于应用程序的分层开发。
1) Model（模型） - 模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器
2) View（视图） - 视图代表模型包含的数据的可视化
3) Controller（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开
MVC架构模式虽然会让类功能由一个变成了三个，但对于修改和拓展还是有很大的方便的。对于客户端而言策划提出的需求往往是只更改下表现的内容，这时候我们只要修改view的内容就好。同样对于不同的分辨率、不同的设备、不同的平台下可以轻松的将功能移植过去，只修改少量的代码。
4. 反射
尽管我们有了以上手段但仍然没有完全避免接触耦合的办法，有没有想抖音搭讪段子那样（嗨，美女，结婚吗？）一步到位的呢。回答是有的，而这种技术就叫做反射。反射反射程序员的快乐！一个只需要程序集名称就可以访问其字段属性和方法的调用方式（不管其是私有还是公有还是静态）。要上班了，老板要来了，这里简单贴下代码草草结束了。
5. 设计模式之观察者模式
这里只做简单介绍吧，大部分游戏客户端的消息传递机制都是用的这种模式去实现的。他的核心是委托和事件。也能很好的解除类之间通信的耦合。后面如果可能会有专门篇幅的讨论。
6.其他的手段还很多，基于时间问题和笔者的能力有限，下面的内容就靠大家自行脑补了。
“Bug排查千百遍，唯独倾城美女看不厌”。最后放上群主喜欢的后宫佳丽（偷笑）镇楼！杨过心中的小龙女，神剑少主心中的王姑娘。笔者心中的柳如是、李师师。
注：本内容为笔者原创，转载或者用于其他用途请注明出处！
