函数的入参使用数据类, 在需求变化时, 提高工程的维护效率

// FunctionParameterUseDataContainer.cpp : Defines the entry point for the console application.
//

/// 函数的入参使用数据类, 在需求变化时, 提高工程的维护效率

/// 今天感觉吃亏了, 需求原来是A, 变成B, 现在又变成A
/// 业务流程基本相同, 只是在同样的流程点上调用不同的3rd接口, 接口的参数类型, 个数, 含义不同
/// 原来传的是独立的参数本身(内建类型, 或业务类指针), 需要几个参数就传几个
/// 当需求由A变成B时, 函数调用 FunA(int iKey, SomeClass* pClass) => FunA(const WCHAR* pcToken)
/// 因为中间还有些被耦合的函数, 导致 需求A=>B时, 从业务的起点到终点的几十个函数接口都要变.
/// 反思后发现, 要传一个数据类, 将需求A, B可能包含的参数都放在里面进行传递, 
/// 如果以后有了需求C, 只要流程基本不变, 那维护的工作量就小很多.
/// 需要改动的地方只有2块, 
/// * 传入的参数在数据类中的变化
/// * 调用3rd接口时, 将数据类中对应的参数传给3rd接口

/// 想起总结这个支持点的原因:
/// 从需求A=>需求B, 用了2天, 修改, 测试
/// 从需求B=>需求A, 用了2.5天, 修改, 测试
/// 这两个需求点之间的间隔时间为2个月左右, 等到B=>A时, 重新理解实现细节也用了一些时间
/// 如果是用数据类来传参, 基本不用重新理解实现细节, 只需要将开始结束的地方改掉就行.
/// 如果中间层函数用到的数据类成员也随着需求变了, 也改改就好, 维护效率应该大大提升了
/// 我坐等 需求B => 需求C

#include "stdafx.h"
#include <windows.h>
#include <string>
#include <tchar.h>

#define REQUIREMENTS_SWITCH_A ///< 需求A的实现
#define REQUIREMENTS_SWITCH_B ///< 需求B的实现

class SomeClass
{
    SomeClass() {}
    virtual ~SomeClass() {}
};

interface Irequirements
{
    BOOL fnRequirementTaskA(int iKey, SomeClass* pClass)
    {
        /** do something ... */
        return TRUE;
    }

    BOOL fnRequirementTaskB(const WCHAR* pcToken)
    {
        /** do something ... */
        return TRUE;
    }
};

class CDtoParameter
{
public:
    CDtoParameter() {}
    virtual ~CDtoParameter() {}

/// private:
public: ///< @todo ls 应该是一些数据geter, seter接口, 而不应该是public直接存取
    int m_iKey;
    SomeClass* m_pClass;
    std::wstring m_strToken;
};

void fn_middle_layer(CDtoParameter* pIn)
{
    /// 中间层函数用参数做一些事情
};

int _tmain(int argc, _TCHAR* argv[])
{
    CDtoParameter DtoParameter;
    Irequirements Req;

#ifdef REQUIREMENTS_SWITCH_A
    /// 业务开始
    DtoParameter.m_iKey = rand();

    /// 中间层函数 传递DtoParameter...
    /// 这样做的好处是中间层函数一点都不用改, 或改的很少
    /// 如果这些中间层的调用链很长, 将参数封装进数据类进行传递的好处更明显

    /// 业务结束
    Req.fnRequirementTaskA(DtoParameter.m_iKey, DtoParameter.m_pClass);
#endif

#ifdef REQUIREMENTS_SWITCH_B
    /// 业务开始
    DtoParameter.m_strToken = L"Demand change";

    /// 中间层函数 传递DtoParameter...
    /// 这样做的好处是中间层函数一点都不用改, 或改的很少
    /// 如果这些中间层的调用链很长, 将参数封装进数据类进行传递的好处更明显

    /// 业务结束
    Req.fnRequirementTaskB(DtoParameter.m_strToken.c_str());
#endif

    _tprintf(L"不用再怕折中流程相同, 3rd接口参数不同的需求A变化到需求B了");
    return 0;
}