用与不用

构成软件或模块最重要的类别用继承，其他的类别用组合。能用单继承树绝不用多个，能用方法搞定的，不另外加类。

类和对象适合描述复杂的逻辑体系，当你试图概念化，抽象化复杂逻辑的时候，类提供了对概念的实体支撑。概念一定是对逻辑的简化，而不是为了概念而概念。

概念本身也越少越好，越简要越好，继承和组合构成的概念体系，继承的使用更加复杂，也更为凶险，不可不慎。继承树一定是对概念本身的简化，如果不是，干脆就别用。

这些东西，理解，使用，构建，都要成本，如果不能简化逻辑本身，那就是在搞破坏。

 

很多语法糖实际上缺乏使用场景。比如c#的属性。属性最好不要大用，不要在赋值或取值的同时做什么额外的事情。写写日志可以，可以当作面向方面编程的一个另类用法。

人的记忆是有限的，方法与人的逻辑贴合程度是最好的，属性用的太深入了，容易把属性和方法混杂，这其实不好。对于复杂的继承体系而言，方法归方法，字段归字段是最好的，清清楚楚，方法的话你知道它是虚的，可以覆写的，字段你知道有一个变量在那里。重用的最佳体验就是把同样的逻辑方法化，方法体系化。属性混同了方法和字段，混同了变量和逻辑，除了你要故意做出少数对外的逻辑，比如Datetime.Now, 给第三方使用者以逻辑上的简化和愉悦外，对开发人员自身而言，只会增加逻辑的负担，搞出来一些假的方法，你在实际组织逻辑的时候还要在头脑中还原他们。

属性是给公共程序集输出类用的。属性提供了一种更友好的使用者接口，方便对逻辑不关心不熟悉的人。如果是自己开发程序，不要用属性，直接用字段。

 

语法糖如果不成体系，不要使用。业务会有常用逻辑和不常用的逻辑，如果是不常用的逻辑，然后使用了本身不成体系的语法糖，会加重理解和维护的负担。宁愿绕远，保持程序风格的统一，很重要。

 

太早的和太晚的重构都不是好事情。无论是重构也好，新写程序也好，首先，从逻辑上走通，然后就是写代码，提取方法，反复拆装构造，简化合并逻辑，构造对象树，消除明暗bug，完善体系线索，分曹治事，熟悉自己创造的体系，在记忆和使用中体悟利弊，然后再改进，简化。螺旋上升。有时候要放弃一些构思，或是取舍一些结构，或是等待一些结果，因为时间和精力最经济的考虑。要有计划的持久，有计划的吃苦，但忌讳浪战，虽有一时之得，难以持久。程序所需与心中所欲实不和的时候，写不出好程序。一定要为了伟大的成绩和收获编程，为了省力或多力编程，不要为了虚幻的学习，进步编程。表面上目标一致，实则名实不合，心中理解与手下代码都会似是而非，过度设计。

 

要花足够长的时间，在持续改进中使劲，而不是过度追求速度和量。好的功能都不是现成的，好的开发流程涉及方方面面的指标，追求体系的胜利，更近似于战略行为，而不是战术行为。所以，若干窍门，若干注意事项之类的热门书，多半价值不大。