Справочный возврат для сеттера

A. Насколько полезным/громоздким является следующий прием использования одной и той же функции для получения и установки, возвращая ссылку?

B. Насколько хороша практика добавления const в конец объявлений функций в случае геттеров и сеттеров?

#include <iostream>

class A
{
  int varReadWrite_;
  int varReadOnly_;
  int varRestricted_;

public:
  A() : varReadOnly_(25) {}
  virtual ~A() {}

  int& varReadWrite() { return varReadWrite_; }
  int varReadOnly() { return varReadOnly_; }
  int varRestricted() { return varRestricted_; }
  void setVarRestricted(int i); //throwable

};

int main(int argc, char *argv[])
{
  A a;
  a.varReadWrite() = 45;
  std::cout << a.varReadOnly() << a.varReadWrite() << std::endl;
  return 0;
}

Причины, по которым я выбрал этот дизайн, были:

1. простота доступа к явно доступным только для чтения или явно записываемым переменным.
2. ограниченные (я не знаю, как еще их назвать), переменные, которые требуют очистки и фильтрации перед назначением - эти переменные могут потребовать явного установщика.

Использование ускорить карту fusion также является интересной возможностью, как здесь

Обновить

Const Reference Members интересны для доступа к переменным только для чтения, например.

class A {
  int mA;
public:
  int& a;
  A(int a_ = 0) : mA(a_), a(mA) {}
};

Практически это связано с дополнительными усилиями по кодированию конструкторов копирования и перемещения, что является приемлемым компромиссом для меня.

Cpp Reference Copy Construtor говорит

Неявно объявленный или заданный по умолчанию конструктор копирования для класса T определяется как удаленный, если... T имеет нестатические элементы данных, которые нельзя скопировать (удалены, недоступны, или неоднозначные конструкторы копирования);