java中的炸包是什么 java中什么是类爆炸

大家好，今天来为大家分享java中的炸包是什么的一些知识点，和java中什么是类爆炸的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！

java工作中有那些问题

一般来说面试我都记下印象深刻的面试题，其他感觉都没什么好记的，但是今天这个面试的过程感觉是我职业生涯中比较有意思的一次面试，遂分享出来。

今天顶着大太阳出去面试，找了好久终于找到了这家公司的位置，貌似是集体办公区域，就是一层楼有N个公司在办公，也没什么隔断。心想创业公司吧，这样也正常。在这之前已经面过三家公司都挺顺利，公司规模都还可以，还有一家一面也是过了等二面。之所以来这家公司面呢是因为对公司的产品还挺感兴趣的，想来看看。

然后到地方后面试官先给了我一份卷子做，都是些很简单的题，写完后等了好久面试官来了，开始进行面试。面试官先看了下我的简历，然后说你怎么两年才做这么4个项目，尤其是第一家才1个项目。我说外包公司项目多，没必要挨个写上，写上最近一家公司的项目，和之前公司代表性的项目就行了。然后他就教育了我一番，说怎么写这么点儿呢，很容易让人觉得你啥都没做，做过的都得写上。我之前一直以为我这种两年多经验的写一页简历足够了，不过他说了下我觉得确实可以考虑考虑多写一些。。。不过老实说我在想。。难道他毕业四五年了还把刚毕业的项目往简历上写？

吐槽完项目。面试官不知道为什么看着我的简历以为是培训班出来的，然后就旁敲侧击的问我毕业是否有参加过什么培训啊。我满脸黑线，我简历写的我第一份工作毕业就进去的，而且我项目都是专业领域性很强的项目，这是从哪儿看出来的。然后这面试官又问我那你大学都学什么课程啊，我又耐着性子解释了一圈。然后他看问不出啥的就没问了。然后就问了一个项目有关的正常问题。开始问我技术了。

第一个技术就问我spring框架，然后问我spring主要注重哪些技术，我说了就依赖注入和自动化配置，然后这人问我如何学习spring，我说看了spring实战，深入理解spring架构，然后还看了源码，然后这人说你看了官方文档吗，我说看了小部分，然后他说你怎么不多看官方说明文档呢，我说我更多喜欢直接看看源码设计，而且官方文档更多就是说明书的意思，我觉得用来入门还行，要真正了解肯定还是要深入底层去看下。然后争论了一番后他问我springboot自动化配置如何实现的。我从实现原理，源码流程说了一圈，我估计他应该不懂这块儿，然后我说完后他和我说你觉得看这些东西用处大吗，你为什么不看官方文档。我当时真是满脸黑线，合着这官方文档在他眼中是圣经啊。然后又问我springboot如何实现的tomcat启动，我源码解释了一圈后我估计他还是不懂源码这块儿，所以又和我死磕说你这些东西为什么不看官方文档说明呢。。嗨，我第一次看到对官方文档如此执着的人..。。当然了他举了个有意思的例子，说比如你买了个冰箱，你不看说明书你怎么知道如何使用呢。。我真的很想说我看过这台冰箱深入介绍的几本书并且连内部零件构造都了解你觉得我不会用这台冰箱吗。。

然后框架就没问了，老实说我觉得可能是他也不太了解。。然后就问我sql了，说有没有用过索引，sql优化。我说了一些，然后他说下mysql索引类型呢？我说你指的哪种类型，是hash/b+tree，还是聚集索引/非聚集索引，还是普通索引/唯一索引/主键索引/.....这种。然后我估计他对前两个应该不了解，然后恼羞成怒的来了句你觉得我问的是哪个？我去，这个我哪能知道。然后我就说了下 hash/b+树索引，然后这个人来了句b+树你觉得是什么，是一种算法，还是xxx，我当时很无语，名字都叫树了这难道不应该是一种数据结构吗。然后又解释了一圈我感觉他可能也不了解这块也就没问了。然后问我算法。

其实就简单的问了句，你了解哪些排序，我说冒泡排序，插入排序，快排，堆排序.....，然后这面试官嘲讽的笑了一声，我赶紧回想了哪个有问题，结果想了下没想到哪个字说的有问题我就问你为什么笑，然后他说堆排序是什么东西。老实说听到这句话我是真的很想直接走的，但是想下这对不起我请的一上午假。然后我很克制的说了句，你不知道不代表没有，这是任何一本讲数据结构与算法的书都应该会讲到的东西，建议去百度下。然后这个时候我估计他本就有点儿恼羞成怒的心情被彻底点着了，然后开始问我jmm。哦对了，他看着我写笔试题的时候排序那儿说了句这是什么排序。(我觉得快排方法应该还是挺好认的)

jmm问我五大数据区域，我说了后最后我提了一下直接内存，然后这人我估计也不懂，然后就开始说我问你这个了吗？我让你说五大区域你为什么提这个？你有听清楚我的问题吗？我当时就？？？，合着我这多提了一嘴直接给戳高潮了。。。然后赶紧闭嘴了，让他接着问后面的问题。

然后问了我期望薪资，我说了个期望薪资，结果这人说，你觉得你在项目中能承担部门负责人？还是项目经理？合着我期望的薪资在这家公司是部门负责人才有的待遇，看这意思应该是觉得我漫天要价。我觉得我要再说我已经有的三个offer都比我刚提的要多怕不是能让他当场爆炸。。当然了，为了不自讨没趣我就说我只能承担个中级开发吧。。。

最后问我有什么想问的，我就照例问了下公司技术栈，然后他说后端用java nodeJs，我就问为什么后端会用两种技术栈？然后他回答道，这么用肯定是处于公司技术考量啊，巴拉巴拉的，反正最后也没说个明白为啥会用两种技术。。然后这个时候提了一嘴既然采用nodeJs是觉得更加方便为什么不考虑考虑使用Python。老实说我觉得我这句话作为大家都是技术人员，技术探讨性的问题应该很正常吧，结果这句话不知道为什么又把他戳高潮了，他直接回到为什么要用Python？我在严肃的和你讲公司技术栈，你觉得这样好吗？你觉得这样提问好吗？你这样随意的一问觉得合适吗？

最后伴随着这几个疑问，面试结束了。。。老实说我被面的有点稀奇古怪的，尽管他问的问题我觉得我应该全都回答上了，但看他的样子似乎很不高兴

包的英文是什么

包的英文读package。

在Java中，包主要有以下用途：

-包允许将类组合成较小的单元

-有助于避免命名冲突

-包允许在更广的范围内保护类、数据和方法

包可以是类、接口和子包的集合

创建包

package mypackage;

必须是.java文件中的第一句话

访问 Java包成员

mypackage.My_Class

导入包

import package_name.*;

导入子包

import package_name.package_sub.*；

编译

javac–d<目录名> xx.java

运行

java包名.类名

如何使用自定义的包：

自己定义一个.java文件，创建一个包

例如：该文件是Test.java文件，创建的包是com.accp

那么，编译该文件后生成的Test.class的包路径是

com.accp.Test.class

将该文件加入classpath中

a.如果将.class文件导入classpath中，那么应该在classpath导入包含该.class文件所在最上级包的目录

例如：Test.class文件最上级包目录是com文件夹，com文件夹在c:\，所以应该加入c:\

b.如果将.jar文件加入classpath中，就应该在classpath中导入该.jar文件的详细路径。

java中什么是类爆炸

可能是由于设计者对面向对象设计经验的缺少，也可能设计者是一个刻板的教条主义者，结果出品了一个很不理想的设计，其中可能就体现在类的数量爆炸的问题。

类爆炸的现象已经发生在我们的软件系统中了。比如我们某期的系统中各种模块文件的数量已经达到一千多个了，虽然比起操作系统这样的系统来说，由一千多个模

块组成的系统不算什么，但是我们目前的软件团队维护这么多的模块真的是有些吃力。由于我们使用的是VB，这还导致另一个问题，VB能装载的文件总数是有限

制的，最后用户提出了新的需求需要新的模块来完成实现，系统却已经不允许加入新的模块了，最后不得不对系统进行拆分或者对某些模块进行合并。

类爆炸的直接原因是设计者对类的抽象粒度没能把握好，只要两个事务有所差别就用不同的类来设计。粒度能多小就做多小，以为这样可以减少耦合。事实是如此

吗？最近组长让我写一份设计问题，他已经规定了设计文档的规范和大纲，规范中说“本系统编码使用了三种类：界面类、实体类、记录集类，并调用了公用模块中

相应函数”，这可能是他从别的设计规范中继承抄袭过来的。但是我最后提交的设计文档没有实体类和记录集类，组长问我为什么没有这两种类，我说我不需要这两

种类，我这个功能一个界面就可完成了。但是他觉得，如果我没有那两个类就应该在设计文档中说明没有那两个类，我说我的设计文档中没有描述那两个类就表明我

没有那两个类，而不需要在文档中说明“实体类，无；记录集类，无”。

如果每一个功能的完成都必须设计成“界面类、实体类、记录集类”这三种类来联合完成，我们就陷入了教条主义的深渊中。曾经和某个项目经理探讨过，“a=c

与a=b=c”的取舍问题，我的观点是根据具体情况来决定是使用“a=c”的结构还是使用“a=b=c”的结构，他的观点是每个功能都一律使用

“a=b=c”的结构，这导致我很郁闷。为什么要在很简单的情况下，本来可以直接就让“a=c”，何必非要加一个中间件“b”，通过“b”来让

“a=c”？不是我不知道“a=b=c”的结构的用意，而是我觉要根据具体情况来应用。我们的系统的类爆炸就是因为不分优劣一律使用“a=b=c”的结构

而爆炸的。对于面向对象的初期使用者来说，总会津津乐道他在系统中实现了面向对象的设计，尽管那个设计比较糟糕。其实这位项目经理只是给了一个系统的规范

文档而已，至于说是他设计了系统的架构，那还远远谈不到。系统中有什么类，类如何创建，类如何组织，类之间如何通信，他都没有做。只是在文档里说了“本系

统编码使用了三种类：界面类、实体类、记录集类，并调用了公用模块中相应函数”，一句话了事。系统中到底有多少类，他不知道。

我在阅读设计专家关于面向对象设计和设计模式的文章时，这些专家一再强调要谨慎使用面向对象和设计模式，否则后果就是苦果。我在应用面向对象时一向比较小心，一步一步的学习使用，而不是一步到位，毕竟我是个初学者。

再举一个例子。我们的系统中有一个连接类，大家都知道这个类是用来连接数据库的。不过我想很少有人知道为什么设计者要设计出这样一个类来。是因为他刚刚读

过设计模式中有一个“单例模式”。对于我们现在的这个系统来说，使用一个数据库连接对象就可以了，设计者为了避免每个程序员都去创建新的数据库连接，就使

用“单例模式”设计出一个连接类来。“单例模式”的用意就是某个类的实例在整个系统中只能有一个实例存在。比如我们用的windows剪贴板，在整个系统

中只能有一个剪贴板，大家都不会去new一个新的剪贴板出来。

我感到非常的郁闷，在一个公用模块里申明一个系统变量connection就可以了，告诉大家这个对象是我们的数据库连接对象，大家都用这个对象，为什么

再来一个clsConnection类对connection重新包装一下？，这反而就有问题了，我可以new出无数个clsConnection的实

例，没有达到“单例模式”的用意，因为在clsConnection类里没有提供静态方法来总是返回系统中已经存在的连接对象，这成了“多例模式”了。也

许设计者的另一个用意是要使用设计模式中的“简单工厂模式”。不过，不管是想练习什么模式，对于一个connection根本没有必要再包装了。这好比我

们有一个系统级变量，为了避免大家都去申明这个变量就用一个类来包装这个变量。那么系统中已经存在这样一个类，为了避免大家乱用这个类，就再来一个类来包

装这个类？层层包裹下去，怎么才算安全？（这里的例子是应用VB做的系统，JAVA使用者请勿随意理解。这里有语言差异。）

使用面向对象设计技术会产生良好的系统，但是，类是面向对象中的东西，那么类爆炸也必然是使用面向对象的产物，这是不良设计导致的。

我们有的程序员有些过于遵守规范而显得有些刻板了。举个例子。某个程序员做了一个类A和一个类B，实体B是实体A的载体（规范中要求每个实体都要对应一个

类），类A提供了一个修改自身的方法，当实体B的某个属性改变时必须要改变实体A的某个属性。我看了源代码，发现一条SQL语句就可以解决这个问题，但是

这个程序员为了用类A的修改方法，在类B中写了一个循环，先找出所有属于实体B的实体A，并创建类A的实例，然后调用类A的修改方法。代码不但冗长还效率

低下。这个程序员有自已的理由去那样做，理由1是上面领导制定的规范要求这样做，理由2是这是一种面向对象的应用，因为类A已经提供了修改实体A的方法，

别人就应该重用这个方法。一切讲究重用。

我想提出的是，如果重用这个方法即不使代码简洁又不能提高效率而且还造成强烈的耦合，为什么还要重用它？在面向对象中，大家知道类的构造函数是用来做什么

的吗？重载方法又是为什么吗？为什么一个类可以有多个不同的构造函数？不同的构造函数是为了达到不同的目的，而不仅仅是为了实例化一个类。方法的重载也是

为了实现不同的目的。当类A提供的方法不能很好的完成任务时，我们就应该舍弃它或者重载它。如果规范要求必须类B调用类A的方法（这个“必须”很值得疑

问）时，那么应该在类A中提供不同的修改方法以使设计合理。类A可以有这样的两个方法：方法1（以实体A自身的引用为参数）,方法2（以实体B的引用为参

数）。

关于重用。

我们现在设计系统一直想达到重用的目的。但是考虑我们所做软件的性质，我们对系统组件应该达到什么样的重用程度。我们的组件是不是要发布出去供第三方二次

开发？我们的组件是不是每年能达到2次重用？业务组件和与业务无关的组件重用的能力是不是有很大区别？我们不同的客户的业务规范是不是相差比较大？

由于我们现在对业务抽象的不到位，设计出来的类的粒度控制的不够好。业务相关和业务无关的对象的分离做的不够好，因此，实现组件甚至一个子系统的重用是很难的，只能为不同的客户去修改现有的代码，这显然不是重用，而是维护。我们的代码一年连一次重用的机会都没有。

关于创新。

如果没有创新的设计，后果是可想而知的，不管我们了解的业务再多，我们总是用最原始或者最笨拙的设计去实现业务。这样我们对业务了解的越多，系统做的越

大，代码就越混乱越不稳定。能达到将就凑乎的使用已经是不错的了。当硬件技术飞速发展的时候，软件技术却落后，结果是什么？那么，在我们公司，业务和技

术，哪个是硬件哪个是软件？当所有程序员都意识到争当项目经理和项目组长可以不去编写程序而待遇却提高了时，结果是什么？设计需要创新，了解业务却是一种

带有明显的“被动”特征。用户不告诉你他的业务规则你就不知道，告诉你，你就知道。当用户停止提供需求时，这段时间内，需求调研人员应该做什么工作？是不

是留下了大量的需求文档，是不是去抽象业务规则了？需求调研人员是不是能发现不同客户的不同业务之间的相似性为设计人员提供指导？

我们无法为客户去创新业务，但我们应该去创新我们的设计。一个软件的设计很难保持三年不变，如果三年后还不能有所创新而发生变换，那就落后了。为了适应新

的形式，微软敢于修改自己的操作系统的内核使系统升级。不升级意味着失去财富，而升级时难免要修改部分内核。那么，应用创新技术付出的代价大还是保持原有

系统不变的受益大？我们要考虑新系统生产时的阵痛和它以后带来的长远利益。

公司的人员流动的特征我们是否加以分析了，流走的是什么的样人，进来的又是什么样的人。这些人的技术能力、性格、悟性又是如何？我们拥有了许多安于现状不

具创新的老员工，我们该怎么对待他们？如果一个员工的性格激烈但悟性良好能有创新，我们是不是排击他了？兢兢业业、按部就班、任由指挥是不是就是一个优秀

的员工？

一个公司，各种性格的员工的存在应该有一个比例。全部都是不安分的创新者是不好的，充斥大量的安分守己、明哲保身、上面怎么说下面就怎么做的员工也是不好的现象。公司员工的性格和悟性的分布应该象一个波浪一样，有浪头有浪波，这样才能形成巨浪。

关于沟通。

公司越大，我发现员工之间的沟通越差。当我们还是一家小公司的时候，我可以认识所有的人，现在仅能认识个别几个人。沟通，不是由领导来强调下面的人去做

的，而是由领导来启动和带动的。所谓“领导”两个字，就是“领”和“导”，什么意思？大家自然知道。如何才能称得上一个领导，他必须具有领头和导向的作

用。各个部门的领导肩负着不同的“领导”。技术领导，他的技术是不是一定要强？若不强，是不是他能通过沟通的艺术来让下面的人服从？

沟通是一个大的问题。比如我早已经应用过一个比较好的数据库设计模型，但是新项目的设计者从来也没有咨询过我是怎么做的，结果他自己搞出一个很糟糕的数据

模型。沟通是一个双向过程。被动的沟通与主动的沟通的效果自然是不同的。我们现在缺乏主动沟通，就是被动沟通都不能好好的参与。所以，沟通出现了“推模

式”和“拉模式”。举个例子，我有些编程技巧放到公司网站了，很少有人去用主动的看，如果他主动去看了，这种行为模式称作“拉模式”。为了让更多的人知道

我的技巧，我只能主动把技术文章发到每个人的邮箱里，我的这种行为模式是一种“推模式”。我把技术文章推到每个人的邮箱里了，那么接收邮件的人是不是“拉

过来”看一眼？我发现，有一部分人是从来不看的，技术人员也不看。到底为什么不看？看不起我的文章还是太了解我而觉得没有必要看？他的心态我没有办法了

解，总之，沟通是有障碍的。

“聚集”沟通需要大家坐在一起去探讨某些问题，但这可能会浪费参与人的时间。因此我一直以为“推模式”的沟通还是可取的。使用邮件来沟通，想看则看不想看

就不看，尊重接收邮件的人的参与意识。但是发邮件会引来一些误会。一部分人会把你的邮件当作垃圾，心里不喜欢你给他发邮件但又不能说出来。一部分人会认为

发邮件的人脑子有毛病或者出风头，我觉得应该让每一个人都摆正心态：尊重发邮件的人。历来都有“枪打出头鸟”的现象，人在浪头上，难免遭遇不恰当的言语。

因此，永远低调和保持沉默便成为一种人生哲学。激进主义是用来推动社会前进的，保守主义是用来维持社会稳定的。我们允许这些同时存在。

由对事演化到对人。

当我们探讨问题时一般都是本着“对事不对人”的态度的。对于言者也许是这样的心里，但听者可能认为言者就是“对人不对事”。我们没有办法使他消除那种心里，因为那是他的性格使然。但是我们希望每个人都心胸开阔一些。

在探讨关于类爆炸的问题时，我说了一些题外话。

当我和一些同事在探讨设计中的缺陷时，发现大家的眼睛都还是明亮的，知道问题所在。不幸的是，几乎所有的人保都持沉默而不将问题暴露出来。当我暴露问题时，会得到个别人的善意的奉劝：“不要去做”。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！