转载

大话重构之原来反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。重构的解决方案就是 访问者模式 ，把工程师/洗车工/外星人干的事情从汽车里面剥离出来。

大话重构之原来反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了。