如何在成员函数和非成员函数之间进行选择？

Question

Effective C++ says to "Prefer non-member non-frend functions to member functions" (item 23). The rationale makes sense to me: it minimizes the API "surface area". But in practice, I often find it hard to convince people (including myself) to follow. For example, suppose I have some shape classes, and they are supposed to support perimeter and area calculations:

// @interface
class Shape {
 public:
  virtual double Area() = 0;
  virtual double Perimeter() = 0;
}

class Rectangle : public Shape {
 public:
  Rectangle(double width, double height);

  double width();
  double height();

  ...
};

class Circle : public Shape {
 public:
  Circle(double radius);

  double radius();
  ...
};

According to this advice, it seems that Area and Perimeter should be non-member non-friend functions (not methods), because they can be. Eg area of a Rectangle can be calculated from the width and height methods like so:

double Area(const Rectangle& rectangle) {
  return rectangle.width() * rectangle.height();
}

In fact, neither Rectangle nor Circle have any internal state that isn't exposed by their getters, and it's hard to imagine how that would ever be the case. Therefore, any function that operates on these should not be a method. Another example:

// The diameter of a shape is the (circle) diameter of the smallest circle
// that contains a shape.
double Diameter(const Rectangle& rectangle) {
  double w = rectangle.width();
  double h = rectangle.height();
  return sqrt(w * w + h * h);
}

Am I missing something here? Or is this actually bad advice??

Answer 1

If you need to calculate the area of polymorphic Shape objects, then Scott's advice is not for your case. Because you cannot calculate the area with an external function, because in fact you don't have public access to the information that is required. Namely, whether the object is actually a circle, a rectangle, or something else. So this is a job for virtual functions.

In fact, in Scott's psuedo-code algorithm for determining the correct placement of a function (taken from this article , as I do not have the book), the first test is this:

if (f needs to be virtual)
    make f a member function of C;

Answer 2

What do you have if you have a class with some variables that are directly accessible via getters and setters? Right, nothing more or less than a struct with an "object oriented" facade. There is absolutely nothing object oriented around the usage of such a data container.

The whole point about object orientation, as I percieve it, is to model behaviour , not data . In this respect, an abstract shape class with pure virtual methods to calculate area and perimeter is a perfectly valid design: It abstracts from the data and exposes the behaviour that you need. If I were you, I would think twice about adding the getters for the fundamental parameters (no useful abstraction), and thrice about adding the respective setters (breaks encapsulation).

But, by all means, do not be religious about either having accessors, or not having them, or avoiding simple plain old data structures, or even about an object oriented design. All of this has it's uses, and avoiding it for the sake of avoiding it will lead to a poor design in one case or another. All I'm saying is: Think about what best suits your needs, and then do it entirely indifferent to what religious rules some big programmers have come up with.