} }
好了，现在我们要买东西，不用去跟那么多的厂家类打交道了。
Store store =new Store(); //买衣服
store.saleCoat(); //买电脑
store.saleComputer(); //买手机
store.saleMobile();
呵呵，这样对我们客户类来说，是不是简单多了。
第二种情况客户要完成的某个功能，可能需要调用后台的多个类才能实现，这时候特别要使用Facade模式。不然，会给客户的调用带来很大的麻烦。请看下面的例子。 我经常看到后台编码人员，强迫它们的使用者写出如下的代码： ……
String xmlString = null; int result = 0; try {
xmlString = gdSizeChart.buildDataXML(incBean);
String path = "D:/Eclipse3.0/workspace/PLMSuite/AppWeb/PM/productSpecification/gridfile.xml";
File f = new File(path);
PrintWriter out = new PrintWriter(new FileWriter(f)); out.print(xmlString); out.close();
System.out.println("\\r\\n\\r\\n sumaryAction" + xmlString + "\\r\\n\\r\\n");
request.setAttribute("xmlString", xmlString); }
catch(Exception ex) {
ex.printStackTrace(); }
这段代码前面即省略号省略掉的一部分是客户类调用后台的一部分代码，是一个相对独立的
功能。后面这一部分也是一个相对独立的功能，而后台代码设计人员却把这个功能留给客户类自己来实现。
我就很怀疑，让客户类做这么多事情，到底要你的后台做什么？你还不如直接把所有的事情都给客户类做了得了。因为，你后台做了一半，剩下的一部分给客户类做，客户类根本就不明白怎么回事，或者说他不清楚你的思路，这样做下去更加困难。可能这点逻辑对你来说，很简单。但使用者不明白你的思路啊，他不知道来龙去脉，怎么往下写？ 如果在这里有一个Facade类，让它来做不该由客户类来做的事，是不是简单多了呢？如下是一个Facade类：
public class Facade {
public static void doAll(PE_MeasTableExdBean incBean, HttpServletRequest request) { ……
request.setAttribute("xmlString", Facade.getFromOut(incBean)); }
private static String getFromOut(PE_MeasTableExdBean incBean) { try {
xmlString = gdSizeChart.buildDataXML(incBean);
String path = "D:/Eclipse3.0/workspace/PLMSuite/AppWeb/PM/productSpecification/gridfile.xml";
File f = new File(path);
PrintWriter out = new PrintWriter(new FileWriter(f)); out.print(xmlString); out.close();
System.out.println("\\r\\n\\r\\n sumaryAction" + xmlString + "\\r\\n\\r\\n"); return xmlString; }
catch(Exception ex) {
ex.printStackTrace(); return null; } } }
那么客户类的调用就是下面的样子：
Facade.doAll(incBean,request);
这样，客户是不是轻松多了？值得注意的是，Facade类中的getFromOut方法其实不应该在Facade类中，本文为了简单起见而放在了这个类中，对Facade类来说是不符合单一职责原则的。
最后总结一下第二种情况的模式。后台为实现某一个功能有如下类：
public class ClassA {
public void doA() { …… } …… }
public class ClassB {
public void doB() { …… } …… }
public class ClassC {
public void doC() { …… } …… }
如果客户类需要这样调用： ……
ClassA a = new ClassA(); a.doA();
ClassB b = new ClassB(); b.doB();
ClassC c = new ClassC(); c.doC(); ……
那么就适合做一个Facade类，来替客户类来完成上述的功能，如下：
public class Facade
{
public void doAll() {
ClassA a = new ClassA(); a.doA();
ClassB b = new ClassB(); b.doB();
ClassC c = new ClassC(); c.doC(); } }
则客户类的调用如下： ……
Facade Facade = new Facade(); Facade.doAll(); ……
--作者说的第二种情况，就是Facade提供一个更粗粒度的一个方法接口让客户调用
KSQL主结构 2007年3月
类com.kingdee.bos.sql.test.BVT_KSQL用来对KSQL进行测试包含了大多数测试用例，每次修改之后都要运行一下以检验KSQL正确性。
类java.util.Collection.TransUtil封装了对词法分析、语法分析、翻译程序的调用，当需要翻译KSQL时需要调用的java.util.Collection.TransUtil中Translate方法，需要注意Translate方法有不同的版本，功能稍有区别。
类com.kingdee.bos.sql.formater.SQLFormatter和其子类负责KSQL到不同数据库平台SQL的翻译，不同的子类分别负责相应数据库平台的SQL翻译，Formatter中不同的方法分别负责翻译不同的SQL，如果要完成某功能就要先找到负责翻译的Formatter方法，目前主要支持DB2 UDB、DB2 AS400、MS_SQL_Server、Oracle。
EAS调用界面的方式 2006年1月
uiWindow = UIFactory.createUIFactory(UIFactoryName.MODEL).create(getEditUIName(),
uiContext, null, OprtState.VIEW); uiWindow.show();
eas的eclipse启动参数 2006年8月
eas的eclipse启动参数 -DEAS_HOME=D:\\kingdee\\eas
-DEAS_SERVER=tcp://localhost:11034
-Dlog4j.configuration=file:D:\\kingdee\\eas\\client\\deploy\\client\\log4j.properties
-Dlog4j.configuration=file:D:\\kingdee\\eas\\client\\deploy\\client\\log4j.properties 可有可无
转载请注明出处：http://blog.csdn.net/pan_tian/article/details/7773802
===EOF===