封装复杂对象的构造逻辑，那么这讲的话呢，实际上是这个builder模式，这个构造器模式就是builder，ok，那么这个builder模式所要实现的是一个什么场景呢，就是，是这样的，比如说我们现在要构造一个复杂的一个对象，然后这个对象呢，就是很多的这个属性，然后有些属性构造的时候，需要做一些校验啊，然后比如说一些格式转换啊，等等，然后就是说它会有一些逻辑么，对吧。大概就是这样的这么一个场景。
然后，这个场景呢，是这样子啊，我们来看一下这边，这应该是builder对吧。我们先来做 一个没有用模式的场景，WithoutBuilderPatternDemo，比如说，我们现在不用模式，那可能就是这样子，我给大家举个例子啊，我这边有一个public static class Product这个类，我假设它是很复杂的这么一个对象啊，然后它有3个，filed1，filed2，filed3，ok，然后它是有一堆的这个get、set对吧，好，然后的话，我们现在来开始构造这个复杂的这个Product对象，比如说我们可能会这样的来做，Product product = new Product();，设置field1属性，然后我们这边可能要，你看，我只是给大家举个例子，在设置field1之前进行较为复杂的这个校验逻辑。System.out.println("在设置field1之前进行较为复杂的校验逻辑");，接下来product.setField1("值1");，然后，设置field2属性，然后这个System.out.println("在设置field2之前进行复杂的数据格式转换逻辑");然后，product.setField2("值2");，然后这便是设置field3属性，System.out.println("在设置field3之前进行复杂的数据处理逻辑，跟其他对象的数据进行关联");，比如说干了这么一个事情，然后product.setField3("值3");。
好，那么它这里的话，可能就是会变成这样子，就是构造成一个复杂的对象么，每构造一个Filed，可能都会在这之前有一些逻辑吗，对吧，然后最后啊，其实上面是一个简化的这么一个逻辑啊，实际上，对于一些，有几十个字段，甚至上百个字段的复杂对象的构建，上面那段代码会极度膨胀，非常那个复杂，那这个有一个坏处啊，一个是说，大量代码堆积在一起，然后那个维护性非常差，可读性非常差，就是一坨代码，到最后跟屎一样，就是读不懂，没法改，可能这个代码，它就是这样子，那另外一个，这段逻辑它如果是在那个多个地方都有使用的话，那么一旦这段逻辑出现了一些变化，那么可能就需要在多个地方修改这一坨跟屎一样的代码。对吧，那当然 了，其实你可以把所谓的这个构造的过程，拿到一个工厂里面去，但是在这个工厂里面，它其实也是一样的啊，你在这个工厂里面，它可能会混杂着大量的代码，当然你说，我可以把这个，不同的这个构造的步骤抽取成某一个这个方法，当然你可以这么去做，但是这样做的话，实际上来说就是，你还是没有用一个，就是这个构造器模式啊，它其实体现的是说你的，整个这个比较复杂的一个构建逻辑吗，对吧，然后它可能需要有很多的逻辑去构建，然后，它体现的并不是说把，就是你可以把一大堆很复杂的这个逻辑放在一个工厂里面去，在这个工厂把多个步骤给抽成不同的方法，你也可以这么去做，但是那样的话，同样会导致，就是那样的话同样会有一个问题啊，什么问题啊，我一会给大家说，我还是先把整个这个构造器模式代码给大家写一遍，然后来看一看，欧克。
然后这边的话，BuilderPatternDemo，给大家看看，如果采用构造器模式，大概看起来，应该是什么样子的。