为什么不使用嵌套结构来分离函数和数据呢

Why not separating functions and data with nested structs?

本文关键字：函数 数据 分离 嵌套 结构 为什么不      更新时间：2023-10-16

我经常考虑避免在toString方法、初始化列表等中"忘记成员变量"，。。。此外，我经常看到对象本身的逻辑（数据使用和操作）与纯数据护理（初始化、获取/设置、复制的构造函数、rval复制、bla）混合在一起。

如果涉及到有很多方法和成员变量的真正大的类，就会非常令人困惑。

那么，为什么程序员不把所有变量放在一个嵌套的结构中，只做数据处理和提取业务逻辑呢？

我想

class NestedStructTesting
{
public:
    typedef struct TData
    {
    private:
        int var1;
        float var2;
    public:
        int getVar1(){return var1;};
        void setvar1(int value){var1 = value;};
        int getVar2(){return var2;};
        void setvar2(int value){var2 = value;};     
        TData()
        {
            var1 = 0;
            var2 = 0;
        }
    };
    TData Data;

    NestedStructTesting(void)
        : Data()
    {
    };

};

可能会接到外部电话，比如：嵌套结构测试st；st数据setvar1（）

（我没有在大型项目中使用它的任何经验，因为我还没有建立一个）

这个模式已经存在，它被称为PIMPL习惯用法，它隐藏了所有的类数据。

有了它，您就可以将公共方法与私有方法和数据分离开来，而这些方法和数据只存在于.cpp.中

举个例子，所有的Qt框架都是用这个习惯用法构建的，所以你永远不会（也许会夸大，但你明白了）在它们提供的数百个头文件中看到任何私有类变量，只有公共（和虚拟保护）方法。

PIMPL习惯用法的其他好处是，它简化了二进制兼容性，使类接口更清晰（通过从头文件中删除私有和非虚拟受保护的成员），减少编译时间（通过从头文件中删除#includes），并将接口与实现分离（通过隐藏依赖于实现的变量和方法，这些变量和方法通常是私有的）

因为如果您处于这种情况，那么您很可能需要创建另一个类来分配您的大类正在做的大量工作。在这种情况下，您也很可能将该内部类放在其自己的.hpp/.cpp文件中。

如果您认为类的逻辑彼此非常接近，因此它们最好位于相同的文件中，或者只是因为您在整体设计中填充得更干净，那么您可以使用内部类。

AFAIK嵌套类只有一个限制，即不能在任何情况下都转发声明它们。

更一般地说，除非你有一个类似MVC的模式，否则你不想把数据从逻辑中分离出来，而是想把小块数据和它们对应的小块逻辑分组，这是实现OOP最简单有效的方法之一。事实上，在框架设计之外，许多开发人员选择了一个分离单元，它不一定是代码的性质/类型（数据/逻辑/其他），而是它的大小，无论好坏：）

相关文章：