![](https://img-blog.csdnimg.cn/20201014180756918.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
Effective java
文章平均质量分 60
请叫我青哥
所有文章无条件开放,顺手给个赞不为过吧
展开
-
第二十七条:消除unchecked类型的警告
当你遇到你不能消除的警告时,如果你能保证被警告的代码类型是什么,就可以使用(也只能使用这种方式)@SuppressWarnings(“unchecked”)注解来消除警告。但是当你不能确保其类型的时候,就不要使用这个注解消除警告,因为即使你在编译期间消除了警告,在运行时也可能会报出ClassCastException的异常。但是当你不能确保其类型的时候,就不要使用这个注解消除警告,因为即使你在编译期间消除了警告,在运行时也可能会报出ClassCastException的异常。原创 2024-07-25 21:31:29 · 300 阅读 · 0 评论 -
第二十六条:不要使用原始类型
有人会说,这样不是挺好的么,想放什么就放什么。我取数据应该怎么取?从这一章开始讲解关于泛型以及将泛型的好处最大化并将其负面影响最小化。这样的代码是不是可读性、可维护性实在是太差了!每日一问:为啥不要使用原始类型?使用原始类型是合法的,原创 2024-07-25 21:19:17 · 108 阅读 · 0 评论 -
第二十四条:与静态类相比,优先选择静态成员类
简而言之,有四种不同的嵌套类,各有应有场景:如果一个嵌套类需要在单个方法之外仍然是可见的,或者他太长了,不适合方法内部,就应该使用成员类。否则,就做成局部类。嵌套类有四种:静态成员类(static member class)、非静态成员类(nonstatic member class)、匿名类(anonymous class)和局部类(local class)。如果嵌套类的实例可以在他外围类的实力之外独立存在,这个嵌套类就必须是静态成员类:在没有外围实例的情况下,要想创建非静态成员类的实例是不可能的。原创 2024-07-20 21:52:27 · 373 阅读 · 0 评论 -
第二十五条:将源文件限制为单个顶层类
如果你足够幸运用命令javac Main.java Dessert.java编译这个程序,那么编译会失败,而且这个编译器将会告诉你:你已经多次定义了Utensil and Dessert类。确实如此,因为编译器将会编译 Main.java,而且当它看见Utensil(它早于Dessert的引用)的引用,它将在Utensil.java中寻找这个类,然后发现了Utensil和Dessert。解决这个问题,就像分解这个顶层类(在我们例子情形中,Utensil和Dessert)到不同的源文件这么简单。原创 2024-07-20 21:35:25 · 231 阅读 · 0 评论 -
第二十二条:接口仅用于定义类型
更糟糕的是,它代表了一种承诺:如果在将来的发行版本中,这个类被修改了,它不再需要使用这些常量了,它依然必须实现这个接口,以确保二进制兼容性。如果非final类实现了常量接口,它的所有子类的命名空间也会被接口中的常量所“污染”。使用这些常量的类实现这个接口,以避免用类名来修饰常量名。如果这些常量与某个现有的类或者接口紧密相关,就应该把这些常量添加到这个类或者接口中。因此,类实现了接口,就表明客户端可以对这个类的实例实施某些动作(接口中定义的方法)。当类实现接口时,接口就充当可以引用这个类的实例的。原创 2024-07-15 21:11:18 · 285 阅读 · 0 评论 -
第二十一条:为传诸后世而设计接口
Java8引入了默认方法,目的就是允许向现有的接口中添加方法。但是向现有的接口中添加新方法还是充满风险的。在存在默认方法的情况下,一个接口的现有实现可能在编译时没有错误或警告,但在运行时却失败了。尽管默认方法现在已经成为java平台的一部分,但谨慎设计接口仍然是及其重要的。虽然接口在发布之后再修正一些缺陷也是有可能的,但千万不要寄希望于此。还要注意的是,默认方法不支持从接口中删除方法或改变现有方法的签名。原创 2024-07-15 20:51:10 · 259 阅读 · 0 评论 -
第二十条:与抽象类相比,优先选择接口
总而言之,要定义支持实现的类型,原创 2024-07-04 21:23:44 · 858 阅读 · 0 评论 -
第十九条:要么为继承而设计并提供文档说明,要么就禁止继承
如果你决定在一个为了继承而设计的类中实现Serializable,并且该类有一个readResolve或者writeReplace方法,就必须使readResolve或者writeReplace成为受保护的方法,而不是私有的方法。如果类是为了继承而被设计的,无论实现这其中的那个接口通常都不是一个好主意,因为他们它一下实质性的负担转嫁到扩展这个类的程序员的身上。当设计一个可能被广泛使用的用于继承的类时,要意识到,我们对写在文档中的方法的自身使用情况,以及隐含在受保护的方法和字段的实现决策做出了永久性的承诺。原创 2024-06-26 22:08:38 · 350 阅读 · 0 评论 -
第十七条:使可变性最小化
不可变的类变成 final 的另 一种办法就是,让类的所有构造器都变成私有的或者包级私有的,并添加公有的静态工厂( static factory )来代替公有的构造器(详见第 1 条)。虽然从技术上讲,允许不可变的类具有公有的 final域,只要这些域包含基本类型的值或者指向不可变对象的引用,但是不建议这样做,因为这样会使得在以后的版本中无法再改变内部的表示法。你应该总是使 一些小的值对象。这种技巧可以很好地工作,因为对象是不可变的,它的不可变性保证了这些计算如果被再次执行,就会产生同样的结果。原创 2024-06-17 21:57:24 · 470 阅读 · 0 评论 -
第十三条:谨慎使用clone方法
不到万不得已,不要轻易使用clone方法,容易使代码变得不稳定原创 2024-06-04 21:19:28 · 207 阅读 · 0 评论 -
第九条:与try-finally相比,首选try-with-resources
在处理必须关闭资源时,应该总是选择try-with-resources,这样得到的代码更短、更清晰,生成的异常也更有价值。原创 2024-05-23 21:30:14 · 119 阅读 · 1 评论 -
第4条:通过私有构造器强化不可实例化的能力
很多人第一时间会有疑问,java中为啥防止类被实例化?new一个类用get set实在太爽了,为啥不给new?原创 2024-05-09 21:46:24 · 392 阅读 · 1 评论 -
Effective java 第一章 引言
术语“导出的API”(exported API),或者简单地说API,是指类、接口、构造器(constructor)、成员和序列化形式 (serialized form),程序员通过它们可以访问类、接口或者包。使用API编写的员被称为 API 的用户(user),在类的实现中使用了 API的类被称为该API的客户端(client)。不严格地讲,一个包的导出 API是由该包中的每个公有(public)类或者接口中所有公有的或者受保护的 (protected)成员和构造器组成。签名不包括方法的返回类型。原创 2023-11-21 19:41:46 · 48 阅读 · 0 评论 -
Effective java 阅读感想及笔记
从事java两年多时间,但对于系统结构还是认为不是太懂,刚好同事推荐了这本《Effective java》,之前一直在忙没有整理,现阶段到明年,这边会系统整理好笔记,直到更新整本书,当然笔记中应该会出现错误,也请读者及时发现指正。原创 2023-11-21 19:01:21 · 41 阅读 · 0 评论