使用嵌套公共 C++ 类和枚举的优点和缺点是什么?例如,假设您有一个名为 printer, ,并且此类还存储输出托盘上的信息,您可以:

class printer
{
public:
    std::string name_;

    enum TYPE
    {
        TYPE_LOCAL,
        TYPE_NETWORK,
    };

    class output_tray
    {
        ...
    };
    ...
};

printer prn;
printer::TYPE type;
printer::output_tray tray;

或者:

class printer
{
public:
    std::string name_;
    ...
};

enum PRINTER_TYPE
{
    PRINTER_TYPE_LOCAL,
    PRINTER_TYPE_NETWORK,
};

class output_tray
{
    ...
};

printer prn;
PRINTER_TYPE type;
output_tray tray;

我可以看到嵌套私有枚举/类的好处,但是当涉及到公共枚举/类时,办公室是分裂的——这似乎更多是一种风格选择。

那么,您更喜欢哪一个,为什么?

有帮助吗?

解决方案

嵌套类

嵌套在类中的类有几个副作用,我通常认为这些副作用是缺陷(如果不是纯粹的反模式)。

让我们想象一下以下代码:

class A
{
   public :
      class B { /* etc. */ } ;

   // etc.
} ;

甚至:

class A
{
   public :
      class B ;

   // etc.
} ;

class A::B
{
   public :

   // etc.
} ;

所以:

  • 特权访问: A::B 对 A 的所有成员(方法、变量、符号等)有特权访问,这就削弱了封装性
  • A 的范围是符号查找的候选范围: B 内部的代码将会看到 全部 A 中的符号作为符号查找的可能候选者,这可能会混淆代码
  • 前向声明: 如果不给出 A 的完整声明,就无法前向声明 A::B
  • 可扩展性: 除非您是 A 的所有者,否则不可能添加另一个 A::C 类
  • 代码冗长: 将类放入类中只会使标题变大。您仍然可以将其分成多个声明,但无法使用类似命名空间的别名、导入或使用。

作为结论,除非有例外(例如嵌套类是嵌套类的亲密部分......即便如此......),我认为普通代码中的嵌套类没有任何意义,因为缺陷的重要性远远超过了感知到的优点。

此外,它听起来像是在不使用 C++ 命名空间的情况下模拟命名空间的笨拙尝试。

在专业方面,您隔离此代码,如果是私有的,则使其无法使用,但来自“外部”类......

嵌套枚举

优点:一切。

缺点:没有什么。

事实上,枚举项会污染全局范围:

// collision
enum Value { empty = 7, undefined, defined } ;
enum Glass { empty = 42, half, full } ;

// empty is from Value or Glass?

只有将每个枚举放在不同的命名空间/类中才能避免这种冲突:

namespace Value { enum type { empty = 7, undefined, defined } ; }
namespace Glass { enum type { empty = 42, half, full } ; }

// Value::type e = Value::empty ;
// Glass::type f = Glass::empty ;

请注意,C++0x 定义了类枚举:

enum class Value { empty, undefined, defined } ;
enum class Glass { empty, half, full } ;

// Value e = Value::empty ;
// Glass f = Glass::empty ;

正是针对此类问题。

其他提示

对于大型项目而言可能成为大问题的一个骗局是,无法对嵌套类或枚举进行前向声明。

如果除了使用独立类的实现之外你永远不会使用依赖类,那么在我看来,嵌套类很好。

当你想要使用“内部”时, class本身就是一个对象,事情可以开始变得有点怪异,你必须开始编写提取器/插入器例程。不是一个漂亮的情况。

看起来您应该使用命名空间而不是类来以这种方式将彼此相关的事物分组。我在嵌套类中看到的一个骗局是你最终得到一个非常大的源文件,当你搜索一个部分时,这个文件可能很难理解。

使用嵌套公共 C++ 类本身没有优点和缺点。只有事实。这些事实是 C++ 标准规定的。关于嵌套公共 C++ 类的事实是优点还是缺点取决于您要解决的特定问题。您给出的示例不允许判断嵌套类是否合适。

关于嵌套类的一个事实是,它们具有对其所属类的所有成员的特权访问权限。如果嵌套类不需要此类访问,那么这是一个缺点。但如果嵌套类不需要此类访问,则不应将其声明为嵌套类。有一些情况,当一个班级 A 想要授予某些其他类的特权访问权限 . 。这个问题有三种解决方案

  1. 制作 的朋友 A
  2. 制作 一个嵌套类 A
  3. 制定方法和属性, 的需要,公众成员 A.

在这种情况下,#3 违反了封装,因为 A 可以控制他的朋友和他的嵌套类,但不能控制调用他的公共方法或访问他的公共属性的类。

关于嵌套类的另一个事实是,不可能添加另一个类 答::C 作为一个嵌套类 A 除非您是所有者 A. 。然而,这是完全合理的,因为嵌套类具有特权访问权限。如果可以添加的话 答::C 作为一个嵌套类 A, , 然后 答::C 可以欺骗 A 授予对特权信息的访问权限;并且你会违反封装性。基本上与 friend 宣言:这 friend 声明不授予您任何特殊特权,即您的朋友向他人隐瞒;它允许您的朋友访问您对非朋友隐藏的信息。在 C++ 中,称某人为朋友是一种利他行为,而不是自私行为。这同样适用于允许一个类成为嵌套类。

关于嵌套公共类的其他一些事实:

  • A 的范围是 B 的符号查找的候选范围:如果你不想要这个,请制作 的朋友 A 而不是嵌套类。然而,在某些情况下,您确实需要这种符号查找。
  • 答::B 不能提前声明: A答::B 是紧密耦合的。能够使用 答::B 不知道 A 只会掩盖这个事实。

总结一下:如果该工具不能满足您的需求,请不要责怪该工具;责备自己使用该工具;其他人可能会遇到不同的问题,而该工具对于这些问题来说是完美的。

paercebal说了关于嵌套枚举的所有内容。

WRT嵌套类,我常见且几乎唯一的用例是当我有一个操作特定类型资源的类时,我需要一个表示特定于该资源的数据类。在你的例子中,output_tray可能是一个很好的例子,但是如果类将要从包含类外部调用任何方法,或者主要是一个数据类,我通常不会使用嵌套类。我通常也不嵌套数据类,除非在包含的类之外没有直接引用包含的类。

因此,例如,如果我有一个printer_manipulator类,它可能有一个包含类的打印机操作错误,但打印机本身将是一个非包含类。

希望这会有所帮助。 :)

请记住,您以后可以随时将嵌套类提升为顶级类,但如果不破坏现有代码,则可能无法执行相反的操作。因此,我的建议是首先将它作为嵌套类,如果它开始成为问题,请在下一个版本中将其作为顶级类。

对我而言,将它放在外面的一个重要因素是它成为全局命名空间的一部分。如果枚举或相关类只适用于它所在的类,那么它是有道理的。因此,在打印机的情况下,包含打印机的所有内容都将知道对枚举PRINTER_TYPE的完全访问权限,它实际上并不需要了解它。我不能说我曾经使用过内部类,但是对于一个枚举来说,将它保持在内部似乎更合乎逻辑。正如另一张海报所指出的那样,使用命名空间对相似项进行分组也是一个好主意,因为堵塞全局命名空间确实是件坏事。我之前曾参与过大规模的项目,只需在全局命名空间上创建一个自动完成列表需要20分钟。在我看来,嵌套的枚举和命名空间的类/结构可能是最干净的方法。

我赞同那些主张将你的枚举嵌入到课堂中的帖子,但有些情况下不这样做会更有意义(但请至少把它放在命名空间中)。如果多个类使用在不同类中定义的枚举,那么这些类直接依赖于其他具体类(拥有枚举)。这肯定代表了一个设计缺陷,因为该课程将负责该枚举以及其他职责。

所以,是的,如果其他代码只使用该枚举直接与该具体类接口,则将枚举嵌入到类中。否则,找一个更好的地方来保存枚举,例如命名空间。

如果将枚举放入类或命名空间中,当您尝试记住枚举名称时,智能感知将能够为您提供指导。一件小事可以肯定,但有时小事情很重要。

Visual Studio 2008似乎无法为嵌套类提供intellisense,所以在我过去常常使用嵌套类的大多数情况下,我已经切换到了PIMPL习惯用法。我总是将枚举放在类中,如果它只由该类使用,或者当多个类使用枚举时,在类的同一名称空间中的类之外。

我可以看到嵌套类的con,可以更好地使用泛型编程。

如果小类是在大类之外定义的,你可以使大类成为类模板并使用任何“小”类。以后你可能需要和大班一起上课。

通用编程是一个强大的工具,恕我直言,我们在开发可扩展程序时应该牢记这一点。奇怪的是,没有人提到这一点。

我遇到的嵌套类的唯一问题是C ++不允许我们在嵌套类函数中引用封闭类的对象。我们不能说“Enclosing :: this”

(但也许有办法?)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top