重构8-Replace Inheritance with Delegation(委托替换继承)

继承的误用十分普遍。它只能用于逻辑环境,但却经常用于简化,这导致复杂的没有意义的继承层次。看下面的代码:

public class Sanitation{     public String WashHands(){         return "Cleaned!";}}  public class Child extends Sanitation{}

在该例中,Child并不是Sanitation,因此这样的继承层次是毫无意义的。我们可以这样重构:在Child的构造函数里实现一个Sanitation实例,并将方法的调用委托给这个实例。如果你使用依赖注入,可以通过构造函数传递Sanitation实例,尽管在我看来还要向IoC容器注册模型是一种坏味道,但领会精神就可以了。继承只能用于严格的继承场景,并不是用来快速编写代码的工具。

public class Sanitation {    public String WashHands() {        return "Cleaned!";}}public class Child {    private Sanitation Sanitation;//getter setterpublic Child() {        Sanitation = new Sanitation();}    public String WashHands() {        return Sanitation.WashHands();}}

来自为知笔记(Wiz)

时间: 2024-10-05 05:42:50

重构8-Replace Inheritance with Delegation(委托替换继承)的相关文章

Replace Inheritance with Delegation

[Replace Inheritance with Delegation]

5. window.location.href/replace/reload()--页面跳转+替换+刷新

1.window.location=url; window.location 对象用于获得当前页面的地址 (URL),并把浏览器重定向到新的页面. 一.最外层top跳转页面,适合用于iframe框架集 top.window.location.href("${pageContext.request.contextPath}/Login_goBack"); ===================================================================

window.location.href/replace/reload()/页面跳转+替换+刷新

一.最外层top跳转页面,适合用于iframe框架集 top.window.location.href("url"); ============================================================================================ 二.window.location.href和window.location.replace的区别 1.window.location.href="url":改变u

Inheritance Of Python 类的继承

Inheritance OOP三要素之一,继承 人类和猫都继承自动物类. 个体继承自父母,集成了父母的一部分特征. 在面向对象的世界中,从父类继承,就可以直接拥有弗雷德属性和方法,这样可以减少代码,多复用.子类可以定义自己的属性和方法. 类的继承 对于python来讲,所有的祖先都是object,所有的类都继承自object class Animal: def __init__(self, name): self._name = name @property def name(self): re

《重构——改善既有代码的设计》读书笔记

重构--改善既有代码的设计 1 重构概述 1.1 重构的概念(What) Refactoring 名词:对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低修改成本. 动词:使用一系列重构方法,在不改变软件可观察行为的前提下,调整其结构. 1.2 为什么要重构(Why) 改进软件设计 提高代码质量和可读性,使软件系统更易理解和维护 帮助尽早的发现缺陷 提高编程速度 1.3 何时重构(When) 何时重构: 1)随时随地进行. 2)三次法则:第一次做某件事只管去做:

重构-----改善既有代码的设计

1重构原则 1.1 定义: 1).调整软件内部结构,目的是在不改变软件软件可查行为前提下,提高其可理解性,降低其修改成本. 2).使用一系列重构准则,在不改变软件可查行为前提下,调整其结构 1.2 何时重构 1).三次法则 2).添加功能时 3).修补错误时 4).复审代码时 1.3 何时不该重构 1).代码太乱,重构效率低于重写效率时 2).项目接近期限时停止重构 2.代码的坏味道 2.1 Duplicated Code 2.2 Long Method 2.3 Large Class 2.4

《重构—改善既有代码的设计》笔记

为什么要重构 改进软件设计,消除重复代码 保持代码易读.易修改 提高编程速度(良好设计师维持软件开发速度的根本) 发现BUG 什么时候重构 事不过三,三则重构(三次法则) 添加功能时一并重构 修改错误时一并重构 复审代码时一并重构 问题代码 重复的代码 过长函数 过大类 过长参数列表 发散式变化 霰弹式修改 依恋情节 数据泥团 基本型别偏执 switch惊悚现身 冗赘类 夸夸其谈未来性 令人迷惑的暂时值域 过度耦合的消息链 中间转手人 狎昵关系 异曲同工的类 不完美的程序库类 纯稚的数据类 被拒

重构-坏代码的味道

代码的坏味道 何时必须重构?没有任何标准能比得上一个见识广博者的直觉.而某些迹象,则会指出“这里有可以用重构解决的问题”,一共22条坏代码味道. Duplicated Code(重复代码) 如果你在一个以上的地点看到相同的程序结构,那么可以肯定,将它们合而为一,程序会变得更好. 最单纯的重复代码就是,同一个类的两个函数含有相同的表达式.这时需要采用Extract Method(提取方法)提取重复代码. 另一个常见的情况是,同个父类的两个子类内含有相同表达式.这是需要使用Extract Metho

转:Bad Smell重构和设计的标准

Bad Smell重构和设计的标准.——与其无尽的等待完美的设计,不如立刻着手实现可行的设计,然后再在设计出现臭味的时候重构实现! 食品有做得好不好之分.其中一个重要的指标就是保质期.好的食品,保质期就长,坏的食品保质期就短.对于代码来说也一样.也有一个保质能力的问题.好的代码,入口芬芳.坏的代码早早就变质了,而且随着时间的推移越来越臭,直到最后,我们只好把它扔掉,虽然它也曾经是我们花钱买来的…… 比如说,我们接到一个项目,我们经过思考,获得了一个可行的设计方案,然后着手实现.此时,可能有一个小