设计问题，想套用一个模式，但是发现比书本上困难多了！！
现在我这边的情况是，我们做一个收费系统，里面大概有三四个支付平台，用一个配置文件将平台必须的配置保存起来，但是由于平台需要配置的参数不一致，所以配置的每一个平台节点的属性都不一样。我的想法是抽象一个平台类出来，叫“Platform（平台）”，里面有一个解析（Resolve）XML的方法，然后让具体的平台类去继承这个类，在实现解析（Resolve）方法的时候，再返回具体的类。
类结构分别如下：
平台类（Platform）：
public abstract class Platform
{
protected string xmlRoow = "d:/dd/dd/sdk.xml";
public abstract void ResolveSDKCfg();
}
平台创建者类（PlatformCreator）：
public class PlatformCreator
{
private string sdkType;
public PlatformCreator(string sdkType)
{
this.sdkType = sdkType;
}
public Platform CreateSDKObj()
{
Platform sdk = null;
switch (sdkType)
{
case "alipay":
sdk = new AliPayPlatform();
break;
case "paypal":
sdk = new PayPalPlatform();
break;
default:
break;
}
return sdk;
}
}
具体平台Alipay类（AliPayPlatform ）：
public class AliPayPlatform :Platform
{
public string PostUrl { get; set; }
public string AuthToken { get; set; }
public override Platform ResolveSDKCfg()
{
string url = base.xmlRoow;
AliPayPlatform a = new AliPayPlatform();
a.PostUrl = "www.xxxx.com";
a.AuthToken = "www.yyy.com";
return a;
}
}
具体平台Alipay类（PayPalPlatform）：
public class PayPalPlatform:Platform
{
public string NotifyUrl { get; set; }
public override Platform ResolveSDKCfg()
{
string url = base.xmlRoow;
PayPalPlatform p = new PayPalPlatform();
p.NotifyUrl = "http://www.xxxxx.com";
return p;
}
}
然后是调用类Program：
class Program
{
static void Main(string[] args)
{
PlatformCreator plats = new PlatformCreator("paypal");//创建“平台创建者”类
Platform p = plats.CreateSDKObj();//利用平台创建者类创建具体平台“PayPalPlatform”对象
PayPalPlatform juti = (PayPalPlatform)p.ResolveSDKCfg();//具体平台对象解析xml获取具体平台对象实体
Console.WriteLine(juti.NotifyUrl);
Console.Read();
}
}
感觉自己写的代码四不像啊，和书本上那些只是void输出的方法麻烦多了，反正我自己看着挺别扭的，请大家指点指点。。。
不好意思，没分了！！！ 设计模式 --------------------编程问答-------------------- 特别有疑问的是第三步“PayPalPlatform juti = (PayPalPlatform)p.ResolveSDKCfg();”还用到了强制类型转换，记得看书的时候都没有这个的，如果我把第三步改成“Platform juti = p.ResolveSDKCfg();”，那么juti对象就访问不了自己类的属性来。。。 --------------------编程问答-------------------- 为了xml而xml，你整了个空洞的操作概念，而你什么业务细节都设计不出来，这就没有意义。不要弄技术，真正的OOAD系统分析设计技术是针对具体的业务领域的，当你在业务抽象细节内部可以用一点技术术语，而不是自始至终扯xml之类的时髦概念。如果不能从业务流程出发去融合技术，如果过渡技术化，我宁愿不听不看。 --------------------编程问答--------------------
老大呀，我也是有苦衷的，这个项目是公司不知道从哪儿弄过来的，以前写好了，但是老大不满意，让重新弄一边，把以前的代码能复制到复制。感觉做软件的什么奇葩都有，我现在的老大恨不得跟你说三句话你就明白他的意思，自己将不明白还老是发脾气。
我现在根本就没有接触到业务，老大也不讲什么业务，我想OOAD是需要对业务领域比较了解到吧，我现在接触到的业务就是和你讲讲当下这个软件的需求，是用来干嘛的，工作原理是什么，其他都没有。
我这么写是有仔细考虑过的，不是完全为了套用XXXX而来的，我是想把不太了解到部分丢到一块，能拨开的尽量拨开，想到是尽量修改少一点，把休要修改的地方明明白白的掌握在心里。。
最后说句，做这行真TM的不容易。。。 --------------------编程问答-------------------- 再者，我觉得技术是慢慢积累起来的，不能说不能给你一个完全想要的平台就不做当前的工作量吧？！
到一家公司去首先还是得适应他们！ --------------------编程问答-------------------- 额，看完，你只有一句话问你“知道什么叫序列化/反序列化不” --------------------编程问答--------------------
序列化就是将对象转为可持久化的过程，一般来说就是将对象转为可存储的文本，反序列化则反之。
这么说：就是将不同的平台配置封装成类？然后……
其实这么做也没多大不同啊，只是操作不走换来一下，操作方式、设计还是得想想呀！ --------------------编程问答-------------------- 支付方式实现，更合适用适配器模式。 --------------------编程问答--------------------
谢谢，我看看。。 --------------------编程问答--------------------
怎么会访问不了？ --------------------编程问答-------------------- 没有必要为了设计模式而设计模式，有的时候if else就够了，你费尽心力做个XX框架，结果业务一辈子都改不到2次~~~设计模式是针对业务来的；
你现在用的是算简单工厂了，主要的关键在怎么抽象出支付类，支付类未考虑全面，以后一样要改代码改的头大，适配器也是不错的选择 --------------------编程问答-------------------- 我首先不会给你适配器，因为一给你适配器了，你第一件事情就是去博客园，找适配器的文章，然后嘛就开始什么适配器是啥，桥接是啥，工厂是啥，什么适配器uml如何如何，桥接uml如何如何，工厂如何如何，策略如何，工厂和策略什么区别，优势，缺点如何，适配器桥接如何，适配器和桥接什么区别如何，优势如何，缺点如何
哎，我真的不愿意你掉那坑你，我真的愿意你实实在在分清楚你到底要做什么，而不是一堆博客园那些条条框框框死你，现在的博客园我就一句话“肖咪咪，骗死人不偿命！”，反正做错滴是你，不是他，掉坑里的是你，不是他，他看还可以在坑边上“霍霍，又一个掉坑里滴” --------------------编程问答--------------------
熊猫哥好像对博客园有点那个
--------------------编程问答--------------------
哈哈，说话蛮有意思！
谢谢你的好意！
但是现在我感觉没法“进步”了，折磨一下自己也许不错！
不过我真的觉得用if和用这个简单工厂没什么区别。
只单单考虑一下设计原则里面的单一职责，我把不同的平台类型拆开封装成类也没什么不对呀？！！ --------------------编程问答-------------------- 还有就是说说序列化的问题，我觉得没必要用序列化：
第一：xml结构式规定好的，所以我不需要创建、修改这个xml文件。
第二：我不需要“传输”。我只需要把这个配置文件通过节点里面的type类型，读取出来，封装成type对应的类型。
补充：.NET技术 , ASP.NET
