上面这种做法可以将值对象改变成引用对象，但是代价就是改变Order创建的方式。上面代码修改完了，那么我们的测试用例也就作废了，因为Order的创建方式进行了修改，需要外部传入一个Customer对象，下方截图就是我们修改后的测试用例。（如果你是在你的工程中这么去将值对象修改引用对象的，不建议这么做，下面会给出比较好的解决方案）。

3.从根本上进行重构

上面代码的修改不能称为代码的重构，因为其改变的是不仅仅是模块内部的结构，而且修改了模块的调用方式。也就是说里外都被修改了，这与我们重构所提倡的“改变模块内部结构，而不改变对外调用方式”所相悖。所以在代码重构时不要这么做了，因为上面的这种做法的成本会很高，并且出现BUG的几率也会提高。因为每个使用订单的地方都会创建一个Customer的类来支持订单的创建，那么问题来了，如果同一用户在不同地方创建订单怎么办？所以上面的做法还是有问题的，终归是治标不治本。所以我们要从根本上来解决这个问题。因为该问题是因为Customer数据不同步引起的，所以我们还得从Customer来下手。

该部分的重构，在第一部分的基础上做起。我们本次重构的目标就是“不改变对外调用方式，但能保持每个用户是唯一的”。好接下来就开始我们真正的重构工作。在本次重构中，依照重构的规则，我们不会去修改我们的测试用例，这一点很重要。

(1)从根本解决问题，首先我们对Customer进行重构。在Customer中添加了一个静态的私有变量customers, 该静态私有变量是字典类型。其中存储的就是每次创建的消费者信息。在字典中每个消费者的key为消费者独一无二的身份证信息（idCard）。在添加完上述变量后，我们需要为创建一个工厂方法createCustomer() 在工厂方法中，如果当前传入的用户信息未被存入到字典中，我们就对其进行创建存入字典，并返回该用户信息。如果传入的用户已经被创建过，那么就从字典中直接取出用户对象并返回。具体做法如下所示。

(2)、对Customer类修改完毕后，我们需要在Order中通过Customer的工厂方法来获取Customer类的实例，这样就能保证Order中的customer对象也是引用对象了。不过此时的引用对象是从Customer中获取的，而不是外部传过来的。下方是Order类中对工厂方法的调用，这样做的好处就是，我们只对模块的内部进行了修改，而测试用例无需修改。

 (3)、对此次重进行测试，我们任然使用第一部分使用的测试用例。也就是说该模块对外的接口是没有变化的，下方就是对重构后的代码的测试结果。由结果可以看出，在不同订单中的用户，只要是信息一致，那么其内存地址是一致的。也就是经过重构，我们将原来的值对象改成了引用对象。

四、Change Reference to Value(将引用对象改为值对象)

将引用对象改为值对象，该重构规则正好与上面相反。在一些情况下使用值对象更为简单，更易管理，但前提是该值对象很小并且不会被改变。在这种情况下你就没有必要使用引用对象了。从上面的示例来看，使用引用对象实现起来还是较为复杂的。还是那句话，如果你的对象非常小，而且在创建后其中的数据不会被改变，如果需要改变就必须在创建一个新的对象来替换原来的对象。在这种情况下使用值对象是完全可以的。在此就不做过多的赘述了。

不过在使用值对象时，你最好为值对象提供一个重载的相等运算符用来比较值对象中的值。也就是说只要是值对象中的每个属性的值都相同，那么这两个值对象就相等。至于如何对“==” 运算符进行重载就不做过多的赘述了，因为该知识点不是本篇博客的重点。

五、Replace Array or Dictionary with Object(以对象取代数组或字典)

这一点呢和本篇博客的第二部分其实是一个。就是当你使用数组或者字典来组织数据，这些数据组合起来代表一定的意义，这是最好将其定义成一个实体类。还是那句话，定义成实体类后，数据更易管理， 便于后期需求的迭代。下方代码段就是讲相应的字典和数组封装成一个实体类，因为确实比较简单，在此就不做过多的赘述了。具体请参加下方代码段。

六、Duplicate Observed Data(复制“被监测数据”)

这一部分是比较重要的部分，也是在做UI开发时经常遇到的部分。用大白话将就是你的业务逻辑与GUI柔和在了一起，因为UI作为数据的入口，所以在写程序时，我们就很容易将数据处理的方式与UI写在一起。这样做是非常不好的，不利于代码的维护，也不利于代码的可读性。随着需求不断的迭代，版本不断的更新，UI与业务逻辑融合的代码会变得非常难于维护。所以我们还是有必要将于UI无关的代码从UI中进行分离，关于如何进行分层宏观的做法请参加之前发布的博客《iOS开发之浅谈MVVM的架构设计与团队协作》。

今天博客中的该部分是分层的微观的东西，也就是具体如何将业务逻辑从GUI中进行剥离。所以在接下来的实例中是和UI实现有关的，会根据一个比较简单的Demo来一步步的将UI中的业务逻辑进行分离。进入该部分的主题。复制“被监测数据”简单的说，就是将UI提供的数据复制一份到我们的业务逻辑层，然后与UI相应的数据进行关联，UI数据变化，被复制的业务逻辑中的数据也会随之变化。这一点也就是所谓的"响应式编程"吧，关于响应式编程，iOS开发中会经常用到ReactiveCocoa这个框架，关于ReactiveCocoa的内容，请参见之前的博客《iOS开发之ReactiveCocoa下的MVVM》。今天的示例中，使用了一个比较简单的方式来同步这些数据，使用了"事件监听机制"。下方就创建一个比较简单的Demo。

1.创建示例

要创建的示例比较简单，在UI方面，只有三个输入框用来接收加数与被加数，以及用来显示两数之和。然后使用两个UILabel来显示+号与=号。我们要实现的功能就是改变其中一个加数与被加数时，自动计算两个数的和并显示。

 要实现上述功能的代码也是比较简单的，总共没有几行，下方这个类就是实现该功能的全部代码。代码的核心功能就是“获取加数与被加数的和，然后在加数与被加数的值有一个改变时，就会计算两者之和，并将和赋值给最后一个输入框进行显示”。具体代码如下所示。