1700448435
1700448436
}
1700448437
1700448438
public void initPassword（）{
1700448439
1700448440
/*初始化密码*/
1700448441
1700448442
}
1700448443
1700448444
public void initJobs（）{
1700448445
1700448446
/*初始化工作任务*/
1700448447
1700448448
}
1700448449
1700448450
}
1700448451
1700448452
UserPopulator类中的方法只要符合基本方法鉴别器条件即会被模板方法调用，方法的数据量也不再受父类的约束，实现了子类灵活定义基本方法、父类批量调用的功能，并且缩减了子类的代码量。
1700448453
1700448454
如果读者熟悉JUnit的话，就会看出此处的实现与JUnit非常类似，JUnit4之前要求测试的方法名必须是以test开头的，并且无返回值、无参数，而且有public修饰，其实现的原理与此非常相似，读者有兴趣可以看看JUnit的源代码。
1700448455
1700448456
注意 决定使用模板方法模式时，请尝试使用反射方式实现，它会让你的程序更灵活、更强大。
1700448457
1700448458
1700448459
1700448460
1700448462
编写高质量代码：改善Java程序的151个建议 建议109：不需要太多关注反射效率
1700448463
1700448464
反射的效率是一个老生常谈的问题，有“经验”的开发人员经常使用这句话恐吓新人：反射的效率是非常低的，不到万不得已就不要使用。事实上，这句话的前半句是对的，后半句是错的。
1700448465
1700448466
反射的效率相对于正常的代码执行确实低很多（经过测试，相差15倍左右），但是它是一个非常有效的运行期工具类，只要代码结构清晰、可读性好那就先开发起来，等到进行性能测试时证明此处性能确实有问题时再修改也不迟（一般情况下反射并不是性能的终极杀手，而代码结构混乱、可读性差则很可能会埋下性能隐患）。我们看这样一个例子：在运行期获得泛型类的泛型类型，代码如下：
1700448467
1700448468
class Utils{
1700448469
1700448470
//获得一个泛型类的实际泛型类型
1700448471
1700448472
public static＜T＞Class＜T＞getGenricClassType（Class clz）{
1700448473
1700448474
Type type=clz.getGenericSuperclass（）；
1700448475
1700448476
if（type instanceof ParameterizedType）{
1700448477
1700448478
ParameterizedType pt=（ParameterizedType）type；
1700448479
1700448480
Type[]types=pt.getActualTypeArguments（）；
1700448481
1700448482
if（types.length＞0＆＆types[0]instanceof Class）{
1700448483
1700448484
//若有多个泛型参数，依据位置索引返回
[
上一页 ]
[ :1.700448435e+09 ]
[
下一页 ]