您的位置:

java经验,java经验 脱o经验

本文目录一览:

java课程分享自学Java语言的经验教训

很多年轻人跻身于Java开发行列,想要开始学习Java,觉得自学就可以,没必要其他方式学习。但是,Java自学能学会吗?自学Java的经验教训你知道多少?java课程一起来看看吧。

就好像一千个人心中有一千个哈利波特一样,这个答案不绝对也不唯一,Java好学但自学的确阻力有些大,作为一门技术语言,它所蕴含的智慧绝对不是靠几本入门、框架之类的书所能概括,自学Java你要做好一种英语0基础达到4级水平的准备!

Java要学什么?

开始就直奔主题聊语法是不对的,应该对Java基本属性以及特点应用领域做个大概了解,可当做学习前的热身,同样对以后的就业也会有帮助。Java基础语法,Java的面向对象,封装、继承、多态慢慢深入。

自学中会面对哪些问题?

类、集合、线程、Java网络编程,这个学习阶段经常会让自学者感到迷茫,大脑不是空白就是混乱。一方面是:对Java了解不够深刻,缺乏灵活应用的本领就好像我们学会了26个英文单词,但仍旧不能写出一串正确的句子;另一方面:缺乏独立查找错误的能力。这个能力是伴随所有程序的,无论有多少丰富的项目经验,必须能写代码,还能发现bug并且能够解决这个bug,自学者因为没有基础的沉淀,对Java各种编程属性不了解,就会遇到"能正着写,却不能倒着推"三分时间写代码七分时间找bug工作效率也大打折扣。

耗尽了所有的耐力,学到这里才是Java课程的基础,你可能用了3个月、5个月甚至更久才勉强消化这些知识,对以后学好框架几乎成了奢望。想要稳扎稳打,同时更快速的掌握Java技术,你需要更系统的学习更贴近企业需求的Java系统知识。

北大青鸟java培训:41条面向对象经验?

(1)所有数据都应该隐藏在所在的类的内部。

(2)类的使用者必须依赖类的共有接口,但类不能依赖它的使用者。

(3)尽量减少类的协议中的消息。

(4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等].(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。

如果类的两个方法有一段公共代码,那么就可以创建一个防止这些公共代码的私有函数。

(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。

(7)类之间应该零耦合,或者只有导出耦合关系。

也即,一个类要么同另一个类毫无关系,要么只使用另一个类的公有接口中的操作。

(8)类应该只表示一个关键抽象。

包中的所有类对于同一类性质的变化应该是共同封闭的。

一个变化若对一个包影响,则将对包中的所有类产生影响,而对其他的包不造成任何影响.(9)把相关的数据和行为集中放置。

设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。

这种类型的行为暗示着这条经验原则被违反了。

(10)把不相关的信息放在另一个类中(也即:互不沟通的行为)。

朝着稳定的方向进行依赖。

(11)确保你为之建模的抽象概念是类,而不只是对象扮演的角色。

类应当统一地共享工作。

(13)在你的系统中不要创建全能类/对象。

对名字包含Driver、Manager、System、Susystem的类要特别多加小心。

规划一个接口而不是实现一个接口。

(14)对公共接口中定义了大量访问方法的类多加小心。

大量访问方法意味着相关数据和行为没有集中存放。

(15)对包含太多互不沟通的行为的类多加小心。

这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。

(16)在由同用户界面交互的Java面向对象模型构成的应用程序中,模型不应该依赖于界面,界面则应当依赖于模型。

(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则).(18)从你的设计中去除不需要的类。

一般来说,我们会把这个类降级成一个属性。

(19)去除系统外的类。

系统外的类的特点是,抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。

(20)不要把操作变成类。

质疑任何名字是动词或者派生自动词的类,特别是只有一个有意义行为的类。

考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。

(21)我们在创建应用程序的分析模型时常常引入代理类。

在设计阶段,我们常会发现很多代理没有用的,应当去除。

(22)尽量减少类的协作者的数量。

一个类用到的其他类的数目应当尽量少。

(23)尽量减少类和协作者之间传递的消息的数量。

(24)尽量减少类和协作者之间的协作量,也即:减少类和协作者之间传递的不同消息的数量。

(25)尽量减少类的扇出,也即:减少类定义的消息数和发送的消息数的乘积。

(26)如果类包含另一个类的对象,那么包含类应当给被包含的对象发送消息。

也即:包含关系总是意味着使用关系。

(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。

(28)类包含的对象数目不应当超过开发者短期记忆的容量。

这个数目常常是6.当类包含多于6个数据成员时,可以把逻辑相关的数据成员划分为一组,然后用一个新的包含类去包含这一组成员。

(29)让系统功能在窄而深的继承体系中垂直分布。

(30)在实现语义约束时,最好根据类定义来实现。

这常常会导致类泛滥成灾,在这种情况下,约束应当在类的行为中实现,通常是在构造函数中实现,但不是必须如此。

(31)在类的构造函数中实现语义约束时,把约束测试放在构造函数领域所允许的尽量深的包含层次中。

(32)Java面向对象中,约束所依赖的语义信息如果经常改变,那么最好放在一个集中式的第3方对象中。

(33)约束所依赖的语义信息如果很少改变,那么最好分布在约束所涉及的各个类中。

(34)类必须知道它包含什么,但是不能知道谁包含它。

(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。

(36)继承只应被用来为特化层次结构建模。

(37)派生类必须知道基类,基类不应该知道关于它们的派生类的任何信息。

(38)基类中的所有数据都应当是私有的,不要使用保护数据。

电脑培训认为类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

(39)在理论上,继承层次体系应当深一点,越深越好。

(40)在实践中,继承层次体系的深度不应当超出一个普通人的短期记忆能力。

一个广为接受的深度值是6.(41)所有的抽象类都应当是基类。

三年java经验应该都会什么

没有什么应该要会什么的,看个人能学到什么程度。

如果一定要说会什么的话,最基本的Spring、Struts2、Hibernate、Oracle、JS、Jquery等使用及原理非常熟,对于性能优化、代码优化、服务器调优、设计模式也要有一定的认识,还要掌握一些企业常用的技术lucene、webservice、JBPM等。

对Java的认识和理解是一个长期的过程,但掌握了这些对java的最常见的应用也算学习了个大概,进入大多数公司都能游刃有余。

后面多考虑架构设计及底层的一些东西,目前大数据很火,可以关注下MapReduce、Hadoop等技术。