- 博客(19)
- 收藏
- 关注
RSS订阅原创 Glide3.5 初探
使用示例GlidewithContext contextRequestManagerRetrievergetContext contextRequestManagerRetrieversupportFragmentGetContext context FragmentManager fmRequestManagerRetrieverfragmentGetContext context an
2018-01-24 11:11:03
311
原创 第18条~第19条
第18条：接口优于抽象类众所周知，java中提供了接口和抽象类两种机制来定义允许多个实现的类型，这一条主要就在讨论这两者之间的优劣。相比于抽象类而言，接口会更加的灵活，如果一个类需要扩展一个新的接口，那么只需要多增加一个接口的实现即可。但是抽象类就无法这么做，因为java语言中不允许多继承，而且在抽象类中增加一个抽象方法会影响到实现它的所有子类，所以扩展抽象类的抽象方法需要格外的慎重。接口的灵活性还
2018-01-02 20:25:34
257
原创 针对DataBinding的RecyclerViewAdapter
对于DataBinding这个库相信大家都很熟悉了，今天我就为大家带来一个针对DataBinding封装的供RecyclerView使用的Adapter基类，当然也还有很多不足的地方，比如不支持多种类型的Model与多种类型布局等，欢迎大家多提意见与建议。本次的封装有以下几个优点：代码量少，封装逻辑简单，易于修改将模板代码的量尽量减少，能专注于业务逻辑结合DataBinding，去除繁琐的控件
2017-12-05 09:33:29
416
原创 第14条~第17条
第14条：在公有类中使用访问方法而非公有域一个类应该将自身的数据私有化，并向外暴露 getter/setter 方法，使外部类通过其来 访问/修改 数据，这是为了保留将来改变这个类内部表示的灵活性。但如果这个域是不可变的，那么直接将其暴露在外的危害就会比较小一些，但是在读取这个数据时，依然无法在类中采取辅助操作。第15条：使可变性最小化不可变类是指该类每个实例中包含的所有信息都必须在创建时就提供，而
2017-06-14 19:18:41
252
原创 第13条：使类和成员的可访问性最小化
第13条：使类和成员的可访问性最小化在程序设计中，封装（信息隐藏）是一个判断程序模块设计的一个重要指标。良好的封装是实现程序模块化的关键因素。而在Java语言中，使用了访问控制机制来帮助程序更好的实现封装。良好的信息隐藏可以更好的实现程序的模块化，降低各个模块之间的耦合程度，加快开发的速度。在进行开发时，我们应遵循这样两条准则：尽可能的使每个类或成员不被外界访问。通俗的说，就是对于一个方法或变量，
2017-06-12 17:03:04
258
原创 第12条：考虑实现Comparable接口
第12条：考虑实现Comparable接口如果一个类实现了Comparable接口，就代表着它的实例具有内在的排序关系。先来看看Comparable接口：public interface Comparable<T> { public int compareTo(T o);}可以看到，Comparable接口中只有compareTo一个方法，这个方法不但允许进行等同性比较，而且可以进行顺序比
2017-04-18 11:24:25
352
原创 第11条：谨慎地覆盖clone
第11条：谨慎地覆盖clone调用clone()方法需要对象实现Cloneable接口，但是这个接口有着许多缺陷。最主要的缺陷在于，Cloneable接口中不包含任何方法，而Object中的clone方法是protect的，也就是说如果一个类只是继承了Cloneable接口，但是却没有重写clone()方法，那么对于这个类的对象，clone()方法依然是不可用的。既然Cloneable接口中没有任何
2017-04-10 16:10:01
429
原创 第10条：始终要覆盖toString
第10条：始终要覆盖toStringtoString的通用约定指出，被返回的字符串应该是一个“简洁的，但信息丰富，并且易于阅读的表达形式”，并且进一步指出“建议所有的子类都覆盖这个方法”。Object中提供了toString方法的一个默认实现，它的返回结果以类的名称，一个”@”符号，以及hash码组成，例如”PhoneNumber@163b91”。这样产生的信息令人难以理解，在实际应用中，toStr
2017-04-05 17:27:08
211
原创 第9条：覆盖equals时总要覆盖hashCode
第9条：覆盖equals时总要覆盖hashCode在每一个覆盖equals方法的类中，都必须覆盖hashCode方法，如果不这么做，会导致这个类无法结合所有基于散列的集合的正常使用，如HashMap，HashSet，Hashtable。Object规范中有这么一条： 如果两个对象根据equals(Object)方法比较是相等的，那么调用这对象中任意一个对象的hashCode方法都必须产生同样的整
2017-03-22 15:25:20
307
原创 第8条：覆盖equals时请遵守通用约定
第8条：覆盖equals时请遵守通用约定覆盖equals方法看起来非常简单，但是很容易导致错误，并且造成严重后果。那么，什么时候应该覆盖Object.equals呢？一般情况下，如果对于一个类的两个对象，我们想要关注的是它的值是否相等，而不是是否指向同一个类，就可以这么做。但是如果使用了单例模式。在覆盖equals方法时，应注意以下的规范，这些规范不是必须的，但是如果违反，当其它的对象去使用这个对象
2017-03-17 14:31:22
190
原创 第7条：避免使用终结方法
第7条：避免使用终结方法终结方法（finalizer方法）： Java提供finalize()方法，垃圾回收器准备释放内存的时候，会先调用finalize()。书中对于终结方法有着这样的评价： 终结方法（finalizer）通常是不可预测的，也是很危险的，一般情况下是不必要的。终结方法存在几个问题：终结方法不能保证会被及时执行，因为从一个对象变得可以清除到其被虚拟机回收，这其中的时间是
2017-03-15 14:50:41
200
原创 第6条：消除过期的对象引用
第6条：消除过期的对象引用Java语言相较于C与C++一个非常大的区别便是具有自动垃圾回收的功能。而这有时会给我们一个错觉，那就是不需要再考虑内存管理这方面的事情了，这种看法明显是错误的，比如下面这段代码：public class Stack { private Object elements[] elements; private int size = 0; public O
2017-03-15 11:46:31
201
原创 第4条：通过私有构造器强化不可实例化的能力
第4条：通过私有构造器强化不可实例化的能力有的时候，我们需要编写只包含静态方法和静态域的类，这样的类不需要被实例化。但是在缺少构造方法的时候，编译器会自动提供一个公有的，无参的构造方法。有一种解决方式是将类写为抽象类来避免被实例化，但是这种做法非常不好，因为这样会误导他人，以为这种类是专门为了继承而设计的。还有一种方式就是让这个类包含一个私有的构造方法：public class UtiltyClas
2017-03-13 13:44:06
239
原创 第3条：用私有构造器或者枚举类型强化Singleton属性
第3条：用私有构造器或者枚举类型强化Singleton属性Singleton即单例，指仅仅会被实例化一次的类。通常使用的构建单例的方法：public static final String a = "123";但是这个方法有一个小问题，就是享有特权的客户端可以使用AccessibleObject.setAccessible方法，通过反射机制来调用私有构造器。这种风险可以通过修改构造器，在创建第二个实
2017-03-13 13:43:47
206
原创 第2条：遇到多个构造器参数时要考虑用构建器
第2条：遇到多个构造器参数时要考虑用构建器（Builder）静态工厂与构造器都有一个局限性：不能很好地扩展到大量的可选参数。如果使用构造器来创建实例，便需要大量的构造方法，例如：public class NutritionFacts { private final int servingSize; // (mL) required private final
2017-03-13 13:43:26
202
原创 第1条：考虑用静态工厂方法代替构造器
第1条:考虑使用静态工厂方法代替构造器Boolean类中的静态工厂方法public static Boole valueOf(boolean b){ return b ? Boolean.TRUE : Boolen.FALSE;}优点静态工厂方法可以自由的使用名称，可阅读性更高，使用时更为直观。而构造函数中不同构造器只能通过不同的参数来进行区分，容易造成混淆。不需要在每一次调用时都创建
2017-03-13 13:42:33
223
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人