美文网首页@IT·互联网
重构心路历程:如何做好抽象与设计?

重构心路历程:如何做好抽象与设计?

作者: Mr_Puff | 来源:发表于2020-05-14 16:58 被阅读0次

    自“重构”一词被Martin Fowler在上世纪末提出以来,一直受到诸多软件开发人员的追捧,圈内人若是对重构不大关注,似乎是有些数典忘祖的意味。于是乎,圈内人无论自身水平如何都开始关注重构,开始动手“去做”;至于做得好不好,结果合理与否,很难有事实标准去衡量。

    越来越多的“网红重构”

    Martin Fowler在写《重构》一书时,明确提出了重构的几个目的:

    • 改进设计
    • 使得软件更易被人理解
    • Find Bugs
    • 提高开发速度

    可见重构的起点很明确--改进设计,OOP的出现为“软件设计“赋予了更深层的定义:”高内聚、低耦合“无人不知,无人不晓,可以被用于很多领域的设计工作上;然而对SOLID理解透彻的软件从业人员又有几何?

    重构不是一时冲动,也不是为了达成特定的业绩目标。我更希望它能够成为软件从业人员自身的基本素质,不必时时刻刻挂在嘴边。重构的特殊性使得其价值体现有很长的延迟,只有出于本能的重构才是纯洁的,如果带有任何利益相关的目的性,那么这个重构就是有污点的。

    如何改进设计?

    业务是根本。不论是多复杂的软件,其根本目的都是为了实现人的业务需求,因此软件世界与真实世界有很多的相似性。关键过程就在于,我们如何把人的需求翻译成软件模型呢?

    UML的出现为软件设计领域提供了事实标准,我们开始了解到了参与软件系统的一些关键角色;以及这些角色的依赖关系,甚至开始关注这些角色的状态变更。于是我们发现“抽象”极其重要,对于一个经常变化的业务需求,我们需要关注这些要点:

    • 基本流程和处理步骤是什么?
    • 有哪些关键角色参与了这个流程?
    • 这些角色自身有什么特点(属性)?
    • 这些角色是如何协同、合作(依赖、组合...关系)的呢?
    • 角色是否会发生状态变化(状态图)?

    弄清楚了以上的内容,就可以按照UML标准给出一系列的设计图,用于说明你的设计意图(此处不建议其他的表达形式,鉴于UML已经足够成熟和被认可),但这个设计意图并不一定是最优解。

    抽象与模式

    OOP的魅力就在于抽象与复用,抽象其本质是分离稳定不变的点,而复用则是为了应付软件系统的复杂性,提供足够的灵活性来扩展软件系统。任何软件系统与真实世界必然存在联系,我们不妨先脱离软件设计本身的理论,仅考虑真实世界的类似场景,看看这个场景中存在哪些不变的参与者。

    例如,我们在超市购物时,通常会有这样的场景:找到一辆购物车->选购商品->往收银台结算->付款打印小票。对应的,如果将这套业务搬到软件系统中,我们就会发现一些稳定出现的参与者:顾客(Customer),购物车(ShoppingCart),商品(Product),订单(Order),交易(Transaction),小票(Receipt)。
    再深入探究一下这些参与者的行为特征:顾客通常会找购物车,会浏览商品信息选择是否购买,结账时支付订单;购物车就比较单纯,只负责装添加的货物;商品能够展示价格和基本信息;顾客推购物车去结算的时候会产生订单,结算时就完成了一笔或多笔交易,交易完成以后顾客就拿到了小票。把这些参与者的行为特征(业务方法)和自身属性组合起来,我们就有了软件系统中对应的一个角色,通常我们把它称之为“领域对象”(Domain Object)。

    完成抽象之后,进一步关注这些领域对象之间的协同合作关系,此时我们就可以用上GOF的几十种设计模式(足够应付大多数场景)了。

    更为一般的设计方法

    并不是所有的场景都能非常明确地表明有多少参与者,这通常由业务需求在初期不明确且实现时缺少设计导致的,且大多数重构都是在这种场景下开展的。

    IPO,即Input-Process-Output,对应于软件系统中的输入、处理和输出。对于已经识别的重构场景,不妨先关注这三个点:

    • 输入,这些输入有什么共同特点,是怎么被构建的呢?
    • 处理,对输入做了什么处理呢?产生了多少个中间角色?一共有多少角色参与?这些角色又是怎么联系起来的呢?
    • 输出,处理完成之后,软件系统输出了什么?系统其它模块对这个输出如何使用?

    关注输入,可以提取到软件系统中关键的数据模型,针对其构建特点通常可以引入“构建型设计模式”;
    关注处理和输出,可以更清晰地找到关键的参与角色,引入合理的“结构型模式”来规范这些角色之间的交互方式;如果能把这些角色的行为再进行组织和分析,通常“行为型模式”就可以被引入了。

    什么是重构?

    《重构》一书的推出,使得我们越来越关注所谓的代码坏味道,出现这些坏味道的根本原因就在于软件系统的抽象与设计不合理。如果只是识别了这些坏味道,把书中的手段一一应用,似乎很难让人信服这是一次完整的重构。所谓的“网红重构”,大抵如此吧。

    总之,任何不关注改善设计和解读设计意图的重构都是鸡肋。

    注:

    • UML:Unified Modeling Language,一种开放的方法,用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。
    • 领域对象:领域驱动设计的关键术语
    • GOF设计模式:Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides合著的《Design Patterns: Elements of Reusable Object-Oriented Software》

    相关文章

      网友评论

        本文标题:重构心路历程:如何做好抽象与设计?

        本文链接:https://www.haomeiwen.com/subject/fihvnqtx.html