关于软件设计方面的想法

|--    为何需要继承,组合或者其他重构方案
1.代码具有相似性, 说明有可能存在内部关联;
2.选择继承还是组合, 和代码的相似性没有直接关系, 最终的选择取决于实际问题中相似代码的真正关系;
3.对现成的问题, 解决代码重复的方案不止一种, 并且在没有加入新的需求之前无法判断哪种方案更好, 因为每一种都已经确保当前项目可以良好运行. 所谓评价软件设计的优劣, 不在于对当前问题的解决策略, 因为每一个既有的问题都是具备特殊性的问题, 无论解决方案如何罕见, 都是符合要求的. 但基于需求的改变是客观存在这一事实, 任何对设计的评判都必须延长到修改、扩展以及维护期.
4.构架设计就是预见设计. 原则上不能将多个问题归结为一类问题, 并用相似的方案解决.
5.继承描述的是稳定的关系, 和代码的相似性无关, 甚至和面向对象思想无关.
    假设有一很普遍的继承关系:
        Animal -> Cat
    通常这样设计的依据是, Cat 这一对象在"现实生活"中是关系紧密的继承关系, 而如果程序中并不使用 Cat 的 Animal 属性, 而将其归结为 "C" 开头的单词, 或者仅仅使用其宠物的特性, 就不需要 Animal 参与了. 强行归入 Animal 可能反而增加设计复杂度.
6.两个在现实生活中理所当然地隶属的类, 在特定的项目里可能完全无关. 之所以通常设计为继承, 完全是借用了现实经验, 这样在绝大多数情况下能很好地解决问题, 但这两者并非生来就有义务地关联.
7.在指导设计时, 项目实际可能的变化要优先于现实生活经验提供的参考.
8.当然实际问题基本上不可能超出现实生活的范畴. 但即使这样仍有很多现实版本可以参考. 如果这是个非常规的版本, 用定向思维就可能导致设计出错.
9.因此设计的目的有时候解决的是该类问题属于哪种现实镜像.
10.基于"需求"而不是基于"现实"设计.
11.项目是从现实中各种镜像中有选择地采用和筛选之后合并形成的问题, 严格意义上没有现实的参考.
12.相对于"继承",组合则用于将来很可能的不再关联的重复代码, 属于松散的"耦合".
13."继承"和"组合"用于应对将来可能出现的两种新需求的情况:
    很可能继续出现同类的对象;
    很可能在原来已经重复的代码上出现特有代码, 打乱原有的相似性.
14.因此"组合"并不绝对优先于"继承", 要看未来的变化更有可能一那种形式出现.