打字猴:1.70045349e+09
1700453490 注释只是代码阅读的辅助信息,如果代码的表达能力足够清晰,根本就不需要注释,注释能够帮助我们更好地理解代码,但它所重视的是质量而不是数量。如果一段代码写得很糟糕,即使注解写得再漂亮,也不能解决腐烂代码带来的种种问题,记住,注释不是美化剂,不能美化你的代码,它只是一副催化剂,可以让优秀的代码更加优秀,让拙劣的代码更加腐朽。
1700453491
1700453492 注意 注释不是美化剂,而是催化剂,或为优秀加分,或为拙劣减分。
1700453493
1700453494
1700453495
1700453496
1700453497 编写高质量代码:改善Java程序的151个建议 [:1700438225]
1700453498 编写高质量代码:改善Java程序的151个建议 建议147:让接口的职责保持单一
1700453499
1700453500 一个类所对应的需求功能越多,引起变化的可能性就越大,单一职责原则(Single Responsibility Principle,简称SRP)就是要求我们的接口(或类)尽可能保持单一,它的定义是说“一个类有且仅有一个变化的原因(There should never be more than one reason for a class to change)”,那问题是什么是职责呢?
1700453501
1700453502 职责是一个接口(或类)要承担的业务含义,或是接口(或类)表现出的意图,例如一个User类可以包含写入用户信息到数据库、删除用户、修改用户密码等职责,而一个密码工具类则可以包含解密职责和加密职责。明白了什么是类的职责单一,再来看看它有什么好处。单一职责有以下三个优点:
1700453503
1700453504 (1)类的复杂性降低
1700453505
1700453506 职责单一,在实现什么职责时都有清晰明确的定义,那么接口(或类)的代码量就会减少,复杂度也就会减少。当然,接口(或类)的数量会增加上去,相互间的关系也会更复杂,这就需要适当把握了。
1700453507
1700453508 (2)可读性和可维护性提高
1700453509
1700453510 职责单一,会让类中的代码量减少,我们可以一眼看穿该类的实现方式,有助于提供代码的可读性,这也间接提升了代码的可维护性。
1700453511
1700453512 (3)降低变更风险
1700453513
1700453514 变更是必不可少的,如果接口(或类)的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,那就会对系统的扩展性、维护性都有非常大的帮助。
1700453515
1700453516 既然单一职责有这么多的优点,那我们该如何应用到设计和编码中呢?下面以电话通信为例子来说明如何实施单一职责原则:
1700453517
1700453518 (1)分析职责
1700453519
1700453520 一次电话通信包含四个过程:拨号、通话、回应、挂机,我们来思考一下该如何划分职责,这四个过程包含了两个职责:一个是拨号和挂机表示的是通信协议的链接和关闭,另外一个是通话和回应所表示的数据交互。
1700453521
1700453522 问题是我们依靠什么来划分职责呢?依靠变化因素,我们可以这样考虑该问题:
1700453523
1700453524 通信协议的变化会引起数据交换的变化吗?会的!你能在3G网络视频聊天,但你很难在2G网络上实现。
1700453525
1700453526 数据交互的变化会引起通信协议的变化吗?会的!传输2KB的文件和20GB的文件需要的不可能是同一种网络,用56KB的“小猫”传输一个20GB的高清影视那是不可行的。
1700453527
1700453528 (2)设计接口
1700453529
1700453530 职责分析确定了两个职责,首先不要考虑实现类是如何设计的,我们首先应该通过两个接口来实现这两个职责。接口的定义如下。
1700453531
1700453532 //通信协议
1700453533
1700453534 interface Connection{
1700453535
1700453536 //拨通电话
1700453537
1700453538 public void dial();
1700453539
[ 上一页 ]  [ :1.70045349e+09 ]  [ 下一页 ]