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

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

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)
    {
        ... ...
    }
}
时间： 2024-12-15 23:39:02

多类继承情况下适应变化设计一例的相关文章

C++ Primer 学习笔记_69_面向对象编程 --继承情况下的类作用域

面向对象编程 --继承情况下的类作用域 引言: 在继承情况下,派生类的作用域嵌套在基类作用域中:如果不能在派生类作用域中确定名字,就在外围基类作用域中查找该名字的定义. 正是这种类作用域的层次嵌套使我们能够直接访问基类的成员,就好像这些成员是派生类成员一样: Bulk_item bulk; cout << bulk.book() << endl; 名字book的使用将这样确定[先派生->后基类]: 1)bulk是Bulk_item类对象,在Bulk_item类中查找,找不到名

15.5——继承情况下的类作用域

继承情况下的类作用域: 在继承的情况下,派生类的作用域嵌套在基类作用域的下. 先在派生类的作用域范围内查找,要是没找到,接着在外围的基类作用域中查找. 1. 名字查找在编译时发生 (1)对象,引用或指针的静态类型决定了其所能作用的成员,即使是当动态类型和静态类型可能不一样时也满足 (2)例如使用基类的指针就不能去访问派生类的成员. 2. 名字冲突与继承 (1)当基类和派生类的成员同名时,基类的成员在直接访问时将被屏蔽. (2)可以采用域作用符::来访问被屏蔽的成员. (3)最好不要有基类和派生类

C++对象模型——&quot;无继承&quot;情况下的对象构造(第五章)

5.2 继承体系下的对象构造 当定义一个object如下: T object; 时,实际上会发生什么事情呢?如果T有一个constructor(不论是由user提供或是由编译器合成),它会被调用.这很明显,比较不明显的是,constructor的调用真正伴随了什么? constructor可能内带大量的隐藏码,因为编译器会扩充每一个constructor,扩充程度视 class T的继承体系而定.一般而言,编译器所做的扩充操作大约如下: 1.记录在member initialization li

C++中虚函数的理解，以及简单继承情况下的虚函数的表！

面向对象的三大特征=封装性+继承性+多态性 封装=将客观事物抽象成类,每个类对自身的数据和方法实行权限的控制 继承=实现继承+可视继承+接口继承 多态=将父类对象设置成为和一个或者更多它的子对象相等的技术, 用子类对象给父类对象赋值之后, 父类对象就可以根据当前赋值给它的子对象的特性一不同的方式运作 C++的空类有哪些成员函数 1.缺省构造函数 2.缺省拷贝构造函数 3.缺省析构函数 4.缺省赋值运算符 5.缺省取址运算符 6.缺省取址运算符const PS:只有当实际使用的时候才会去使用这些类

&quot;无继承&quot; 情况下的对象构造

考虑以下代码: Point global; //1) Point Foobar() { Point local; //2) Point *heap = new Point; //3) *heap = local; //4) //...stuff... delete heap; //5) return local; //6) } 1), 2), 3) 为三种不同的对象产生方式: global内存配置, local 内存配置和 heap 内存配置. 4) 把一个object 指定给另一个, 6) 设

Java类什么情况下被初始化？

1.创建类的实例(new 的方式).访问某个类或接口的静态变量,或者对该静态变量赋值,调用类的静态方法 2.反射的方式 3.当初始化一个类的时候,如果发现其父类还没有进行初始化,则需先触发其父类的初始化. 4.Java虚拟机启动时被标明为启动类的类,直接使用java.exe命令来运行某个主类(包含main方法的那个类) 5.当使用 JDK 1.7 的动态语言支持时,如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic.REF_put

有继承情况下的初始化

类初始化 类初始化是执行<clinit>()方法,它的代码由两部分组成: (1)静态变量的显式赋值 (2)静态代码块 它俩是按照编写的顺序组装而成 每一个类的类初始化方法只会执行一次 子类初始化时会先检查父类,如果父类还没有初始化,会先完成父类的初始化,即先执行父类的<clinit>()方法 实例初始化 一个类可能会有1~n个的<init>方法,有几个看声明了几个构造器 实例初始化是执行对应的<init>方法,具体执行哪个,看new后面调用的是哪个构造器 实

C++ Primer 学习笔记_69_面向对象编程 -继承景况下的类作用域

面向对象编程 --继承情况下的类作用域 引言: 在继承情况下,派生类的作用域嵌套在基类作用域中:如果不能在派生类作用域中确定名字,就在外围基类作用域中查找该名字的定义. 正是这种类作用域的层次嵌套使我们能够直接访问基类的成员,就好像这些成员是派生类成员一样: Bulk_item bulk; cout << bulk.book() << endl; 名字book的使用将这样确定[先派生->后基类]: 1)bulk是Bulk_item类对象,在Bulk_item类中查找,找不到名

（转）Java 类的热替换 —— 概念、设计与实现

构建基于 Java 的在线升级系统 对于许多关键性业务或者庞大的 Java 系统来说,如果必须暂停系统服务才能进行系统升级,既会大大影响到系统的可用性,同时也增加了系统的管理和维护成本.因此,如果能够方便地在不停止系统业务的情况下进行系统升级,则可以很好地解决上述问题.在本文中,我们将基于实例,对构建在线升级 Java 系统的基础技术和设计原则进行了深入的讲解.相信读者能够根据文中的技术构建出自己的在线升级系统来. Java ClassLoader 技术剖析 在本文中,我们将不对 Java Cl