在SO上已经问了几个有关C ++中访问器方法的问题，但没有一个能满足我对此问题的好奇心。

我尝试尽可能避免访问器，因为像Stroustrup和其他著名的程序员一样，我认为带有很多此类的类是OO不好的标志。在C ++中，在大多数情况下，我可以为类增加更多责任，或使用friend关键字避免此类情况。但是在某些情况下，您确实需要访问特定的班级成员。

有几种可能性：

1.完全不使用访问器

我们可以仅公开各个成员变量。在Java中这是不行的，但对于C ++社区似乎可以。但是，我有点担心要返回一个对象的显式副本或只读（const）引用，是否夸大了？

2.使用Java风格的get / set方法

我不确定它是否完全来自Java，但是我的意思是：

int getAmount(); // Returns the amount
void setAmount(int amount); // Sets the amount

3.使用客观的C风格的获取/设置方法

这有点奇怪，但显然越来越普遍：

int amount(); // Returns the amount
void amount(int amount); // Sets the amount

为了使它起作用，您将不得不为您的成员变量找到一个不同的名称。有些人在下划线后面加上下划线，其他人则在前面加上“ m_”。我也不喜欢

您使用哪种风格，为什么？

从维护角度来看，坐着400万行C ++代码（这只是一个项目），我的观点是：

• 如果成员是不可变的（即const）或没有依赖性的简单成员（例如具有成员X和Y的点类），则不要使用getters / setter方法。

• 如果private只有成员，也可以跳过getter / setter。我也算内部的成员PIMPL -班如private如果在.cpp单元短小。

• 如果member是publicor或protected（protected与一样糟糕public）并且non- const，non-simple或具有依赖项，则使用getters / setters。

作为一名维护人员，我想要使用吸气剂/塞特剂的主要原因是因为那时我有一个放置断点/记录/其他地方的地方。

我更喜欢替代方法2的样式，因为它更易于搜索（编写可维护代码的关键组成部分）。

2）是最好的IMO，因为它使您的意图最清晰。 set_amount(10)比更加有意义amount(10)，并且作为一个很好的副作用，允许名为的成员amount。

公共变量通常不是一个好主意，因为没有封装。假设您需要在更新变量时更新缓存或刷新窗口？如果您的变量是公共的，那就太糟糕了。如果有设置方法，则可以在其中添加它。

1. 我从不使用这种风格。因为它可能会限制类设计的未来，并且显式的getter或setter对于好的编译器同样有效。

   当然，实际上，内联显式getter或setter会在类实现上创建尽可能多的基础依赖。它们只是减少了语义依赖性。如果更改它们，您仍然必须重新编译所有内容。

2. 这是我使用访问器方法时的默认样式。

3. 这种风格对我来说似乎太“聪明”了。我确实在极少数情况下使用它，但仅在我确实希望访问器尽可能感觉像变量的情况下使用。

我确实认为有一种简单的变量袋可能带有构造函数，以确保它们都被初始化为合理的情况。当我这样做时，我只是将其设为a，struct然后将其全部公开。

1. 如果我们只想表示pure数据，那是一个很好的样式。

2. 我不喜欢它:)，因为get_/set_当我们可以在C ++中重载它们时，这确实是不必要的。

3. STL使用这种样式，例如std::streamString::str和std::ios_base::flags，除非应避免使用！什么时候？当方法的名称与其他类型的名称冲突时，则使用get_/set_样式，例如std::string::get_allocator因为std::allocator。

总的来说，我认为系统中有太多的实体使用太多的getter和setter并不是一个好主意。这仅表示设计不良或封装错误。

话虽如此，如果这样的设计需要重构，并且源代码可用，我宁愿使用“访客设计”模式。原因是：

一种。它给全班同学一个机会，让他们决定允许谁访问其私有国家

b。它给班级一个机会，以决定允许对其私有状态感兴趣的每个实体使用哪种访问权限

C。它通过清晰的类接口清楚地记录了此类外部访问

基本思想是：

a）如有可能，请重新设计，

b）重构为

1. 所有对类状态的访问都通过一个众所周知的个人 界面

2. 应该可以为每个这样的接口配置某种操作，例如 应该允许来自外部实体GOOD的所有访问，应该禁止来自外部实体BAD的所有访问，并且 应该允许外部实体OK进行访问，但是未设置（例如）

1. 我不会排除访问器的使用。可能对于某些POD结构而言，但我认为它们是一件好事（某些访问器可能也具有其他逻辑）。

2. 如果您的代码一致，则命名约定并不重要。如果您正在使用多个第三方库，则它们可能仍会使用不同的命名约定。因此，这是一个品味问题。

另一种可能是：

int& amount();

我不确定我是否会推荐它，但是它具有的优点是，这种不寻常的符号可以阻止用户修改数据。

str.length() = 5; // Ok string is a very bad example :)

有时，这也许只是一个不错的选择：

image(point) = 255;  

再次可能的是，使用功能符号来修改对象。

edit::change_amount(obj, val)

这样，危险/编辑功能可以通过其自己的文档放在单独的命名空间中。这似乎是通用编程自然而然的。

我已经看到了类的理想化，而不是整数类型来引用有意义的数据。

以下类似内容通常无法很好地利用C ++属性：

struct particle {
    float mass;
    float acceleration;
    float velocity;
} p;

为什么？因为p.mass * p.acceleration的结果是一个浮点数，而不是强制值。

定义类以指定目的（即使它是一个值，例如前面提到的金额）更有意义，并且允许我们执行以下操作：

struct amount
{
    int value;

    amount() : value( 0 ) {}
    amount( int value0 ) : value( value0 ) {}
    operator int()& { return value; }
    operator int()const& { return value; }
    amount& operator = ( int const newvalue )
    {
        value = newvalue;
        return *this;
    }
};

您可以通过运算符int隐式访问数量中的值。此外：

struct wage
{
    amount balance;

    operator amount()& { return balance; }
    operator amount()const& { return balance; }
    wage& operator = ( amount const&  newbalance )
    {
        balance = newbalance;
        return *this;
    }
};

Getter / Setter用法：

void wage_test()
{
    wage worker;
    (amount&)worker = 100; // if you like this, can remove = operator
    worker = amount(105);  // an alternative if the first one is too weird
    int value = (amount)worker; // getting amount is more clear
}

这是一种不同的方法，并不意味着它的好坏，而是不同的。

让我告诉您另外一种可能性，这似乎是最简洁的。

需要阅读和修改

只需将变量声明为public：

class Worker {
public:
    int wage = 5000;
}

worker.wage = 8000;
cout << worker.wage << endl;

只需要阅读

class Worker {
    int _wage = 5000;
public:
    inline int wage() {
        return _wage;
    }
}

worker.wage = 8000; // error !!
cout << worker.wage() << endl;

这种方法的缺点是，当您要更改访问模式时，需要更改所有调用代码（即添加括号）。

＃3的变化，我被告知这可能是“流利的”风格

class foo {
  private: int bar;
  private: int narf;
  public: foo & bar(int);
  public: int bar();
  public: foo & narf(int);
  public: int narf();
};

//multi set (get is as expected)
foo f; f.bar(2).narf(3);