[专题讨论]设计模式及应用

yining

对不起，没有注意看。你说的对，确实没有必要，而且会引起性能的降低。

ccwlm741212

设计模式及应用： 好话题啊，可惜讨论的不够深！！！可惜

decode

有高见不妨说出来，偶是抱着学习的态度来的。

decode

Java与模式 读书笔记（3）

Builder建造模式
一个产品常有不同的部分组成的。这里的部分可能是对象，也可能是一些属性。它们通常称作：internal representation.不同的产品有着不同的零件。使用建造模式使得客户端不需要知道所产生的产品的内部细节。

模式中涉及的角色：
抽象建造者： 给出一个抽象接口，以规范产品对象各个组成部分的建造。 这个角色独立于应用程序的商业逻辑。其定义的方法有两种，一个是建造方法。建造方法的个数通常和零件的个数相同。另一种是结果返回方法。结果返回方法一般只有一个。

具体建造者：具体建造者包含对象的建造逻辑。它实现抽象建造者的接口。并在建造过程完毕后，提供产品的实例。

导演者角色。 担任这个角色的类调用具体建造者角色以创建产品对象。

产品角色：产品便是建造中的复杂对象。产品不一定有相同的接口，而且可以是完全不相关联的。

标识接口的使用。 由于建造模式中产品是完全不相关联的，而具体建造者返回的对象必须是同一类，所以很可能在这个模式中用到标识接口。

活动图的描述：
客户端先创建具体建造者。然后创建导演者。然后，具体建造者被交给导演者。导演者建造对象，然后返回对象给客户端。
因为导演者需要指挥不同的具体建造者完成不同的产品建造，所以，不宜让导演者直接创建具体建造者，而是由客户端传入。

建造模式的变化：
1。空的零件建造方法。 因为不同的产品有着不同的零件数，所以完全有可能有的零件建造上需要提供一个空的实现。
2。如果系统中很确信可以只有一个具体建造者的话，可以省掉抽象建造者。
3。当省掉抽象建造者后，导演者和建造者角色可以合并起来。

在以下情况下应当使用建造模式
需要生成的产品对象有复杂的内部结构。每一个内部成分本身可以是对象，也可以是对象的一个组成部分。
需要生成的对象的属性相互依赖。建造模式可以强制实行一种分步骤进行的建造过程。
在对象创建过程中会因使用到系统中其他一些对象，这些对象在产品对象的创建过程中不易得到
使用建造莫斯科主要有以下的小窝效果
建造模式的使用式的谈心的内部表象可以独立的变化。食用建造模式可以使客户端不必知道诚心类不同程度的细节
每一个有的对于都相互独立而引起他的而已其他的目光无关
模式所建造的最终产品更易于控制。

yining

等着你的续篇。现在还不太好讨论呢。

decode

最初由 yining 发布
[B]等着你的续篇。现在还不太好讨论呢。 [/B]

呵呵。楼上的楼上的那个帖子，我是回复ccw的

decode

适配器与缺省适配器(Adapter and default adapter)

适配器把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

适配器有两种形式，；类的适配器和对象的适配器。
两者的区别在于，类的适配器用继承实现，对象的适配器用委派关系实现。

类的适配器
涉及角色有

目标(Target)角色：目标角色是所期待的接口。由一个接口扮演
源角色（Adaptee）角色：现有的接口。将被适配到Target上去。
适配器（Adapter）角色：将源接口转换到目标接口上去。由一个具体类扮演

类Adapter的定义方法：
public class Adapter extends Adaptee implements Target
{
/*
ommitted
*/
}

Adapter在继承Adaptee后，补足一些未实现的功能，或者override一些方法，从而实现Target接口

类适配器总结：
1）源的子类无法和源使用同一个适配器
2）实现时可以override源的方法

对象适配器

涉及角色有
目标(Target)角色：目标角色是所期待的接口。由一个接口扮演，也可以是一个抽象/具体类
源角色（Adaptee）角色：现有的接口。将被适配到Target上去。
适配器（Adapter）角色：将源接口转换到目标接口上去。由一个具体类扮演


对象Adapter的定义方法
public class Adapter implements Target
// Or public class Adapter extends Target
{
        private Adaptee adaptee;
       
        public Adapter(Adaptee adaptee)
        {
                /*
                */
        }
/*
ommitted
*/
       
}

对象适配器总结：
1）源类和源类的子类都可以通过同一个适配器适配到同一个目标。
2）不太容易置换源类的方法
3）易于增加新的方法

使用适配器的情况
1）系统需要使用现有的类， 而此类的接口不符合系统的需要。
2）想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，
包括一些可能在将来引进的类一起工作。而源类不需要设计一些复杂的接口。
3）（对对象适配器而言） 需要改变多个已有的子类的接口。

缺省适配是适配器模式的一个特例
很多情况下，必须让一个具体类实现一个接口。但是这个类又用不到接口所规定的所有方法
，通常的处理方法是，对于其他方法提供一个空的实现。

缺省适配器是对一个抽象的适配器，对于给定接口的所有方法都提供了空的实现。具体的类从抽象
适配器类继承，按自己的需要覆盖空的实现。

缺省适配器使得一个实现接口的类只关注自己需要的那部分接口。缺省适配器类应该被声明为
抽象的，阻止被客户端实例化。

yining

讲一下我的体会。

第一，关于简单工厂。

这个东西，我觉得不应该把它算成一个模式。每一个模式都有自己的意图。对于工厂类来说，这一类模式的意图在于把client分离，另外一点在于增加创建类的时候，不用修改现有代码。（对于抽象工厂来说，他的侧重点在与一族的对象，所以增加一的新的族是不用修改代码的，但是如果增加一个新的类就需要乐）

但是简单工厂则不同，首先，client仍然需要知道所创建的类的知识，（所谓的参数，不也就是和被创建的类挂钩的么？）其次，每一次增加一个新的类，原来的代码就需要改动。这样的模式基本没有什么意义。

再说说适配器的问题：

这个东西应该说比较少用到。主要的应用是对第三方软件的接口。由于无法修改别人的代码，所以用到Adapter。不过，世事无绝对，最近就碰上了一个使用Adapter的机会，而且还是自己的代码。具体的内容是这样的，现在我们的功能需要扩充，但是现在的接口类的client太多，修改接口类太麻烦（代码3000多行）。所以就创建了几个新的类，把接口类改成了Adapter。

在这里顺便说一句refactor的作用。通过refactor，把原来的接口类从3000多行，改到了2000多行，创建了4个新的类，大约是用了1200-1500行代码。好像代码量增多了，性能略微有所下降，但是实际上，每个类的维护（尤其是原来的接口类）都容易很多。类的功能，角色更清晰，以后再有功能扩充会容易很多。

decode

如果不是实时系统，可维护性可扩充性是第一位的。特别是对于我，如果不换公司，可能5，6年还做同一个产品。不过，做到这两样是很难阿。
简单工厂，阎宏单独列出的主要目的是为了提供一个台阶，过度到工厂方法和抽象工厂。

yining

简单工厂的问题其实在于：内部的创建过程一定会有：if else的语句。按照Refactoring一书的说法，是一定要改掉的。