Questions about an article introducing the C ++ interface

Question

I read an article about C ++ interfaces ( http://accu.org/index.php/journals/233 ), and I'm completely lost in the part where it says that all virtual member functions should be private (section "Strengthening separation "). It just doesn't make sense to me at all.

According to the author, the code looks like this:

class shape { public: virtual ~shape(); virtual void move_x(distance x) = 0; virtual void move_y(distance y) = 0; virtual void rotate(angle rotation) = 0; //... }; class line : public shape { public: line(point end_point_1, point end_point_2); //... private: virtual ~line(); virtual void move_x(distance x); virtual void move_y(distance y); virtual void rotate(angle rotation); //... }; 

So, we have a pure virtual function, which is publicly available, and its implementation (in the string class), which is private.

Can anyone explain how the function move_x can be called? Its access specifier is private, this will result in an error if I try to do this:

 line my_line(point(0,0), point(1,2)); my_line.move_x(-1); // does not compile 

Is it also fair to say that the drawing interface (see earlier in the article) cannot access these functions?

Thanks.

Answer 1

The idea is that you use these methods with a link or pointer to shape .

 shape &s = my_line; s.move_x(-1); 

This may be justified on the basis of “disclose only what you need” or as a form of self-documentation. This proves that methods are called only as intended.

Answer 2

If you have a line object, you might be tempted to call its methods. But if the only way to get them is to ask for the shape interface, then the object will look like an object like something more like a collection of interfaces.

This makes sense if you imagine a line that implements more than one interface.

Answer 3

This advice applies only to homogeneous hierarchies, that is, hierarchies in which derived classes do not introduce any new functions (except for constructors) and simply redefine the functions of the base class. In this case, you obviously do not need to work with the line instance directly - only with the help of a pointer / link to shape .

If you have a less uniform hierarchy, this advice does not make much sense: how to apply it to cases where a derived class introduces new functions or inherits them from another base class? In this case, you sometimes want to work directly with objects of the derived class, and this advice will only lead to inconvenience.

Further development of this idea - less radical and useful in a larger context - Non-virtual interface (NVI) from Herb Sutter.

Answer 4

I think the article well illuminates the rationale for this quote:

Now the only thing that users can do with the string is instantiate it. All use should be through its interface - i.e. forms, thereby providing separation of the interface / implementation. Before leaving this topic, it is important to get something straightforward: in order to enforce compliance, the interface / implementation separation does not tell users what to do. Rather, the goal is to make logical separation - now the code explains that the key abstraction of the form, and this line serves to ensure the implementation of the form.

That is, line not interesting in itself. This is just an implementation of the shape interface, and there may be other implementations. You are particularly interested in the shape interface. Therefore, you should only access the implementation through this interface, and not as a separate class.