设计原则 DRY 【don't repeat yourself】 不要一上来就强迫设计最好的接口，方法，函数。保持一定的扩展性即可。 写极致优秀的代码也不是一蹴而就。 顺序应该是， 1.写大量的业务代码，不考虑任何设计，满足当前需求； 2.业务代码无法支持业务新需求，每个需求稍有区别，但又不是完全新的，但旧的封装无法满足，只能封装新方法来实现变化的新需求，写法仍然是阶段一的思路。 3.厌倦了步骤二的过程，永远在重复写业务。已经能想到部分需求在旧的设计上，如果有扩展性的话，是不需要完全从新开发，比如抽象统一的接口，抽象好的数据库结构，用不同的文件或者不同的实体类扩展开发。抽象能力开始锻炼。 4.