多类继承情况下适应变化设计一例_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 多类继承情况下适应变化设计一例

多类继承情况下适应变化设计一例

 2017/6/24 5:32:10  buguge  程序员俱乐部  我要评论(0)
  • 摘要:在支付中心的中信支付渠道实现层里,关于每个支付接口的对接实现,类图设计方式如下(后附支付中心程序框架-分层结构),诸如获取动态支付码、公众号/服务窗、订单查询、关单、退款、代付、代付查询等每种支付接口的api实现均继承了同一个基类。ClassDiagram支付中心程序框架-分层结构基类封装了请求渠道方api所必须的参数验证、签名、生成请求报文、发起请求、验证响应报文这一系列环节。这样的OO设计,可以简化每个支付接口api类的逻辑实现,它们只需构造请求模型,然后调用基类Communicate方法
  • 标签:情况 继承 设计 变化

在支付中心的中信支付渠道实现层里,关于每个支付接口的对接实现,类图设计方式如下(后附支付中心程序框架-分层结构),诸如获取动态支付码、公众号/服务窗、订单查询、关单、退款、代付、代付查询等每种支付接口的api实现均继承了同一个基类。

imageView2/2/w/1240" alt="" data-original-src="http://upload-images.jianshu.io/upload_images/1551149-bc77e1966f1e99e0.png?imageMogr2/auto-orient/strip%7CimageView2/2" />
ClassDiagram
支付中心程序框架-分层结构

基类封装了请求渠道方api所必须的参数验证、签名、生成请求报文、发起请求、验证响应报文这一系列环节。这样的OO设计,可以简化每个支付接口api类的逻辑实现,它们只需构造请求模型,然后调用基类Communicate方法,然后转换成相应模型即可。

投产后,线上交易量太大。系统运维过程中往往要通过查日志来协助排障,比如某次订单查询的请求返回了错误的信息“订单未支付”,那么就要定位该次请求所对应的渠道请求报文日志和响应报文日志。

对于支付中心支付接口收到的每一次请求,我会生成一个随机字符串作为logflag,来统一标识每一次请求的处理过程(涉及到项目的每一层,如webapi层、交易服务层、BLL层、DAL层)中所对应的日志。 见下图中的“[OrderQuery_180001914_C72FF]”、“[OrderQuery_180002492_C6E22]”、“[JSPay_102157155_D0F3F]”、“[180002CITIC648]”。


交易日志截图

美中不足的是,渠道通讯层所记录的日志没有这个logflag,导致很难与webapi等层的日志对应起来。 本文要说的就是这一完善,接收外部传来的logflag参数,在记日志的时候打上这个logflag标识。(后来与同事闲聊时,得知可以用当前Thread的Name来很容易的实现这个统一标记交易日志的功能,本文重点是分析本次重构过程,所以姑且不讲这些)

基类CiticAPIBase是抽象类:

public abstract class CiticAPIBase<TRequestModel, TResponseModel>
    where TRequestModel : RequestDTOBase
    where TResponseModel : ResponseDTOBase
{

    readonly string LOG_FLAG = string.Format("[{0}CITIC{1}]", DateTime.Now.ToString("HHmmss"), new Random().Next(9999));
    protected LogHelperUtil _LogHelperUtil;

    public CiticAPIBase()
    {
        _LogHelperUtil = new LogHelperUtil(LOG_FLAG);
    }

    public abstract TResponseModel Invoke(TRequestModel reqModel);

    public string Communicate(RequestModelCommon citicReqModel)
    {
        try
        {
            CiticCommon citicCommon = new CiticCommon(LOG_FLAG);
            var json = citicCommon.Invoke(_reqModel);
            //_LogHelperUtil.WriteLog("渠道接口处理结果:{0}", json);
            return json;
        }
        catch (ResponseErrorException ex)
        {
            throw new ResponseErrorException("【上游通道】" + ex.Message);
        }
    }
}

 

派生类之一_61InitJSAPI(实现的支付接口是公众号/服务窗),重写Invoke方法:

public class _61InitJSAPI : CiticAPIBase<JSPayRequestDTO, JSPayResponseDTO>
{    
    public override JSPayResponseDTO Invoke(JSPayRequestDTO reqDto)
    {
        var citicReqDto = new _61InitJSAPIRequestModel()
        {
            out_trade_no = reqDto.order_no,
            body = reqDto.goods_name,
            total_fee = reqDto.pay_money,
            mch_create_ip = ReadIp.Ip_GetIPAddress(),
            notify_url = PartnerConfig.PayNotifyUrl,
            callback_url = reqDto.return_url,
            is_raw = "1", //reqModel1.is_raw, 我司与青岛中信配的是原生态js支付。所以,这里写死。

            sub_openid = reqDto.user_client_name,//TODO:
            mch_id = reqDto.merchant_id,
        };
        if (citicReqDto.mch_id == PartnerConfig.MCH_ID_TEST)
        {
            citicReqDto.sub_openid = string.Empty;
        }

        //----调用中信支付通道
        var json = base.Communicate(citicReqDto);
        var respModel = JsonConvert.DeserializeObject<_61InitJSAPIResponseModel>(json);
        string pay_url = string.Format("https://pay.swiftpass.cn/pay/jspay?token_id={0}&showwxtitle=1", model.token_id);
        var returnDto = new JSPayResponseDTO()
        {
            StatusIsSuccess = true,
            ReturnCodeIsSuccess = true,
            pay_info = respModel.pay_info,
            pay_url = pay_url,
        };
        return returnDto;
    }
}

 

派生类之一_8Reverse代码(实现的支付接口是关单),重写Invoke方法:

/// <summary>
/// 8 关闭订单接口
/// </summary>
public class _8Reverse : CiticAPIBase<ReverseRequestDTO, ResponseDTOBase>
{
    public _8Reverse(string logFlag) : base(logFlag) { }

    public override ResponseDTOBase Invoke(ReverseRequestDTO reqDto)
    {
        ... ...
    }
}

 

接下来说实现方案。

我是从构造方法入手的,构造方法加了个logFlag参数。调用方在初始化具体的对象时,传递logFlag。基类变成了如下的样子:

public abstract class CiticAPIBase<TRequestModel, TResponseModel>
    where TRequestModel : RequestDTOBase
    where TResponseModel : ResponseDTOBase
{

    readonly string LOG_FLAG = string.Format("[{0}CITIC{1}]", DateTime.Now.ToString("HHmmss"), new Random().Next(9999));
    protected LogHelperUtil _LogHelperUtil;

    public CiticAPIBase(string logFlag)
    {
        LOG_FLAG = logFlag + LOG_FLAG;
        _LogHelperUtil = new LogHelperUtil(LOG_FLAG);
    }

    public abstract TResponseModel Invoke(TRequestModel reqModel);

    public string Communicate(RequestModelCommon citicReqModel)
    {
        ... ...
    }
}

 

然后,每个派生类都要显式声明构造方法,加上logFlag参数:

public class _61InitJSAPI : CiticAPIBase<JSPayRequestDTO, JSPayResponseDTO>
{
    public _61InitJSAPI(string logFlag) : base(logFlag) { }

    public override JSPayResponseDTO Invoke(JSPayRequestDTO reqDto)
    {
        ... ....
    }
}

public class _8Reverse : CiticAPIBase<ReverseRequestDTO, ResponseDTOBase>
{
    public _8Reverse(string logFlag) : base(logFlag) { }

    public override ResponseDTOBase Invoke(ReverseRequestDTO reqDto)
    {
        ... ...
    }
}

 

8个派生都这么改还是挺麻烦的,也违背了OCP原则。另外,从领域的角度来说,logFlag参数与整个功能并无关系,只是为了完善记录日志才“生硬地”加这么一个参数。所以,上面的实现方案不妥。改为封装一个LogFlag属性。这样,只需修改基类,派生类无需任何改动。调用方在实例化对象后,可以为LogFlag属性赋值(if possible)。

public abstract class CiticAPIBase<TRequestModel, TResponseModel>
    where TRequestModel : RequestDTOBase
    where TResponseModel : ResponseDTOBase
{
    public string LogFlag { set { _LOG_FLAG = value + _LOG_FLAG; } }

    string _LOG_FLAG = "";
    protected LogHelperUtil _LogHelperUtil;

    public CiticAPIBase()
    {
        _LOG_FLAG = string.Format("[{0}CITIC{1}]", DateTime.Now.ToString("HHmmss"), new Random().Next(9999));
        _LogHelperUtil = new LogHelperUtil(_LOG_FLAG);
    }

    public abstract TResponseModel Invoke(TRequestModel reqModel);

    public string Communicate(RequestModelCommon citicReqModel)
    {
        ... ...
    }
}

 

发表评论
用户名: 匿名