当你遇到一个工程, 子类的大部分功能相似,只有少数几个是不相同的. 相同的可以通过继承获得,不同的,在基类中定义virtual函数,在子类中分别实现它.
模板方法模式:定义一个操作中的算发的骨架,而将一些步骤延迟到子类中.模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
使用深拷贝:
1.先写基类的函数,将基类函数,定义为virtual
2.基类函数中有clone函数
3.clone函数在子类中实现时,是返回子类的this指针.
4.在子类中,实现其他函数
不举栗子了..反正这就是一篇关于纯虚函数的举例,网上很多的.
模板方法模式是通过把不变行为搬移到超类,去除子类中的重复代码来体现它的优势.
模板方法就是提供了一个很好的代码复用平台. 因为有时候, 我们会遇到由一系列步骤构成的过程需要执行. 这个过程从高层次上看是相同的. 但有些步骤的实现可能不同. 这时候, 我们通常就应该要考虑用到模板方法模式了.
即, 当碰到这个情况, 当不变的和可变的行为在方法的子类实现中混合在一起的时候, 不变的行为就会在子类中重复出现. 党我们通过模板方法模式把这些行为搬移到单一的地方,这样就帮助子类摆脱重复的不变行为的纠缠.
LoD迪米特法则/最少知识原则: 如果两个类不必彼此直接通信, 那么这两个类就不应当发生直接的相互作用. 如果其中一个类需要调用另一个类的某一个方法的话, 可以通过第三者转发这个调用.
迪米特法则的根本思想,是强调了类之间的松耦合. 类之间的耦合越弱, 越有利于复用, 一个处在弱耦合的类被修改, 不会对有关系的类造成波及, 也就是说, 信息的隐藏促进软件的复用.
个人对这句话的理解是,可以通过生成基类的指针,调用子类的方法.
外观模式: 为子系统中的一组接口提供一个一致的界面, 此模式定义了一个高层接口, 这个接口使得这一子系统更加容易使用.
外观模式完美地体现了依赖倒转原则和迪米特法则的思想. 所以是非常常用的模式之一.
首先, 在设计初期阶段, 应该要有意识的将不同的两个层分离. 经典三层架构, 需要考虑在数据访问层和业务逻辑层,业务逻辑层和表示层的层与层之间建立外观模式. 增加外观模式可以提供一个简单的接口, 减少它们之间的依赖. 第三,在维护一个遗留的大型系统时, 可能这个系统已经非常难以维护和扩展了, 但因为它包含非常重要的功能,新的需求开发必须要依赖于它. 此外用外观模式也是非常合适的. 为新系统开发一个外观模式类,类提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口. 让新系统与外观模式对象交互, 外观与遗留代码交互所有负责的工作.
