1700453720
List＜String＞list=new ArrayList＜String＞（）；
1700453721
1700453722
此时list的表面类型为List，是一个列表的抽象，而实际类型为ArrayList。在可能的情况下，尽量抽象表面类型，但也存在不必抽象的情况，比如工具类xxxUtils，一般是不需要接口或是抽象类的。
1700453723
1700453724
（3）任何类都不应该从具体类派生
1700453725
1700453726
如果一个项目处于开发状态，确实不应该有从具体类派生出子类的情况，但这也不是绝对的，因为人都是会犯错误的，有设计缺陷是在所难免的，因此只要是不超过两层的继承都是可以忍受的。特别是做项目维护时，基本上可以不考虑这个规则，为什么？维护工作基本上都是做扩展开发的，修复行为通过一个继承关系，覆写一个方法就可以修正一个很大的Bug，何必再去继承最高的基类呢？（当然这种情况尽量发生在不甚了解父类或无法获得父类代码的情况下）。
1700453727
1700453728
（4）尽量不要覆写基类的方法
1700453729
1700453730
如果基类是一个抽象类，而且这个方法已经实现了，那么子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会产生一定的影响。
1700453731
1700453732
（5）抽象不关注细节
1700453733
1700453734
接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确地实现了业务逻辑，同时在适当的时候对父类进行了细化，各司其职才能保证抽象的依赖完美实现。
1700453735
1700453736
依赖抽象的优点在小型项目中很难体现出来，例如在小于10个人月的项目中，使用简单的SSH架构，基本上不用费太大力气就可以完成，是否采用抽象依赖原则影响不大。但是，在一个大中型项目中，采用抽象依赖可以带来非常多的优点，特别是可以规避一些非技术因素引起的问题。项目越大，需求变化的概率也就越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果项目设计优良、代码结构清晰，人员变化对项目的影响则基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。
1700453737
1700453738
1700453739
1700453740
1700453742
编写高质量代码：改善Java程序的151个建议 建议150：抛弃7条不良的编码习惯
1700453743
1700453744
很多人错误地认为编码只是熟练手的事情，其实要成为优秀的编码人员就必须进行自我剖析，抛弃不良的习惯，展示自己优秀的编码能力。通常不良的编码习惯有很多种，这里列出7条编码者经常会犯的错误，提醒大家注意。
1700453745
1700453746
（1）自由格式的代码
1700453747
1700453748
如果我们不从一个团队角度出发，而是从程序员个体角度去看问题：A项目的风格和B项目的风格迥异，甚至是在同一个项目的不同类中风格也不同，不用缩进，不添加注释，想加接口就加个接口，不想加就不加，我们要的是“自由，自由，还是自由”。—这不是一个成熟的职业者应该具有的，我们应该保持自己的代码风格，即使它是错的，也比没有风格要好。
1700453749
1700453750
（2）不使用抽象的代码
1700453751
1700453752
这也算是IDE的便利性造成的习惯，一个业务类不进行抽象，直接进行编码，在需要修改时，要么依靠IDE批量重构，要么通过查找替换的方式重构，很方便，不是吗？而且，随着SSH的普及，“无抽象”编程进一步横行起来。要接口何用？想要修改的时候直接修改XML配置文件就可以了，要什么接口！系统间数据交互？序列化为XML传递，与接口何干？！
1700453753
1700453754
这是一种非常拙劣的习惯，抽象的意义不在于编码，而是在于对业务的理解，接口是对业务宏观的描述，而不是实现代码。
1700453755
1700453756
（3）彰显个性的代码
1700453757
1700453758
技术人员追逐最新的技术，这本是无可厚非的，但是新技术只能作为技术的一个方向，不适合立刻投入生产中，要知道一个项目的运行质量是远远高于代码质量的，不要为了一个新颖的API就在生产中尝试使用，不要做小白鼠。
1700453759
1700453760
这里介绍一个“最小惊诧原则”（Principle Of Least Surprise简称POLS，或者Principle Of Least Astonishment简称POLA），其意是说要使用最常见的，而不是最新颖的功能。在编码时，应寻找最常用的方法来实现，比如，同样有两个方法都能实现一个算法，选择那个最常用的，而不是那个别人一看就惊呼“哇哦，算法这么牛”的，让普通人都能看懂的代码才是最简洁的代码。
1700453761
1700453762
最小惊诧原则也同样适用于UI设计，当操作界面上两个元素冲突或重叠时，首选是那个不让用户感到吃惊的元素。
1700453763
1700453764
（4）死代码
1700453765
1700453766
可能是忘记删除的代码，也可能是故意保留的类似“到此一游”的签名代码，这些代码按照正常的执行逻辑是不可能被执行到，但是在某些未知情况下它就是执行了，此时就会产生严重的影响。
1700453767
1700453768
（5）冗余代码
1700453769
[
上一页 ]
[ :1.70045372e+09 ]
[
下一页 ]