对于生成器模式我这里以生产自行车为例进行讲解,自行车由车轮与车架组成,由不同样式的车轮与不同样式的车架就可以组装成不同的自行车(如赛车,山地车等),下面的程式进行说明:
下面来比较抽象工厂模式与生成器模式的区别:
以生产自行车为例,抽象工厂模式获得的是不同名牌的自行车而不管自行车是由什么部件组装而成的;而生成器模式获得是不同样式的自行车,所关心的是自行车组成部件的构成.所以看出抽象工厂模式获得是一系列相关的类(如凤凰牌自行车,XX牌自车等)而生成器模式获得的是提供给它数据(如上例中的“山地车“)一步一步构建的一个复杂的对象(即山地车)
Feedback
#1楼 219.239.219.*
2005-03-01 13:01 by sysword [未注册用户]作者阐述的思想是正确的,但觉得这个例子不好,没有强调出组装过程的不同。Builder模式是元素构建过程和组装过程的分离。强调的是实体和过程的一种解耦。
本文例子没有强调出赛车和山地车组装过程的不同。为什么要把组装过程分离出来呢,主要是因为这个过程比较复杂,构造过程的多样性导致了不同的产品,而这过程和元素是没有关系的。
比如搭积木,一套积木假设有六种形状,可以是塑料的,可以是纸制的,也可能是计算机中更简单的一种抽象表示。每种表示形式对应一个具体的Builder类,每个形状对应类中的一个方法。但用积木可以构建出各种玩具,比如小车,坦克等。每个玩具对应一种搭建方法,塑料坦克和纸坦克的搭建方法是一致的,把这个一致性抽象出来,就是Builder模式中的组装类。
Buidler模式体现的是在创建一个复杂对象时三个不同平面的分离:不同元件、不同表现形式、不同过程,这三个平面是相对独立的。不同元件表现Builder类的不同方法上,不同表现形式表现在各种具体的Builder类上,不同过程表现在不同的组装类上。
其实复杂对象的构建不一定表现在三个平面上的,可能俩个或四个以上,俩个的情况就是Factory模式,四个以上的情况可以通过在Builder模式上扩展,比如刚才创建出的各种玩具需要有各种不同的摆放方式,抽象一点说就是创建出的产品需要有不同的表现形式,这就可以在组装类上面在构造一个表现形式抽象类,具体不同的派生类分别对应各种不同的表现形式。
理解Builder模式一定要理解到各个不同平面的解耦这点,才能灵活运用。
比较懒惰:(,本来想写个例子阐述一下的:(
本文例子没有强调出赛车和山地车组装过程的不同。为什么要把组装过程分离出来呢,主要是因为这个过程比较复杂,构造过程的多样性导致了不同的产品,而这过程和元素是没有关系的。
比如搭积木,一套积木假设有六种形状,可以是塑料的,可以是纸制的,也可能是计算机中更简单的一种抽象表示。每种表示形式对应一个具体的Builder类,每个形状对应类中的一个方法。但用积木可以构建出各种玩具,比如小车,坦克等。每个玩具对应一种搭建方法,塑料坦克和纸坦克的搭建方法是一致的,把这个一致性抽象出来,就是Builder模式中的组装类。
Buidler模式体现的是在创建一个复杂对象时三个不同平面的分离:不同元件、不同表现形式、不同过程,这三个平面是相对独立的。不同元件表现Builder类的不同方法上,不同表现形式表现在各种具体的Builder类上,不同过程表现在不同的组装类上。
其实复杂对象的构建不一定表现在三个平面上的,可能俩个或四个以上,俩个的情况就是Factory模式,四个以上的情况可以通过在Builder模式上扩展,比如刚才创建出的各种玩具需要有各种不同的摆放方式,抽象一点说就是创建出的产品需要有不同的表现形式,这就可以在组装类上面在构造一个表现形式抽象类,具体不同的派生类分别对应各种不同的表现形式。
理解Builder模式一定要理解到各个不同平面的解耦这点,才能灵活运用。
比较懒惰:(,本来想写个例子阐述一下的:(
非常感謝sysword 的發表:)
致於我在文中没有强调出组装过程的不同,我想是我比你更懒吧,認為對於產品各部件的組成及組裝成品的過成,往往是一個比較復雜而煩鎖的過程,就像經常遇到的輸入不同的參數來獲得不同的界面一樣,那麼界面往往是由不同的部件組成的,組裝成一個可以看的界面我想在這是比較復雜的了,所以沒有具體的去分析!
致於我在文中没有强调出组装过程的不同,我想是我比你更懒吧,認為對於產品各部件的組成及組裝成品的過成,往往是一個比較復雜而煩鎖的過程,就像經常遇到的輸入不同的參數來獲得不同的界面一樣,那麼界面往往是由不同的部件組成的,組裝成一個可以看的界面我想在這是比較復雜的了,所以沒有具體的去分析!
浙公网安备 33010602011771号