大话重构之原来反OO天天见

在OO（面向对象）时代长大的小伙伴们一定记得：

面向对象的基石：把数据和依赖该数据的行为封装在一起。

但我们经常遇到一个类依赖其它类的数据的情况。不多的话，正常，对象间势必存在交互，毕竟完全独立的类无法构建出复杂的业务系统。

太多依赖外部数据的话，可能是问题，也可能不是问题，而是故意为之。嗯？这不是反OO吗？莫急，先来看看两个例子，然后分析隐藏在后面的东西。

特性依恋

先看太多外部数据依赖是问题的情况，重构里面管这叫 特性依恋 。顾名思义，太过迷恋别人的东西。

case class Product(name: String, price: Float)

case class OrderItem(count: Int, product: Product)

case class Order(items: List[OrderItem]) {

  def cost: Float = {

    items.sum(item => item.count * item.product.price)

  }

}

每个订单项的花销之和，就是订单的花销。问题异常明显，订单项的花销是在订单层次计算的，导致订单过度依赖订单项的数据。

case class OrderItem(count: Int, product: Product) {

  def cost = count * product.price

}

case class Order(items: List[OrderItem]) {

  def cost = items.sum(_.cost)

}

订单项的花销，订单项自己计算，订单的花销是所有订单项花销之和。代码比说明书清楚多了，OK。

行为构建在数据之上，对象作为载体封装二者。从上面的例子可以看出，不能错位，属于订单项的行为就不要放在订单里面，如此才能提高代码的可维护性和可重用性。

到目前为止，OO的世界依然和谐美好。

如此熟悉的反OO：访问者模式

再来一例。

case class Car(engine: Engine, body: Body, wheels: List[Wheel]) {

  def engineerCheck() {

    check(enigne)

    check(body)

    wheels.foreach(check(_))

  }

  def washerWash() {

    wash(body)

    wheels.foreach(wash(_))

  }

}

一辆车有一个引擎，一个车身，几个轮子。出厂/维修/保养的时候都需要找工程师检查，洗车的时候需要找洗车工清洗。工程师检查的行为一定是针对汽车的各组件，洗车工也是清洗的各汽车组件，行为和数据在一起组成对象，从OO的角度看，没啥问题。

如果来了一个外星人，以前没见过地球的汽车，觉得新奇，准备自己反向工程一辆，那简单：

case class Car(engine: Engine, body: Body, wheels: List[Wheel]) {

  ...

  def alienReverseEngineering() {

    reverseEngineering(enigne)

    reverseEngineering(body)

    wheels.foreach(reverseEngineering(_))

  }

}

小伙伴们发现没？汽车已经无辜到要关心外星人，职责太特么不单一了，即使它没有违反OO。重构的解决方案就是 访问者模式 ，把工程师/洗车工/外星人干的事情从汽车里面剥离出来。

trait Element {

  def accept(v: Visitor)

}

class Engine extends Element {

  def accept(v: Visitor) {

    v.visit(this)

  }

}

class Body extends Element {

  def accept(v: Visitor) {

    v.visit(this)

  }

}

class Wheel extends Element {

  def accept(v: Visitor) {

    v.visit(this)

  }

}

case class Car(engine: Engine, body: Body,

               wheels: List[Wheel]) {

  def accept(v: Visitor) {

    engine.accept(v)

    body.accept(v)

    wheels.foreach(accept)

  }

}

Elment代表的是需要被访问的元素，本例中就是汽车的各组件。Car容纳了所有组件，并隐藏组件间的结构。

trait Visitor {

  def visit(engine: Engine)

  def visit(body: Body)

  def visit(wheel: Wheel)

}

class Engineer extends Visitor {

  def visit(engine: Engine) = { ... }

  def visit(body: Body) = { ... }

  def visit(wheel: Wheel) = { ... }

}

class Washer extends Visitor {

  def visit(engine: Engine) = { ... }

  def visit(body: Body) = { ... }

  def visit(wheel: Wheel) = { ... }

}

class Alien extends Visitor {

  def visit(engine: Engine) = { ... }

  def visit(body: Body) = { ... }

  def visit(wheel: Wheel) = { ... }

}

Visitor是所有对Car感兴趣的人，以及他们会对Car发生的行为。

Element/Car是数据，而Visitor是行为，访问者模式使得你可以在不修改Car的组件及结构的情况下，通过Visitor的方式定义新的行为。

细心的小伙伴们已经发现了，其实访问者模式分离了数据和行为，反OO了。

反不反OO呢？

一会支持OO，一会反OO，以后咋做设计呢？

如果一码说设计是门艺术，需要根据实际情况仔细权衡，小伙伴们一定会在心里使劲骂，说了句废话。

那一码不说虚的，来分析点实在的东西。既然两个例子无法在OO上达成一致，那咱往后退一层，来看看更基础的原则 单一职责 和 不要重复 。

对于订单一例，只有把订单项的数据和行为（开销）放在一起，才算系统里面对一个概念的解释只在一处存在，满足 不要重复 的原则。对于汽车一例，只有把易于变化的行为和稳定的数据结构分离，才能做到一个个独立的职责汽车/工程师/洗车工/外星人，才能做到易于维护和扩展。

能够把上面这一点想通，其实只是个开始而已。一码个人觉得，对于代码层面的设计而言：

软件设计的基本原则是道，如：单一职责，不要重复，依赖倒置等
范式及其背后的模式是术，如：面向对象及设计模式，函数式编程及Monads，泛型编程，元编程等

从代码设计的角度看，如果你会C#，那么不要再去学Java（反之亦然），而应该去学学Scheme的函数式编程，Ruby的元编程。只有掌握不同的术，才能让道逐渐丰满，也才能为具体问题找到最合适的设计方案。

巴特西

大话重构之原来反OO天天见

特性依恋

如此熟悉的反OO：访问者模式

反不反OO呢？

推荐

最新文章

热门文章

巴特西

大话重构 之 原来反OO天天见

特性依恋

如此熟悉的反OO：访问者模式

反不反OO呢？

推荐

最新文章

热门文章

大话重构之原来反OO天天见