共计 3117 个字符，预计需要花费 8 分钟才能阅读完成。
起源：zhihu.com/question/58410621/answer/156868800
一 为什么须要一个好的代码构造
- 好的代码构造并不仅仅是为了看上去清晰，它更像是咱们对一个零碎的拆解和组装。
- 好的代码构造能够让你在遇到代码交接这种天理不容的状况时，缩小提刀砍人的可能性。
- 好的代码构造能够让多人合作开发更容易，而不会缠缠绵绵到咫尺，再相爱相杀。
咱们常常形容一个坏的代码构造，像屎一样。
咱们称它为一坨，说真的，接手过烂代码之后，真的找不到比屎更能形容本人感触的词了。
“屎”代表着凌乱，一坨，各种杂质。接手一堆烂代码的难度就像是用一坨屎来做沙画。
有时候咱们还会用一团毛线来形容代码，大略是这样的。
对的，这种感触是相对不会错的。而咱们要做的就是把这团毛线，变成像瑞士军刀一样的清晰。
你们感觉哪个更有成就感？
二 什么样才是一个好的构造
- 好的构造应该放弃繁多职责。
- 好的构造应该是通用的。
- 好的构造应该是有明确定义的。
这其实就是所谓的脚手架提供的最大的价值，一般而言，Java，Android，IOS 都有一套明确的框架体系，JS 原本没有，起初有了，而后。。他们就打起来了。
就像。。。他们一样。
该喷火的喷火，该喷水的喷水，每个人分工都很明确。
三 每一个分类代表什么含意
1.Model
Model 是模型，一般而言，会有人分的更细，VO，DTO 等等。我并不举荐分的更细，这个 Model 经常和长久化的数据一一对应，如 Mysql 和 MongoDB。
Model 承载的作用就是数据的形象，形容了一个数据的定义，Model 的实例就是一组组的数据。整个零碎都能够看成是数据的 流动，既然要流动，就肯定是有流动的载体。
这个红圈标的就是 Model。它就应该是一个纯数据的汇合，就是被各种货色传来传去，被各种加工解决的数据团。
通常会有很多 Model，一条业务流就是对应一条或者多条数据流，拿知乎为例子。
文章是一个 Model，个别叫 Article，包含 Title，Summary，Author，Content 等等。
评论也是一个 Model，个别叫 Comment，包含 Content，userID 等等。
对于初学者而言，第一个要学会，就是建模，把业务逻辑映射成数据模型。
2.Util
Util 是工具的意思，一般来说，经常用来形容和业务逻辑没有关系的数据处理。
Util 个别要和公有办法比照：公有办法一般来说是只是在顺便场景下应用的，公有办法越多，代码构造越乱。常见的重构策略就是首先从一个越长行数的代码里形象出若干个公有办法，而后再抽出专用的 Util。
如果有可能，尽可能的少用公有办法，而是把他换成一个专用的 Util，代表他和业务逻辑是不相干的。通常命名也是 ArticleUtil，CommentUtil 之类的。
像这种打包，不论是充气娃娃还是别的什么货色，都打包。你能够了解为图中的黑衣人就是一个 Util。
某中水平上也会跟 Service 有点靠近。然而 Service 一般而言，都是蕴含有业务逻辑的，很少能做单元测试。
Util 一般来说，就是一个明确的输出和一个明确的输入后果。单元测试中，少数也是来测试 Util。
积攒好本人的 Util 是一件很重要的事儿。
3 Service
Service 比 Util 的概念大很多，它的重点是在于提供一个服务。这个服务可能包含一系列的数据处理，也有可能会调用多个 Util，或者是调用别的服务。总归一句话，就是，有什么事件，你来找我。
就像这个图上的妹妹一样，她就是一个 Service，她能提供什么样的服务？这个是必须定义好的。如果是洗脚，她要帮你脱鞋，要端盆子烫你的脚。这外面，你的脚就是一个 Model，盆子里的水相当于 Util，不论外面放进去啥都能烫一烫。
帮你脱鞋能够是一个 Service，也能够是一个公有函数，也能够是一个 Util。看你的是让这个小妹妹帮你脱，还是别的小妹妹脱，还是主动脱鞋机。
如果是你主动脱。。。阐明你在 Model 外面加上了性能，你的脚就不是一个纯正的数据模型了，而是一个蕴含业务性能在外面的充血模型。
这样不好。老老实实让小妹妹帮你拖鞋不好么。
4.Dao
Dao 一般而言，都是用来和底层数据库通信，负责对数据库的增删改查。
是的。他就是一个 Dao。他从来不关怀这些货物要去哪里，他只关怀。入库，出库，查问和更换。
所谓的 CRUD 就是创立，读取，更新，删除。
Dao 最好都是要独立进去。
到当初为止，最佳实际就是一个 Service 只对应一个 Dao。Service 会做一些额定的查看，如货物是否损坏，入库单是否残缺，等等等等。
我并不举荐在 Service 里调用多个 Dao，也举荐在 Service 里调用多个 Service，大多数状况下我都不举荐这么干。
具体起因当前再说，这也是一个开放性的话题。
当初咱们分分明了 Model，Util，Service 和 Dao，可是谁来做总的调度呢？
5.Controller
控制中心，所有的指令，调度都从这里收回去。
哪一个 Service 做什么事儿，谁的数据提供给谁，一般而言，都是在 Controller 里实现的。
Controller 也是最常见的容易产生脏代码中央，通常他们会把一些不该放到 Controller 里货色也放进来。
大略的感觉就是这样的。
干嘛的都有。想想如果打小针，抽血，查尿也混淆到门诊大厅的感觉？
可是大部分人写代码就是这样的。
四. 是否实用于 WEB，Android 和 IOS？
Java 后盾是有很分明的构造的，毕竟在 JSP 里写 Sql 语句的蛮荒时代曾经过来了。
Android 自身就是一个良好的框架体系，基本上问题也不大，最多就是 MVP 和 MVC 的差异之类。
IOS 尽管没有官网提供这种框架体系，特地是很多人喜爱间接在 Dict 里用 key 取数据，这自身就毁坏了代码的层次性。
然而毕竟是有李明杰提供的 Json 解析 Util, 只是各家要求的力度而已。
最难以了解的是 WEB，也就是 JS。
我不是在黑 JS，我是在黑 JS 程序员。分层构造始终都不是 JS 社区里最重视的，在 JQuery 时代更是如此，不论是 Html 还是 JS 还是 CSS 混在一起是失常的。
那个时候叫插件，当初改名了，叫组件。
你很难在 JQuery 里找到一套清晰的分层构造，就跟十几年前所有的人都在 Jsp 里写逻辑语句的情理差不多。
直到 google 的大神偶然遛达过去一看，咦？你们怎么还在刀耕火种？我来给你们加点现代感的货色吧。
于是 Angular 横穿入世，一次性的构建了一个清晰的框架结构。每次看到 Angular 的时候都忍不住 惊叹，原来前端代码也能够这样！
而原来的感觉就是这样。。。
当初基本上能够分成两大阵营，一个是 React 和 Vue，一个是 Angular。
React 和 Vue 自身更偏得于插件化，哦，不，组件化。所以他们须要便宜桶，来拼接整个前端的架构体系。
Angular 却是有典型的 Java 架构格调，妥妥的硬汉子。
所以，实际上说，这套体系也是能够利用在 WEB 上的，就像 Android 和 IOS 一样的，然而你喜爱，或者不喜爱，本人选啦。
五 进一步的学习的话，是要学习零碎架构么？
是的。进一步要学习，并不仅仅是学习零碎架构。
这里还没有讲到 Service 的设计，相互之间的调用，解耦，服务之间的通信和治理。
音讯队列这个神器还没有退场，MongoDB 这种策略要塞也没出场。
所以以上内容，仅实用于 2 年以内的各种工程师。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
