适用性:
第一:
当你要为一个复杂的子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具有可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图,这一视图对大多数用户来说已经足够,而那些需要更多的可定制的用户可以超越Facade层。
第二:
客户程序与抽象类的实现部分之间存在着很大的依耐性。引入facade将这个子系统与客户以及其他的子类系统分离,可以提高子系统的独立性和可移植性。
第三:
当你需要构建一个层次结构的子系统时,使用facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过facade进行通讯,从而简化了他们之间的依赖关系。
实现:
第一:降低客户——子系统之间的耦合度。
用抽象类实现facade而它的具体子类对应于不同的子系统实现。这可以进一步降低客户与子系统的耦合度。这样,客户就可以通过抽象昂的Facade类接口与子系统通讯。这种抽象耦合的关系使得客户不知道它使用的是子系统的哪一个实现。
除生成子类的方法以外,另一种是用不同的子系统对象配置Facade对象。为定制Facade,仅需要对他的子系统对象(一个或多个)进行替换即可。
第二:
……选自《设计模式》
比较Facade模式与Adapter模式:
(一):在两个模式中,都存在既有的类。
(二):在Facade模式中,我们无须按某个接口进行设计;而在Adapter模式中,则必须按某个特定的接口进行设计。
(三):Facade不要多态,而Adaper需要多态。(但是《设计模式》否定了这种说法,上面实现的第一个加黑就是)
(四):Facade模式中的动机是简化接口,而Adapter,尽管也是越简单越好,但是设计必须遵循一个已有的接口,不能简化任何东西,即使可能存在更简单的接口。
结论:Facade简化了接口,而Adapter将一个模式转换成另外一个接口。
<<设计模式解析>>
class Scanner{
public:
Scanner(istream& );
virtual ~Scanner();

virtual Token& Scan();
private:
istream& _inputStream;
}
class Parser{
public:
Parser();
virtual ~Parser();
virtual void Parse(Scanner&, ProgramNodeBulider& );
};
class ProgramNodeBulider{
public:
ProgramNodeBulider();
virtual ProgramNode* NewVariable(const char* variableName) const;
virtual ProgramNode* NewAssignment(ProgramNode* variable,
ProgramNode* expression) const;
virtual ProgramNode* NewCondition(ProgramNode* truePart,
ProgramNode* falsePart) const;
Program* GetRootNode();
private:
ProgramNode* _node;
};
class ProgramNode{
public:
virtual void GetSourcePosition(int& line, int& index);
virtual void Add(ProgramNode* );
virtual void Remove(ProgramNode* );
protected:
ProgramNode();
};
class CodeGenerator{
public:
virtual void Visit(StatementNode* );
virtual void Visit(ExpressionNode* );
protected:
CodeGenerator(ByteCodeStream& );
protected:
BytecodeStream& _output;
};

class Complier{
public:
Complier();
virtual void Complie(istream&, BytecodeStream&);
};

void Complier::Complie(istream& input, BytecodeStream& output)
{
Scanner scanner(input);
ProgramNodeBulider builder;
Parser parser;

parser.Parse(scanner, bulider);

RISCCodeGenerator generator(output);
ProgramNode* parseTree = builder.GetRootNode();
parserTree->Traverse(generator);
}
第一:
当你要为一个复杂的子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具有可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图,这一视图对大多数用户来说已经足够,而那些需要更多的可定制的用户可以超越Facade层。
第二:
客户程序与抽象类的实现部分之间存在着很大的依耐性。引入facade将这个子系统与客户以及其他的子类系统分离,可以提高子系统的独立性和可移植性。
第三:
当你需要构建一个层次结构的子系统时,使用facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过facade进行通讯,从而简化了他们之间的依赖关系。
实现:
第一:降低客户——子系统之间的耦合度。
用抽象类实现facade而它的具体子类对应于不同的子系统实现。这可以进一步降低客户与子系统的耦合度。这样,客户就可以通过抽象昂的Facade类接口与子系统通讯。这种抽象耦合的关系使得客户不知道它使用的是子系统的哪一个实现。
除生成子类的方法以外,另一种是用不同的子系统对象配置Facade对象。为定制Facade,仅需要对他的子系统对象(一个或多个)进行替换即可。
第二:
……选自《设计模式》
比较Facade模式与Adapter模式:
(一):在两个模式中,都存在既有的类。
(二):在Facade模式中,我们无须按某个接口进行设计;而在Adapter模式中,则必须按某个特定的接口进行设计。
(三):Facade不要多态,而Adaper需要多态。(但是《设计模式》否定了这种说法,上面实现的第一个加黑就是)
(四):Facade模式中的动机是简化接口,而Adapter,尽管也是越简单越好,但是设计必须遵循一个已有的接口,不能简化任何东西,即使可能存在更简单的接口。
结论:Facade简化了接口,而Adapter将一个模式转换成另外一个接口。
<<设计模式解析>>
































































