展开全部
 
1. util包的框架
 
常用的集合类主要636f70793231313335323631343130323136353331333431343630实现两个“super接口”而来：Collection和Map。
 
1.1 Collection有两个子接口：List和Set
 

 
List特点是元素有序，且可重复。实现的常用集合类有ArrayList、LinkedList，和Vector(线程安全)。
 
Set特点是元素无序，不可重复。实现的常用集合类有HashSet，LinkedHashSet，TreeSet(可排序)
 
1.2 Map是key、value键值对的集合
 
特点是key值无序不可重复，value值可重复(这样表述其实不太准确，因为实际上key和value是绑定在一起的)。常用的有HashMap，HashTable(线程安全)，TreeMap(可排序)。
 
1.3 其余重要接口和类
 
上面是util包中的集合框架，一般Java教材里面都会讲到。但我们深入研究一下，会发现还有其余几个重要的内容：
 
Iterator：迭代接口
 
集合类实现该接口后便具有了迭代功能。最简单的迭代实现是ArrayList，迭代过程其实就是数组的迭代。LinkedList、LinkedHashSet和LinkedHashMap迭代过程就是链表的迭代。这两者的迭代效率都很高，迭代时间与容器里的元素数目成正比。但HashSet、HashMap迭代效率就略低了，因为采用了哈希表，所以元素是散列在数组中的，迭代时必须读完整个数组，迭代时间与容器的容量成正比。
 
Comparator：比较接口
 
实现该接口后，集合内元素便可比较通过compare()方法实现元素排序
 
AbstractXXX：骨架类
 
所谓骨架类，其实就是不同集合的核心代码实现，让继承这个抽象类的子类少干点活。例如AbstarctList代表“随机访问”集合(底层数组实现)的骨干代码实现。AbstractSequentialList代表“连续访问”(底层链表实现)集合的骨干代码实现。
 
Collections、Arrays
 
集合工具类和数组工具类。Java中的工具类好像都喜欢在对应的接口或类名称后，加S来表示其工具类。

 
Util是utiliy的缩写，是一个多功能、基于工具的包。
 
java.util是包含集合框架、遗留的 collection 类、事件模型、日期和时间设施、国际化和各种实用工具类(字符串标记生成器、随机数生成器和位数组、日期Date类、堆栈Stack类、向量Vector类等)。集合类、时间处理模式、日期时间工具等各类常用工具包。
 
Java的实用工具类库java.util包。在这个包中，Java提供了一些实用的方法和数据结构。例如，Java提供日期(Data)类、日历(Calendar)类来产生和获取日期及时间，提供随机数(Random)类产生各种类型的随机数，还提供了堆栈(Stack)、向量(Vector) 、位集合(Bitset)以及哈希表(Hashtable)等类来表示相应的数据结构。
 
Java是一门面向对象编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。Java语言作为静态面向对象编程语言的代表，极好地实现了面向对象理论，允许程序员以优雅的思维方式进行复杂的编程 。
 
Java具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点。Java可以编写桌面应用程序、Web应用程序、分布式系统和嵌入式系统应用程序等。

 
知识点
 
java.util 包提供了一些实用的方法和数据结构。比如日期类 Data，日历类 Calendar 以及随机数类 Random，同时包里还提供了堆栈 Stack、向量 Vector、位集合 Bitset 以及哈希表 Hashtable等表示数据结构的类。
 
本课程介绍了Date，Calendar和Random类，表示数据结构的类留作作业。
 
##Date类
 
封装了操作日期和时间的方法，但后来被Calender和DateFormat取代了。
 
DateFormat是java.text包中的类，用于对日期时间格式的处理。
 
##Calender类
 
介绍了GregorianCalendar 类，TimeZone，Locale等，但在示例代码中没有体现出来。
 
注意：month 的含义与 Date 类相同，0代表1月，11代表12月。
 
代码主要介绍了Calender类的使用方法。
 
##Random类
 
它可以产生 int、long、float、double 以及 Goussian 等类型的随机数。
 
文档对seed没有做出比较易懂的解释，也没有给出具体用例，让人有些难以理解seed是啥。同时提到的Goussian随机数也让人不知道指的是什么，
 
课程总结
 
介绍了一些比较实用的工具类，而数据结构这类难度较大不常用的就没有具体给出详细的解释了，掌握了这几个类的用法也有利于在解决实际问题时提高效率，不用每次要用都去百度一下。但是毕竟，课程中的内容只占整个util包的一小部分，更多内容还需要自己查阅资料等。
 
文档内没有发现错误文字等。
 
文档内语句通顺，易于理解。
 
文档内不包含语气词以及网络词汇。
 
程序代码中输出语句中又包含汉字
 
表格表述易于理解。
 
代码讲解基本完善
 
实验操作步骤代码块基本完善。
 
截图详细
 
课后习题能在虚拟机内完成。
 

 

 

 
 

 

  
来源：zhihu.com/question/58410621/answer/156868800
 
 
适合受众：2年以下的初级程序员和0基础的门外汉
 
内容大纲：
 
1.为什么需要一个好的代码结构
 
2.什么样才是一个好的结构
 
3.每一个分类代表什么含义
 
4.是否适用于WEB，Android和IOS？
 
5.进一步的学习的话，是要学习系统架构么？
 
一 为什么需要一个好的代码结构
 
好的代码结构并不仅仅是为了看上去清晰，它更像是我们对一个系统的拆解和组装。
好的代码结构可以让你在遇到代码交接这种天理不容的情况时，减少提刀砍人的可能性。
好的代码结构可以让多人协作开发更容易，而不会缠缠绵绵到天涯，再相爱相杀。
 
我们经常形容一个坏的代码结构，像屎一样。
 
 
我们称它为一坨，说真的，接手过烂代码之后，真的找不到比屎更能描述自己感受的词了。
 
“屎”代表着混乱，一坨，各种杂质。接手一堆烂代码的难度就像是用一坨屎来做沙画。
 
有时候我们还会用一团毛线来形容代码，大概是这样的。
 
 
对的，这种感受是绝对不会错的。而我们要做的就是把这团毛线，变成像瑞士军刀一样的清晰。
 
 
你们觉得哪个更有成就感？
 
二 什么样才是一个好的结构
 
好的结构应该保持单一职责。
好的结构应该是通用的。
好的结构应该是有明确定义的。
 
这其实就是所谓的脚手架提供的最大的价值，一般而言，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年以内的各种工程师。
 
别乱用，这样打日志定位 Bug 又快又准！
如何画出一张优秀的架构图（老鸟必备）
最牛逼的 Java 日志框架，性能无敌，横扫所有对手.....
阿里面试官 ：写if 时不带 else，你的代码会更好！
如何保护 SpringBoot 配置文件中的敏感信息
MyBatis 批量插入的 3 种方式！还有谁不会？
SpringBoot 项目模板：终于摆脱步步搭建了
还发愁画流程图？IDEA这款神仙插件全部帮你搞定！