软件架构设计箴言理解
如果你想对设计原则有更多的了解，可以参见这里面向设计原则理解和一些软件设计的原则。
4：首先考虑可维护，延伸性，事后优化
这里也是本文的起因，正如开篇所说，Donald Knuth 提到的：对软件的过早地优化是万恶的根源。在开发的时候我们不需要进行任何性能的优化，即使你认为这里可能存在性能的瓶颈，你需要考虑的更多的是设计的扩展和延伸性，以后的继续添加新功能和维护。对于用户需话要的需求，性能优化很多时候只是作为一个更好的体验存在。只有当真正出现性能瓶颈的时候，你才需要做性能的优化。一个可延伸可扩展，层次分明，代码清晰的模块，对于你的优化也是件容易的事情，在对项目后期对于项目的总体需求明白下你也有得到更多的优化方案。在重构模式中同样也提倡时候优化。过早的优化导致你的项目会越陷越深，到最后才知道用户其实根本不需要这么高的需求，或者是用户根本不常用的功能模块。优化也需要有标准，多少时间是用户能忍受的，目前是多少时间。往往用户对性能要求的只有那个少量常用的操作，而对于功能性需求的变更却是无止境的，维护成本却是高昂的。
最后说一句，经常有人说反射性能低下，对我们必须承认反射比其他方案性能是不好，但是我们有解决方案：缓存。在则说性能低下，是以什么什么标准？用户的接受程度？反射我们可以有其替代方案Emit，Expression tree。从反射，Expression tree，Emit的选择，其使用难度在提升，开发效率在增加，性能在改善。本人一般却倾向于Expression tree，两种剧中吧。
5：继承是为了多态而不是重用
OOP中可以编写一个类，然后我可以不断的继承重用去扩展新需求。这是类的重用，是全部的重用？重用这个词看上去也许更加的微妙。多态是面向对象的核心特征之一，也不记不清那里听到的：重用只是继承的附带功能。在我们的继承体系中不宜庞大如果一个拥有4,5层的继承体系，对你的理解也增加难度，而且集成体系必须是个干净的继承体系，满足LSP（里氏替换原则）：在所有用到父类的地方都可以替换为子类，还能正常准确工作。这就要求你继承更多的是修改扩展父类的行为，尽量避免状态。继承只是不要为了重用的为目的，在恰当的时机更好的办法是实现一个完全的类来替换不能满足现有需求的类。这也是oo原则第二原则吧，组合优先于继承。组合比如设计模式中的策略模式，你得到的是一个算法组合功能个数是一个笛卡尔积。但也是绝对的组合，只是优先，不是取代，软件和现实世界都是充满了矛盾的，就如开篇第一条“软件中唯一不变的就是变化”就是最大的矛盾，来自辩证唯物主义，你要做的是权衡。组合表述的是整体的替换，如策略模式模式的算法整体替换。继承是部分的少量的扩展修改行为，比如设计模式中的模版方案，在父类的流程控制下，部分步骤的修改，数据，事务的流转控制权在父类。这条在最后说一句：设计模式不是万能的，只是前人的优秀经验，是依赖于场景存在的，了解设计模式我觉得更重要的是其使用场景，在遇见同类场景的时候知道可以有这种模式作为解决方案或许更好，仅作为供你选择的解决问题方案。
6：用户的一切输入都是万恶的
用