1700448511
1700448512
}
1700448513
1700448514
}
1700448515
1700448516
//操作user表
1700448517
1700448518
class UserDao extends BaseDao＜String＞{
1700448519
1700448520
}
1700448521
1700448522
对于UserDao类，编译器编译时已经明确了其参数类型是String，因此可以通过反射的方式来获取其类型，这也是getGenricClassType方法使用的场景。
1700448523
1700448524
BaseDao和UserDao是ORM中的常客，BaseDao实现对数据库的基本操作，比如增删改查，而UserDao则是一个比较具体的数据库操作，其作用是对User表进行操作，如果BaseDao能够提供足够多的基本方法，比如单表的增删改查，那些与UserDao类似的BaseDao子类就可以省去大量的开发工作。但问题是持久层的session对象（这里模拟的是Hibernate Session）需要明确一个具体的类型才能操作，比如get查询，需要获得两个参数：实体类类型（用于确定映射的数据表）和主键，主键好办，问题是实体类类型怎么获得呢？
1700448525
1700448526
子类自行传递？麻烦，而且也容易产生错误。
1700448527
1700448528
读取配置问题？可行，但效率不高。
1700448529
1700448530
最好的办法就是父类泛型化，子类明确泛型参数，然后通过反射读取相应的类型即可，于是就有了我们代码中的clz变量：通过反射获得泛型类型。如此实现后，UserDao可以不用定义任何方法，继承过来的父类操作方法已经能满足基本需求了，这样代码结构清晰，可读性又好。我已将这种方式使用在多个项目中了，目前没有出现因为该反射引起的性能问题。
1700448531
1700448532
想想看，如果考虑反射效率问题，没有clz变量，不使用反射，每个BaseDao的子类都要实现一个查询操作，代码将会大量重复，违反了“Don’t Repeat Yourself”这条最基本的编码规则，这会致使项目重构、优化难度加大，代码的复杂度也会提高很多。
1700448533
1700448534
对于反射效率问题，不要做任何的提前优化和预期，这基本上是杞人忧天，很少有项目是因为反射问题引起系统效率故障的（除非是拷贝工的垃圾代码，这不在我们的讨论范围之内），而且根据二八原则，80%的性能消耗在20%的代码上，这20%的代码才是我们关注的重点，不要单单把反射作为重点关注对象。
1700448535
1700448536
注意 反射效率低是个真命题，但因为这一点而不使用它就是个假命题。
1700448537
1700448538
1700448539
1700448540
1700448542
编写高质量代码：改善Java程序的151个建议 第8章 异常
1700448543
1700448544
大成若缺，其用不弊。
1700448545
1700448546
大盈若冲，其用不穷。
1700448547
1700448548
——老子《道德经》
1700448549
1700448550
不管人类的思维有多么缜密，也存在“智者千虑必有一失”的缺憾。无论计算机技术怎么发展，也不可能穷尽所有的情景—这个世界是不完美的，是有缺陷的，完美的世界只存在于理想中。
1700448551
1700448552
对于软件帝国的缔造者来说，程序也是不完美的，异常情况随时都会出现，我们需要它为我们描述例外事件，需要它处理非预期的情景，需要它帮我们建立“完美世界”。
1700448553
1700448554
1700448555
1700448556
1700448558
编写高质量代码：改善Java程序的151个建议 建议110：提倡异常封装
1700448559
1700448560
Java语言的异常处理机制可以确保程序的健壮性，提高系统的可用率，但是Java API提供的异常都是比较低级的（这里的低级是指“低级别”的异常），只有开发人员才能看得懂，才明白发生了什么问题。而对于终端用户来说，这些异常基本上就是天书，与业务无关，是纯计算机语言的描述，那该怎么办？这就需要我们对异常进行封装了。异常封装有三方面的优点：
[
上一页 ]
[ :1.700448511e+09 ]
[
下一页 ]