4

所以，我有四门课：

App - 这代表应用程序的入口点

MainPage - 这代表主屏幕

Authenticator - 这表示用于身份验证的助手/实用程序类

LoginPage - 这代表一个登录屏幕。

App、MainPage 和 LoginPage 都有指向 Authenticator 的指针，实际上，它是在用户启动应用程序、到达主屏幕并提示登录时从 App、MainPage、LoginPage 传递的。 App创建MainPage，如果MainPage需要登录，则创建LoginPage。Authenticator 指针在创建时传递。

假设 Authenticator 看起来像这样：

class Authenticator {
public:
   std::string GetToken() const;
   void Login(std::string username, std::string pass);
}

现在，App 将创建一个指向 Authenticator 的普通非 const 指针，但因为我不希望 MainPage 能够修改 Authenticator，我希望它存储一个指向它的 const 指针（即它只能调用 const 成员函数它）。但是，我希望 LoginPage 能够调用非 const 成员函数，例如 Login()，因此当我将 Authenticator 从 MainPage 传递到 LoginPage 时，我需要抛弃 const-ness。

我的问题是：在这种情况下这样做不好吗？不允许修改对象的类是否应该能够将其传递给可以修改的类？还是让 App 同时创建 MainPage 和 LoginPage 并为它们提供相同的 Authenticator 会更好吗？我对这个选项的唯一问题是我主动创建了一个 LoginPage，而不是懒惰，我更喜欢懒惰地做。

提前致谢。

4

4 回答 4

2

从应用程序的角度来看，MainPage正在修改 Authenticator。如果它直接这样做或调用另一方（LoginPage）代表它这样做并不重要。所以 MainPage 应该得到一个非常量指针，然后应该将它传递给它的子页面进行登录。

如果你想确保你的 MainPage 不会修改 Authenticator，你可以为它实现一个基类来存储这个指针并有一个方法来调用登录对话框。Authenticator 是私有的，方法是受保护的。然后，您可以派生自己的 MainPageDerived ，它没有（合法的、非骇客的）机会来修改 Authenticator 但可以在需要时调用 LoginPage 。

请注意，我说可以，因为对于 3 门课程，我认为这是过度设计的。但是，如果您将来有更多页面，这可能是一种有效的方法。

于 2013-04-16T07:40:34.450 回答
1

您缺少逻辑常量概念的重要部分。当一个类接受指向 const 对象的指针（或引用）时，它承诺永远不会以可能修改对象的方式使用指针/引用。这当然意味着传递给可以修改它的其他人。

换句话说，如果MainPage计划要求某人修改Authenticator它（即，将指向它的非常量指针传递给其他人），它也负责修改，因此应该存储一个非常量指针它。

于 2013-04-16T07:40:09.313 回答
1

从接口的角度来看：如果你有MainPage( Authenticator const* )，你就在保证没有任何事情MainPage 会改变 的可观察状态Authenticator。直接或间接地——如果MainPage稍后将它的指针传递给另一个将修改对象的类，你就违反了合同。因此，在您的情况下，它的 const 正确性要求MainPage( Authenticator* )：代码构造 MainPage不关心修改是直接的还是间接的；它只是想知道合同是什么，并且它得到维护。

于 2013-04-16T07:40:42.760 回答
0

只给MainPage它需要的东西。你可以从几个方面来看。它可能需要：

  • 一个AuthenticationTokenSource提供最新的Token.
  • AnAuthenticatedExectuor执行ActionsMainPage定义，但AuthenticatedExectuor在调用时提供身份验证Action

可能还有其他方法，但首先想到的是这些方法。

于 2013-04-16T07:46:26.427 回答