leveldb log_reader.h/ Рассмотрение дизайна класса Reader

Question

Я нахожу класс Reader дизайн таким образом. у нас есть имя класса Reader, затем мы предоставляем интерфейс класса Reporter

class Reader {
...
class Reporter {
   public:
    virtual ~Reporter();

    // Some corruption was detected.  "size" is the approximate number
    // of bytes dropped due to the corruption.
    virtual void Corruption(size_t bytes, const Status& status) = 0;
};
};

почему мы должны проектировать этот путь? В своей интуиции я предоставлю чисто виртуальную функцию Corruption в классе Reader?

class Reader {

virtual void Corruption(size_t bytes, const Status& status) = 0;
};

Затем, если я захочу использовать класс Reader, я унаследую от класса Reader и предоставлю свою собственную реализацию Corruption.

Я думаю, что разница здесь заключается в том, что, если мы поступим так, как leveldb db, пользователю нужно только знать, как реализовать интерфейс Reporter. Но в моем наследии от класса Reader пользователю необходимо знать весь класс Reader.

Таким образом, способ leveldb обеспечивает большую инкапсуляцию.

Это правильное соображение в степени Левелдба