》 顺便推一下博客主页
前言
今天写demo的时候，顺便发现了自己对设计模式感觉搞迷糊了。然后就整理一波设计模式。现在android常用的是mvc，mvp,mvvm。其他设计模式先放过了，先不整，主要是用得少。话说面试的时候，一般都会问自己写代码的设计模式，才出来的时候说mvc,基于大佬的代码复制一套mvp,然后基于jetpack说是mvvm.似乎从来没有仔细理解过这几种设计模式的优缺点，为啥要用这些设计模式等等。 为啥用，因为大家都在用，我不用就落伍了，这可能是我这类搬砖工这么用的原因。我记得有大佬在自己博客上说过类似的话."设计模式，他是一种思维逻辑，而不是一种简单的代码规范，要体验到诸多设计模式的优点，只有自己用得多了，而不是看的多，用得多了才有自己的感悟，否则一直都是代码规范是没法理解到他的优点的“。
内容资料大多数源于百度百科
正文
android搬砖工，所以基本上从android应用上去理解，如果有理解错误的地方，欢迎指正。
mvc
经典MVC模式中，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。其中，View的定义比较清晰，就是用户界面。
百度百科MVC
理解一波
这个调调，感觉更适合当初的jsp和H5开发。要说android上使用，前期开发的时候，一般用别人的框架工具之类的，通常是activity 处理业务模型M，作为Vew用户界面，作为控制器处理事件和网络请求数据缓存之类的。 有将数据处理和事件单独拿到一个类中处理的，我就没有遇到过，拿到一个类处理的，人家都说是高贵的MVP开发了。所以那个时候，m在activity里面，v是activity，c是activity，fragment也是这个样子。view层的压力太大了。 这么久导致一个问题，那就是界面层代码太多了，如果网络请求和数据处理没有进行封装，那也太长了，如果不写注释，接盘的大佬也太惨了。 当然了，在这个基础上也不乏有一些大佬是将数据处理单独到一个class里面的，毕竟后台大佬和自己对M的定义不一样，先写界面就需要数据转换了。 android 的databinding 出来之后，就觉得有必要将事件处理提到一个class里面了。这就有了简单搬代码位置的思路。databinding 的事件处理当然也可以在view里面整。
MVP
mvp的全称为Model-View-Presenter，Model提供数据，View负责显示，Controller/Presenter负责逻辑的处理。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
百度百科MVP
理解一波
这个感觉和mvc的控制层抽离方式很像，毕竟网络请求和数据处理也算控制层中的内容。而p层主要的作用就是写数据控制和事件处理，emmmmmm? 起码我点击事件没有拿到P层和C层过。 个人觉得他的View不直接操作M,这个才是这个MVP的特点，毕竟如果是服务器一套模型，本地一套模型，中间转换层就只要写到P层就好了，写的位置统一了，以后也好改一点。 只要将数据处理好，然后通过接口或者eventBus,或者类似的工具收到就行，这么就导致View 层的逻辑很清晰。因为P层进行数据事件处理，和可能出现的两套数据模型，P就承担了和C层一样的功能了。
MVVM(jetpack)
MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开.
理解一波
主要还是jetpack 这一套东西太好用了，不用处理生命周期。数据恢复，数据绑定更新。只要按照他的开发规则整，android 开发就简单很多了。不像之前生命周期数据刷新都要代码控制。当然也有大佬写过很严谨的代码，主要萌新可能会有疏漏。
之前的P或者C都是将事件处理和数据，现在改到ViewModel 中了，当然了，viewModel 可以只是处理事件，然后再搞一个子类，单独处理网络请求和数据缓存，然后回调到viewModel 中，因为ViewModel 是进行事件的，所以，数据M应该让View使用就好，由ViewModel持有更新。如果将M数据放到View中和MVC又有什么区别。
结合实际
上面的主要是个人总结的理论东西，然后实际情况，可能有点出入。
mvc
如果是view 持有Model，充当C,那就没有必要整了。小项目感觉通常就是这么整的，逻辑不复杂，也不需要太多的事件，不处理太多的数据处理。过于复杂的地方也可以将复杂的逻辑数据化，单独写一个类处理这些东西。单独写的这个类可能和View一起充当C层了。
mvp
之前大佬写的模板，Activity 充当view,然后有一个接口处理P层的数据回调呀(然后这个调调竟然叫view,我泪了)，或者事件回调，然后写一个P层进行事件处理和数据处理。接口可以通过类似于EventBus 取消掉。因为P层和接口是关联的，会加大代码量，解决问题是阅读方便了一些，逻辑清晰很多，规范了写法。
MVVM
这个主要是jetpack，现在写一套东西要创建好多东西，首先是View,然后是ViewModel,然后是viewModel和view的回调接口,然后是xml适配databinding加viewModel,然后是网络请求和数据缓存类，最后是网络请求数据缓存类回调到ViewModel的接口。泪目了。虽然接口回调都可以通过类似于EventBus减少，但是通过EventBUs类似的工具传参如果注释写的不好，那就泪目了。 这个调调主要是将功能点分的很细。一个类处理一个类似的事情，规范了写法，但是加了好多类，简单功能可能导致ViewModel或者接口类，网络请求类一点用处都没有了，当然也可以写一个专门处理这样的类。反正就是复杂了创建过程，统一处理了逻辑分类，使得代码可读性提高了很多。这样就需要自己写一套模板，适合自己的项目。 现在android studio 4.1导致我之前写的模板代码不能用了，只能换到IDEA.
涉及长代码的模块
主要还是解决代码太长，逻辑太乱的问题。但是分的太细了，也不容易理清楚的，所以还是看情况整吧。
- 数据请求(主要是回调处理)
- 数据缓存 （也可以是sql存储，就涉及到增删改查了，写到view代码也蛮长蛮多的）
- 本地模型和服务器模型转换（这个主要是服务器模型如果不在界面上用，就应当转换就销毁，放view干啥啊）
- 多个网络请求（这个多个网络请求，无论是Rx组合还是什么写法，都是长代码模块）
- 数据加密解密 （工具类写好，这个倒是不长，主要是和网络请求一起）
- 点击后网络请求。还是网络请求
- 切换展示数据
- 自定义数据模型初始化等等。
- 特殊view初始化，这个调调看写法，也可以放到P层或者C,或者ViewModel中。
个人觉得，只要能让对方直接使用的都应该抽离出来写，如果对方需要参与创建流程，那就弄建造者模式就好。比如说android dialog就是建造者模式。 但是用的还是蛮少的，通常是界面层的东西，和业务处理关系不大，界面层的还是放到view中去整就好。
结束
其实整了半天，也没有说明个什么，主要是当笔记乘机和诸位大佬沟通一波。 当然了，也有大佬说方便些单元测试。道理我都懂，正经搬砖工谁写单元测试呀，你写吗？反正我写了[嘻嘻.png]。 写测试代码还是蛮重要的，现在只会写简单的验证数据的，像activity界面层的就不行，老是抛错[卑微.png]。 为啥他们都把接口叫做view.是因为要往View回调数据吗？叫ViewCallBack不好吗？就因为他名字长久简略叫view了吗。卑微.png
