对层次结构的一般建议 [英] General advice on hierarchical structs

问题描述

编辑：我将离开我最初发布的问题的第一部分，虽然我现在可以看到，我在最后的问题结束了。我总是把一切都非常字面上，有时让我惊讶，其他人不。我知道这是我自己的缺点。我试图重新整理问题，希望能更好地沟通我实际寻找什么样的答案。

让我开始说实际的实现这可能没什么关系，因为我在一个非常小规模的项目，但我一直重视理论，以便我开发正确的习惯从一开始，因此我倾向于被困在地方它没有真正重要。让我们假装它很重要，但。我很想知道我在这种情况下的不同选择的优缺点。

Let me begin by saying that the actual implementation of this probably doesn't matter much since I'm working on a very small-scale project but I've always valued theory highly so that I develop the right habits right from the beginning, and as such I tend to get stuck in places where it doesn't really matter. Let's pretend that it matters, though. I'm eager to know the pros and cons of the different options that I have in this situation.

我正在一个程序，你可以自定义环境你的喜好。一个这样的环境的设置被称为配置文件。您可以在多个个人资料之间切换，并且一次只能有一个个人资料处于活动状态。

I'm working on a program where you can customize the environment to your liking. The settings for one such environment is called a profile. You can switch between several profiles, and only one profile may be active at one time.

这可能是我将来要更新程序，可能会尝试加载过时的配置文件格式，其中缺少某些设置。为了使自己更简单，并确保向后兼容性，我决定创建一个名为 ProfileManager 的类，它将加载配置文件格式并在必要时更新。

It is possible that I may want to update the program in the future which means I could potentially try to load an outdated profile format where certain settings are missing. To make things easier on myself and to ensure backwards compatibility I have decided to make a class called ProfileManager that will load the profile formats and update them if necessary.

我还决定使用一个 struct Profile 来保存所有的设置，这就是我的问题。

I have also decided to make a struct Profile that will hold all the settings, and this is where my question comes into the picture.

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

See the three versions I have tried out here:

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;
};

版本1很简单，我相信它的性能和内存使用比版本2和三个（如果有什么不同，就是）。

Version one is simple, and I'm sure it scores better on performance and memory usage than version two and three (if there is any difference, that is). The names can get really long, though, and I'm not a fan of long identifiers.

在版本二中，我可以使用更短的标识符，而且我真的很喜欢。而是使用 profile.color_palette.pos.x 比 profile.color_palette_pos_x 识别属性。但有一个缺点。当我键入 profile。它建议窗口这不是一个属性，但结构，我没有使用，我不是直接在 profile.h 内部工作。

In version two I can use much shorter identifiers, and I'd really rather identify a property using profile.color_palette.pos.x than profile.color_palette_pos_x. There is one drawback, though. When I type profile. it suggests window which is not a property but a struct and I have no use for that when I'm not working directly inside of profile.h.

第三版解决了我使用版本一个和两个但它引入了一个新的问题。当我输入配置文件它建议 some_setting ，我不应该能够通过个人资料，只能通过 profile.general_settings 。这只是Code :: Blocks是奇怪的，还是有一些根本的，我只是不知道吗？

Version three solves the problems that I have with versions one and two but it introduces a new problem. When I type profile. it suggests some_setting which I shouldn't be able to access through profile, only through profile.general_settings. Is that just Code::Blocks being weird or is there something fundamental that I just don't know about?

所以我的问题（改写）：

• 是否客观地选择使用任何我的示例结构？也就是说，他们中的任何一个比其他人的表现略差？与版本1相比，嵌套结构使用了过多的内存吗？任何版本比其他版本更容易出错？我只是在这里寻找是或否的答案，所以我知道，如果这是不明智的与他们任何一个去。在决定要使用的结构时，我应该记住一些其他的东西吗？


• 在决定是否使用某个结构时，是否有任何不成文的规则或一些常见的知识不使用嵌套结构？再次，我只是在这里寻找一个是或否。


• 有人希望我使用嵌套结构的任何命名约定（类名为 LikeThis ，getters和setters通常命名为 like_this ）？我应该将它们声明在我打算使用它们的范围之内还是之外？我已经读过，人们通常建议反对更广泛的范围，而不是必要的，我只是要求确保，因为我从来没有工作过的环境里面的类是可取的，甚至是合法的。

• Would it be an objectively wrong choice to use any of my sample structures? That is, are any of them marginally worse than the others performance-wise? Do the nested structs use an excessive amount of memory compared to version one? Are any of the versions more prone to bugs than the others? I am simply looking for yes or no answers here so that I know if it would be unwise of me to go with any one of them. Is there, perhaps, something else I should keep in mind when deciding on a structure to use?
• Are there any unwritten rules or some common knowledge that people have in mind when deciding on whether or not to use nested structs? Again, I'm simply looking for a yes or a no here.
• Are there any naming conventions that people expect me to use for nested structs (like classes are named LikeThis and getters and setters are usually named like_this)? Should I declare them inside or outside of the scope in which I intend to use them? I have read that people usually advise against a broader scope than necessary and I am simply asking to make sure because I have never before worked in a milieu where classes inside of classes is advisable or even legal.

推荐答案

• 在这种情况下，超过其他？ （这可能是我没有想到的）

不，完全取决于

• 嵌套结构体（至少是嵌套结构体声明似乎引入更多的问题，他们解决，他们大大降低可读性，所以我的直觉告诉我，我应该避免它。

• 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紧密耦合（即，像标准容器迭代器类耦合到它们相关联的容器实现）的时间。

Nested structs have their use cases per se, most of the time if the nested struct/class is tightly coupled to the declaring outer class/struct (i.e. like standard container iterator classes are coupled to their associated container implementations). Using them without having such tightly coupling relation, it will complicate things, yes.

• 如果我使用嵌套的structs，我应该使用结构体或变量的命名约定吗？我应该在我打算使用它们的范围内或之外声明他们吗？

AFAIK没有特殊的命名约定，除了你想要与C ++标准类的模板参数兼容。如果你有类似嵌套的迭代器类定义，将其命名并按照标准算法和其他操作的要求完成合同。

AFAIK there are no special naming conventions, other than you want to have for compatibility with C++ standard classes' template arguments. If you have such like a nested iterator class definition, name it so and fulfill contracts as demanded from the standard algorithm and other operations.

在你的示例＃2中，看起来 interfaces （在类外声明）可能更适合组合这样的关系和抽象。

As it comes figured out in your sample #2, it seems interfaces (that are declared outside your class) might fit better to assemble such relations and abstractions you need

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_)
    {}
};

这篇关于对层次结构的一般建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！