自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(17)
  • 收藏
  • 关注

原创 《EffectiveJava》读后感(第4章类和接口 第21条)

用函数对象表示策略有些语言支持函数指针(function pointer)、代理(delegate)、lambda表达式(lambda expression),或者支持类似的机制,允许程序把“调用特殊函数的能力”存储起来并传递这种能力。这种机制通常用于允许函数的调用者通过传入第二个函数,来指定自己的行为。Java中没有提供函数指针,但是可以用对象引用实现同样的功能。调用对象上的方法通常是执行该对象(that object)上的某项操作。然而,我们也可能定义这样一种对象,它的方法执行其它对象(other

2020-07-19 13:03:11 79

原创 《EffectiveJava》读后感(第4章类和接口 第20条)

类层次优于标签有时候,可能会遇到带有两种甚至更多种风格的实例的类,并包含表示实例风格的标签域。class Figure {enum Shape { RECTANGLE , CIRCLE } // Tag field - the shape of this figurefinal Shape shape; // These fields are used only if shape is RECTANGLEdouble length;double width; // This fie

2020-07-19 12:20:43 115

原创 《EffectiveJava》读后感(第4章类和接口 第18、19条)

接口优于抽象类首先类只允许一个继承,这个位置很宝贵,所以作为抽象类作为类型定义就受到了极大的限制。1. 现有的类可以很容易被更新,以实现新的接口。2. 接口是定义mixin的(混合类型)的理想选择。3. 接口允许我们构造非层次结构的类型框架。通过对你导出的每个重要接口都提供一个抽象的骨架实现类,把接口和抽象类的优点结合起来。接口的作用仍然时定义类型,但是骨架实现类接管了所有与接口实现相关的工作。设计共有接口一定要谨慎,因为接口一旦被公开,并且被广泛使用,再想改变这个接口几乎时不可能的了。接口通常

2020-07-11 00:24:49 85

原创 《EffectiveJava》读后感(第4章类和接口 第17条)

要么为继承而设计,并提供文档说明,要么就禁止继承首先该文档必须精确的描述覆盖每个方法所带来的影响。该类必须有文档说明它可覆盖的方法的自用型。关于文档的格言:好的API文档应该描述一个给定的方法做了说明工作,而不是描述它是如何做的。为了继承而进行的设计不仅仅设计自用模式的文档设计。为了使程序员能够编写出更加有效的子类,而无需承受不必要的痛苦,类必须通过某种形式提供适当的勾子(hook),以便能够进入到它的内部工作流程中,这种形式是可以精心选择的受保护的方法。对于为了继承而设计的类,唯一的测试方法就是编写

2020-07-11 00:06:45 99

原创 《EffectiveJava》读后感(第4章类和接口 第16条)

复合优先于继承继承是实现代码重用的有力手段,但它并非永远是完成这项工作的最佳工具。使用不但会导致软件变得很脆弱。在包的内部使用继承是非常安全的,在那里,子类和超类的实现都处在同一个程序的员的控制之下。对于专门为了继承而设计、并且具有很好的文档说明来说,使用继承也是非常安全的。本条目讨论的是实现继承(当一个类扩展另一个类的时候),并不适用于接口继承(当一个类实现另一个接口的时候)。与方法调用不同的是,继承打破了封装性。换句话说,子类依赖超类的实现细节,如果超类实现随着发行版本发生变化,子类就可能会被破坏,

2020-07-10 23:48:54 75

原创 《EffectiveJava》读后感(第4章类和接口 第13、14、15条)

使类和成员的可访问性最小化刚好够用的访问权限时最好的,这样可以尽可能的保护程序。工作上的代码权限,liux的权限也是同样的思想进行的。在公有类中使用访问方法而非公有域在类中变量应设为不可访问的,提供访问的方法即可。公有类中都不应该暴露可变的域。使可变性最小化尽量使类便可不可变,这样的好处是使类更加易于设计、实现和使用,它们不容易出错,并且更加安全。使类变得不可变需要遵循下面5条规则:不要提供任何会修改对象状态的方法。使所有的域都是final的。保证类不会被扩散,一般的做法就是把类变成fin

2020-07-06 00:04:13 78

原创 《EffectiveJava》读后感(第3章对于所有对象都通用的方法 第12条)

考虑实现Comparable接口这条大量的例子去解释一条就时跟标题一样,就是考虑实现Comparable接口。这章作者还有个强烈建议就是:强烈建议(x.compareTo(y) == 0) == (x.equals(y)),这并非规则,但尽量保持这条的实现。...

2020-07-05 22:08:10 69

原创 《EffectiveJava》读后感(第3章对于所有对象都通用的方法 第9、10、11条)

覆盖equals时总要覆写hashCode始终要覆盖toString简单来说这是初学者应当遵守的规则,牢牢记住就对了,并且一般大点的公司在代码提交的时候会通过自动扫描工具进行扫描并解决才能提交。

2020-07-05 21:11:27 56

原创 《EffectiveJava》读后感(第3章对于所有对象都通用的方法 第8条)

覆盖equals时请遵守通用约定类的实例本质上都是唯一的。不关心类是否提供了"逻辑相等"的测试功能。例如java.util.Random就不需要复写equals超类已经覆盖了equals,从超类继承过来的行为对于子类也是合适的。类是私有的或是包级私有的,可以确定它的equals方法永远不hi被调用。那么,什么时候应该覆盖Object.equals呢?如果对象具有自己特有的“逻辑相等”概念(不同于对象等同的概念),而且超类还没有覆盖equals以实现期望的行为,这时我们就需要覆盖equals。单

2020-07-05 21:06:29 104

原创 《EffectiveJava》读后感(第2章创建和销毁对象 第7条)

尽量避免使用终结方法终结方法通常是不可测的,也是很危险的,一般情况下是不必要的。使用终结方法会导致行为的不稳定,降低性能,以及不可移植性。当然,终结方法也有其可取之处,但根据经验应该避免使用终结方法,这也是公司考试时很容易考到的选择题。尽量比哦面使用Finalizer方法,因为低优先级易导致出现OOM的问题。另:创建和销毁对象会造成多余的性能消耗(约430倍)。应使用try-catah-finally显示总结,高效且一定执行。可以使用Finalizer作为安全网,或者终止非关键资源,否则不要使用。如果

2020-07-02 23:56:10 78

原创 《EffectiveJava》读后感(第2章创建和销毁对象 第6条)

消除过期的对象引用在java中有垃圾自动回收,,但时在过程中就会忽略内存管理的问题了。其实很多时候会有问题,这里引用书中的代码:public class Stack {private Object[] elements;private int size = 0;private static final int DEFAULT_INITIAL_CAPACITY = 16;public Stack() {elements = new Object[DEFAULT_INITIAL_CAPACITY]

2020-07-02 23:46:13 69

原创 《EffectiveJava》读后感(第2章创建和销毁对象 第5条)

避免创建不必要的对象一般来说,最好能重用对象而不是在每次需要的时候就创建一个相同功能的新对象。重用方式既快速,又流行。如果对象是不可变的,它就始终可以被重用。例如避免使用:String s = new String("stringette"); // Dont DO THIS改进为使用:String s = "stringette";这是一个简单且清晰明了的改进,并且性能提升很多。静态工厂可避免创建不必要的对象,且几乎优于构造器。使用静态块也可以使实例只初始化一次,大量调用的时候可以明显

2020-07-01 23:45:28 89

原创 《EffectiveJava》读后感(第2章创建和销毁对象 第4条)

通过私有化构造器强化不可实例化的能力简单来说就是工具类需要私有化构造器来防止被使用者实例化,这是在编程过程中老员工会在无意间传授的一个小技巧,但这个小技巧非常的有用,需要在代码开发中严格的遵守。java.lang.Math和java.util.Arrays都是这样做的。如果你企图通过做成抽象类来防止类被实例化是行不通的。该类可以被子类化,并且子类也可以被实例化。这种有个小小的副作用,就是私有化构造器后子类没有可访问的超类构造器可调用了。但这相对来说影响并不大,并且一般来说工具类就不是被设计来进行继承的

2020-06-30 23:27:47 66

原创 《EffectiveJava》读后感(第2章创建和销毁对象 第3条)

用私有的构造器或者枚举强化Singleton属性Singleton想必大家都是很熟悉的一个设计模式了,这个实际模式也是在实际开发中相当好上手且实际优化效果佳的设计模式。Singleton指仅仅实例化一次的类。Singleton通常被用来代表那些本质上唯一的系统组件,比如窗口管理器或者文件系统。使类成为Singleton会使它的客户端测试变得十分困难,因为无法给Singleton替换模拟实现,除非它实现一个充当其类型的接口。这里提供几个单例的实现模式:1、普通单例。这个单例最简单,但是会存在一系列的问题

2020-06-30 23:17:40 104

原创 《EffectiveJava》读后感(第2章创建和销毁对象 第2条)

遇到多个构造器参数时要考虑使用构建器(Builder设计模式)静态工厂和构造器有个共同的局限性:它们都不能很好的扩展到大量的可选参数。考虑用一个表示包装食品外显示的营养成分标签。这些标签中有几个域是必须的:每份的含量、每罐的含量以及每份的卡路里,还有超过20个可选域:总脂肪量、饱和脂肪量、转化脂肪、胆固醇、钠等等。大多数产品在某几个可选域中都会有非零的值。重叠构造器方式一般创建构造器会使用重叠构造器的方式,即首先创建一个只有必要参数的构造器,然后第二个构造器有一个可选参数,第三个构造器有两个可选参数

2020-06-30 00:42:33 63

原创 《EffectiveJava》读后感(第2章创建和销毁对象 第1条)

考虑用静态工厂方法代替构造器对于类而言,为了让客户端获取它自身的一个实例,最常用的方法就是提供一个共有的构造器。还有一种方法,类可以提供一个共有的静态方法,它只返回类的实例的静态方法。下面就是Boolean的简单示例。这个方法将boolean基本类型转换为Boolean对象:public static Boolean valueOf(boolean b){ return b ? Boolean.TRUE : Boolean.FALSE;}注意:静态方法和设计模式中的工厂方法模式不同,这里的静态方

2020-06-29 00:51:19 99

原创 《EffectiveJava》读后感(第1章 引言)

说明:本书作为本人在读关于EffectiveJava的读后感,目录以及内容顺序会完全按照书本原有的结构进行记录,以及本人对于书籍的一些自我想法的记录,主要作为分享和资料类的博客,令可加深自己对于书籍的理解和码友们的讨论。本文主要是对于各个章节进行精华的摘取,并加上自己的一些拙见。希望能帮助大家在课余学习或者是跳槽面试时增加一些自身价值的资本。Java 集合框架创办人,Joshua Bloch 领导了很多 Java 平台特性的设计和实现,包括 JDK 5.0 语言增强以及屡获殊荣的 Java 集合框架。20

2020-06-29 00:01:39 126

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除