c++ - 有关层次结构的一般建议

Question

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便 editing this post用事实和引用来回答。

6年前关闭。



Improve this question




编辑:我将保留问题的第一部分，就像我最初发布的一样，尽管现在我看到我在问题末尾的措辞很差。我总是从字面上看待一切，有时其他人没有做到这一点令我惊讶。我知道这是我自己的缺点。我试图重新表述这些问题，以期更好地交流我实际上正在寻找的答案。

首先，我要说的是，由于我正在进行的是一个很小规模的项目，因此实际的实施可能并不重要，但我始终高度重视理论，以便从一开始就养成正确的习惯，并且因此，我倾向于卡在无关紧要的地方。让我们假装这很重要。在这种情况下，我渴望了解各种选择的利弊。

我正在开发一个程序，您可以根据自己的喜好自定义环境。一种这样的环境的设置称为配置文件。您可以在多个配置文件之间切换，一次只能激活一个配置文件。

我将来可能要更新程序，这意味着我可能会尝试在缺少某些设置的情况下加载过时的配置文件格式。为了使事情变得容易并确保向后兼容，我决定创建一个名为 ProfileManager的类，该类将加载配置文件格式并在必要时进行更新。

我还决定制作一个可以保存所有设置的 struct Profile，这就是我的问题所在的位置。

在这里查看我尝试过的三个版本:

struct Profile
{
    // Version one: lots of variables with closely related names
    bool window_one_open;
    bool window_one_collapsed;
    int window_one_pos_x;
    int window_one_pos_y;
    int window_one_width;
    int window_one_height;

    // Version two: named structs used to easily create multiple entries of the same format
    struct position
    {
        int x;
        int y;
    };

    struct window
    {
        bool open;
        bool collapsed;
        position pos;
        int width;
        int height;
    };

    window color_palette;
    window text_editor;
    window browser;

    // Version three: unnamed struct(s) used to simply group certain variables together
    struct
    {
        bool some_setting;
        bool some_other_setting;
        int important_number;
    } general_settings;
};

第一版很简单，我敢肯定它在性能和内存使用上比第二版和第三版要好(如果有区别，就是这样)。但是，名称可能会变得很长，而且我也不喜欢长标识符。

在第二版中，我可以使用短得多的标识符，并且我真的更愿意使用 profile.color_palette.pos.x而不是 profile.color_palette_pos_x来标识属性。但是，有一个缺点。当我键入 profile.时，它建议使用 window，它不是属性而是结构，当我不直接在 profile.h内部工作时，我没有用。

第三版解决了我在第一版和第二版中遇到的问题，但引入了一个新问题。当我键入 profile.时，它提示我不应该通过 some_setting只能通过 profile访问的 profile.general_settings。这只是Code::Blocks怪异还是我根本不了解的基本知识？

所以我的问题是( 改为):

使用我的任何样本结构在客观上是错误的选择吗？就是说，它们中的任何一个在性能方面都比其他人差一点吗？与版本一相比，嵌套结构是否使用过多的内存？有哪个版本比其他版本更容易出现错误？我只是在这里寻找是或否的答案，以便我知道与他们中的任何一个一起走对我来说是否不明智。在确定要使用的结构时，也许还有其他需要记住的事情吗？

在决定是否使用嵌套结构时，人们会想到任何不成文的规则或一些常识吗？同样，我只是在这里寻找是或否。

人们是否希望我使用任何嵌套结构的命名约定(例如，类命名为LikeThis，而getter和setter的命名通常是like_this)？我应该在打算使用它们的范围之内还是之外声明它们？我已经读到人们通常建议不要将范围扩大到不必要的范围，而我只是想确保，因为我从未在过这样的环境中工作过，在这种环境中，类(class)内部的类(class)是明智的，甚至是合法的。

最佳答案

• In this scenario, is there a structure that is objectively preferrable over others? (it can be something I haven't even thought of)

不，这完全取决于您的实际用例，哪种方法更适合解决它们

• Nested structs (at least, nested struct declarations) seem to introduce more problems than they solve, and they drastically reduce readability, so my gut tells me I should avoid it. What is the general consensus on this?

嵌套结构本身就有其用例，大多数情况下，如果嵌套struct / class与声明的外部类/ struct紧密耦合(即，如标准容器迭代器类与其关联的容器实现耦合)，则大多数情况下。在没有这种紧密耦合关系的情况下使用它们会使事情复杂化，是的。

• If I do use nested structs, should I use the naming conventions for structs or for variables? Should I declare them inside or outside of the scope in which I intend to use them?

AFAIK除了要与C++标准类的模板参数兼容之外，没有特殊的命名约定。如果您有类似嵌套的 iterator类定义的名称，请如此命名，并按照标准算法和其他操作的要求履行契约(Contract)。

正如您在示例2中弄清楚的那样，似乎 接口(interface)(在类外部声明)可能更适合组合此类所需的关系和抽象

struct IPosition {
    virtual int x() const = 0;
    virtual int y() const = 0;

    virtual ~IPosition() {}
};

struct IWindow {
    virtual bool open() const = 0;
    virtual bool collapsed() const = 0;
    virtual const IPosition& pos() const = 0;
    virtual int width() const = 0;
    virtual int height() const = 0;

    virtual ~IWindow() {}
};

struct Profile {
    IWindow& windowOne;
    IWindow& windowTwo;

    // Provide an appropriate IWindow implementation instances 
    // when constructing here
    Profile(IWindow& windowOne_, IWindow& windowTwo_) 
    : windowOne(windowOne_)
    , windowTwo(windowTwo_)
    {}
};

关于c++ - 有关层次结构的一般建议，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24462001/

上一篇：c++ - 使用 libpd 时如何处理不能被 64 整除的音频缓冲区大小？

下一篇：C++通过exec函数杀死子进程，但不杀死父进程和正常运行时间

相关文章：

C++ - 访问可执行文件上的 "dropped"文件

algorithm - 具有 O(1) 索引和 O(1) prev 和 next 的稀疏数组

javascript - 对包含数组的字典进行排序作为值和等级

json - 如何从另一个平面/简单的配置单元表中使用 map[structs] 加载配置单元表

C++ 打印盒子应用程序

c++ - 别名(或类型定义)参数化类的内部类

c++ - 为什么 cin.getline() 不起作用(C++)？

ruby - 查找两个单词之间的相邻单词列表

c - 仅初始化 C 中的一个嵌套结构

performance - 如何在 Go 中通过清晰的结构值优化性能？

Answer 1

• In this scenario, is there a structure that is objectively preferrable over others? (it can be something I haven't even thought of)

不，这完全取决于您的实际用例，哪种方法更适合解决它们

• Nested structs (at least, nested struct declarations) seem to introduce more problems than they solve, and they drastically reduce readability, so my gut tells me I should avoid it. What is the general consensus on this?

嵌套结构本身就有其用例，大多数情况下，如果嵌套struct / class与声明的外部类/ struct紧密耦合(即，如标准容器迭代器类与其关联的容器实现耦合)，则大多数情况下。在没有这种紧密耦合关系的情况下使用它们会使事情复杂化，是的。

• If I do use nested structs, should I use the naming conventions for structs or for variables? Should I declare them inside or outside of the scope in which I intend to use them?

AFAIK除了要与C++标准类的模板参数兼容之外，没有特殊的命名约定。如果您有类似嵌套的 iterator类定义的名称，请如此命名，并按照标准算法和其他操作的要求履行契约(Contract)。

正如您在示例2中弄清楚的那样，似乎 接口(interface)(在类外部声明)可能更适合组合此类所需的关系和抽象

struct IPosition {
    virtual int x() const = 0;
    virtual int y() const = 0;

    virtual ~IPosition() {}
};

struct IWindow {
    virtual bool open() const = 0;
    virtual bool collapsed() const = 0;
    virtual const IPosition& pos() const = 0;
    virtual int width() const = 0;
    virtual int height() const = 0;

    virtual ~IWindow() {}
};

struct Profile {
    IWindow& windowOne;
    IWindow& windowTwo;

    // Provide an appropriate IWindow implementation instances 
    // when constructing here
    Profile(IWindow& windowOne_, IWindow& windowTwo_) 
    : windowOne(windowOne_)
    , windowTwo(windowTwo_)
    {}
};