Не являющийся членом недруг функционирует по сравнению с закрытыми функциями

Я верю в бесплатные функции и согласен с Саттером, но мое понимание находится в противоположном направлении. Дело не в том, что ваши общедоступные методы должны зависеть от бесплатных функций вместо частных, а в том, что вы можете создать более богатый интерфейс вне класса с бесплатными функциями, используя предоставленный открытый интерфейс.

То есть вы не выталкиваете свои личные данные за пределы класса, а скорее сокращаете общедоступный интерфейс до минимума, который позволяет вам создавать остальную функциональность с наименьшей возможной связью: только с использованием общедоступного интерфейса.

12262] В вашем примере за пределы класса я бы вынес метод CalculateDifference, если он может быть эффективно представлен в терминах других операций.

class Number { // small simple interface: accessor to constant data, constructor
public:
  explicit Number( int nNumber ) : m_nNumber( nNumber ) {}
  int value() const { return m_nNumber; }
private:
  int m_nNumber;
};
Number operator+( Number const & lhs, Number const & rhs ) // Add addition to the interface
{
   return Number( lhs.value() + rhs.value() );
}
Number operator-( Number const & lhs, Number const & rhs ) // Add subtraction to the interface
{
   return Number( lhs.value() - rhs.value() );
}

Преимущество состоит в том, что если вы решите переопределить внутреннее устройство Number (с таким простым классом мало что можно сделать), пока вы сохраняете свой общедоступный интерфейс постоянным, все остальные функции будут работать вне коробка. Детали внутренней реализации не заставят вас переопределять все другие методы.

Сложная часть (не в приведенном выше упрощенном примере) - это определение наименьшего интерфейса, который вы должны предоставить. Статья ( GotW # 84 ), на которую ссылается предыдущий вопрос, является отличным примером. Если вы прочтете его подробно, то обнаружите, что можете значительно сократить количество методов в std :: basic_string, сохранив при этом ту же функциональность и производительность. Подсчет снизится с 103 до 32 членов. Это означает, что изменения реализации в классе затронут только 32 члена вместо 103, и поскольку интерфейс сохраняется, 71 свободная функция, которая может реализовать остальную функциональность с точки зрения 32 членов, не должна быть изменена.

Это важный момент: он более инкапсулирован, поскольку вы ограничиваете влияние изменений реализации на код.

Отойдя от исходного вопроса, вот простой пример того, как использование бесплатных функций улучшает локальность изменений в класс. Предположим, что это сложный класс с действительно сложной операцией сложения. Вы можете пойти на это и реализовать все переопределения операторов как функции-члены, или вы можете так же легко и эффективно реализовать только некоторые из них внутри, а остальные предоставить как бесплатные функции:

class ReallyComplex
{
public:
   ReallyComplex& operator+=( ReallyComplex const & rhs );
};
ReallyComplex operator+( ReallyComplex const & lhs, ReallyComplex const & rhs )
{
   ReallyComplex tmp( lhs );
   tmp += rhs;
   return tmp;
}

Легко видеть, что независимо от того, как исходный оператор + = выполняет свою задачу, свободный оператор + выполняет свои обязанности правильно. Теперь, при любых без исключения изменениях в классе, operator + = необходимо будет обновить, но внешний operator + останется нетронутым до конца своей жизни.

Приведенный выше код является общим шаблоном, хотя обычно вместо получения операнда lhs по постоянной ссылке и создания внутри временного объекта его можно изменить так, чтобы параметр сам был копией значения, что помогает компилятор с некоторыми оптимизациями:

ReallyComplex operator+( ReallyComplex lhs, ReallyComplex const & rhs )
{
   lhs += rhs;
   return lhs;
}