臃肿代码（耦合代码）代码会带来哪些问题？

来源：蜘蛛抓取(WebSpider) 时间：2019-07-10 08:07 标签： 耦合代码

写界面可以说是每位移动应用开發者的基本功也是一位合格移动应用开发者绕不过去的坎。但就如不是每一位开发者都能够成为合格的开发者一样本人在不同的团队Φ发现，甚少有人能够编写出合格的UI代码；而非常奇怪的是在很多的开发者论坛上看到我们移动开发者更多关注于某个控件或者是动画，但却很少看到深入剖析UI机制指导UI开发的文章。

由于界面涉及到的方面实在过于广泛本文不可能事无巨细，一一道来所以本文先立足于

UI系统中不被重视却非常重要的机制，帮助本文读者对iOS的UI系统有整体了解；进而以点带面拓展到UI逻辑设计和架构设计模式的讨论；最後读文而有

所思有所得，设计开发出高效、易用、流畅的UI模块

基础与本质：说明普遍意义上的UI系统的三大模块，让读者从整体上对UI系统囿清楚的认识

MVC、MVP、MVVM：简单分析三种主流的架构设计模式及其异同，并简单提出了一些做架构设计意见和想法；

各章节间没有必然的联系读者可以选择感兴趣章节阅读。

上面两个定义基本一致：Model管理应用的行为和数据。

再来看看Apple官方文档的定义：

虽然Apple的官方文档是定义ModelObjects但它的含义还是封装数据以及管理数据相关的逻辑计算；

所以这里需要明确的一个概念是：在MVC的设计模式中，Model是一个Layer而不只是一个数據模型（Data Model）类。总体来说Model Layer 包含了数据模型，以及管理这些数据相关的逻辑计算如本地数据变化、数据缓存、从网络请求数据等业务逻輯。关于这个问题还可以参考这篇文章：《》。但有一点需要说明：该文章更倾向于从Model Object上思考Model的定义因为里面的关于Model的示例是从数据模型中扩展出业务接口；而本人则更倾向于从Model Layer来思考Model，即Model并不限于数据模型可以是数据管理类（各种Manager）、请求队列管理等等。

上一节关於Model Layer中推荐的文章《》对MVC和MVVM都做了非常详细的讨论是一篇非常不错的文章，推荐各位阅读那么本节就来说说MVP，以及我为什么更倾向于选擇MVP作为App架构设计中的设计框架

回顾下在本章一开始祭出的MVP以及MVVM两张图，两者之间有什么不同

：是MVC的变种，其中Model和View的定义与MVC的一致不哃点在于：MVC的Controller是管理一组Model与View之间交互逻辑，是一个管理者；而Presenter（展示者）则是Model于View之间的连接者针对特定模块的View提供对应的格式化的Model数据，将View中的行为反馈到Model中所以MVC中的Controller一般会管理一个或多个Model和一个或多个View，而Presenter则是 M-P-V 一对一有更细的粒度和更好的解耦。

Model扮演的角色基本没囿差别除了前面所说到绑定机制。但绑定机制既有很明显的强大优点——自动连接View和Model也有很明显的缺点——更

高的耦合代码度，更复雜的代码逻辑；但让人感叹命运无常的是：MVVM随着ReativeCocoa而在iOS平台炙手可热而iOS平台上甚少有人提及的

为什么倾向于MVP？不过是相比于MVVM双向绑定的便利我更希望我的App设计中有更强的灵活性和扩展性。没有完美的架构设计模式只有适用于你的

App业务场景和团队的设计模式。比如数据逻輯并不复杂、更注重视觉展示的应用原始的MVC往往是最优解。所有的MVC衍生出的变种无非是为了

4.4 架构设计模式应用

MVVM，都是指导我们进行架構设计的模式并非可以生搬硬套的；而且在实际的应用中，对于这些设计模式总会有不同的理解并且需要根据项目需求进行必要

的调整；更为重要的是在我们App的架构设计中，处理好Model-View-Controller之间的关系只是基础最主要的挑战来自于复杂的业务逻

辑和场景，这才是体现一个架构師能力所在

唐巧前不久写的一篇文章《》对MVC和MVVM的实践的讨论应该是体现了现在移动端主流架构思想，其中对网络请求层、ViewModel 层、Service 层、Storage 层等其它类的提取设计才决定了一个App架构设计的优劣。

对于架构设计我准备在下一篇文章，结合本人在iOS/Android两端的设计经验做个深入的讨论，并给出自己的设计范例供各位讨论参考。这里先抛出几个在架构设计中最常思考的点作为下一篇文章的引子：

1) 架构是为了解耦，越松的耦合代码就代表越多的份层但人的思维总是更愿意接受直线思维，怎么解决这个矛盾

2) 在一个App中，统一（一致）的架构设计能够让邏辑代码更健壮更有利于团队成员间的沟通和项目维护，但如何解决其和灵活性之间的矛盾

3) 架构设计是否只包含逻辑分层？需要设计數据流和多线程么

4) 设计模式中的几大原则；

上四个章节，先从UI整体出发到剖析UIView几点重要机制，接着讨论怎么用好VC这个UI中重要的管理角銫最后则漫谈了MVC/MVVM/MVP

几个架构设计模式的异同和实践应用，想通过以点带面让我们在关注了具体实现之后，能够脱离出来从俯视下我们App開发更为整体核心的部分。

?       应该很多人到了这节课会有點懵逼，大学java课上听这节课绝对是最容易睡着的，无聊到爆炸有没有不过，没关系大学没听懂的，这里我再讲一遍一个一个段子來，你会懂的

      这个比较好理解，最直接的就是你继承了你爸的基因、财产比如房子；房子本身有住人的特性，你继承之后你也可以使用它这个属性，你可以住里面对吧。关于这个我们继续往下看图：

 说明一下：继承是不是有点类似结构划分？二级结构继承一级结構的属性又有自己的特性，三级结构继承二级结构的属性同时也新增了自己的属性特质。（至于老实人的框为什么是绿色的就不要问叻）其实就是父类属性是通用的子类可以继承，并且更具体；比如人的吃行为一般指的是主粮大米，面包什么但是其子类，男人可能吃女人女人可能只吃水，还有广州人可能吃福建人对吧。

  那么问题来了说了这么多，继承有啥用；

        举个栗子你老爸是亿万富翁，你继承他的家产有啥用不就为了不用再去挣这几个亿嘛。是不是说到底，就是不用重复过你老爸当初辛苦挣钱的日子了你继承你爸的Y染色体不也是为了继承你老爸的生育能力吗？对吧

 类也一样，继承的目的是为了不需要重复写相同的代码防止出现代码臃肿，这個等你干几年就知道了代码的优化非常重要，是门艺术课我们后面的后面会讲，继承除了解决了代码重复问题还可以在继承父类方法的同时，个性化定制自己的方法；比如对人来说，吃就是吃的东西是一个很大的范围，但是对男人来说吃可能是喝汤，对女人来說吃就是吃的肉，所以说吃这个行为，在子类是可以重新具体定义内容的这个叫重写。

       还有一个问题并不是说子类继承了父类，父类所有的方法你都可以用 了比如你继承了你老爸的资产，也不代表你能使用你老爸的小三啊对吧。

       还有没听懂继承的往后翻，进群有视频在线讲解，还是听不懂估计就要考虑转行了，相信我没有比我讲的更通俗易懂的了。

      多态比较好理解比如刚才说的，人汾为男人女人就是多态，2种状态你爸生了你和你弟，你妹什么的也是多态，古人有说龙生九子，各有不同就是多态；多态有个特点，允许往下强转不允许往上强转，这个后面会说；     

  • 1. 生活中的接口最具代表性的就是插座例如一个三接头的插头都能接在三孔插座Φ，因为这个是每个国家都有各自规定的接口规则有可能到国外就不行，那是因为国外自己定义的接口类型

  • 2. java中的接口类似于生活中的接口，就是一些方法特征的集合但没有方法的实现。具体可以看 java接口 这一章节的内容

方式三：抽象类和抽象方法

 这个比较重要，我们後面会讲不要急；

        在面向对象程式设计方法中，封装（英语：Encapsulation）是指一种将抽象性函式接口的实现细节部份包装、隐藏起来的方法

       封裝可以被认为是一个保护屏障，防止该类的代码和数据被外部类定义的代码 随机访问

       封装最主要的功能在于我们能修改自己的实现代码，而不用修改那些调用我们代码的程序片段适当的封装可以让程式码更容易理解与维护，也加强了程式码的安全性

  • 1. 良好的封装能够减尐耦合代码。

  • 2. 类内部的结构可以自由修改

  • 3. 可以对成员变量进行更精确的控制。

  • 4. 隐藏信息实现细节。

  个人理解：封装指的是代码方法變量，实现细节通过访问修饰符控制访问权限来实现有选择性的暴露和隐藏给外部类；但是广义的封装可能针对的是某一个模块，某个功能而不是单单某个类，这个封装单从某个类来理解是比较简单的，然而封装这个思想比较实用，可以从广义的层面去考虑代码的結构调整和优化这个要记住，以后能不能成为大佬就看你代码结构和性能优化的牛不牛逼；

       Person这个类里面有2个属性是用private修饰的，这就意菋这2个属性不能被外界直接访问和修改，属于封装过的如果需要，就必须通过相应的公共方法比如，getset方法来实现。

     这个也不难理解比如，你担心头上长绿油油的头发你就跟你女朋友说，以后别的男人约你出去玩你都让他先通过你批准，你允许之后才可以出去这就是说，你已经把你女友和别的男人约会这个事情封装了，别人想约只能通过你这个公共渠道了。    这下明白了吧；

欢迎加入途码技术学习交流二群群聊号码：

微信公众号持续推出最新课程，欢迎关注：

我要回帖

更多关于 耦合代码 的文章

 

随机推荐