На занятиях 23.10.19 рассматривался вопрос об отделении const-only (read-only) части интерфейсных классов в отдельные интерфейсные классы. Например, у нас мог бы быть класс Const_matrix_base с методом shape, от которого наследовали бы Matrix_base с методом reshape и Const_bit_matrix с методом get. Bit_matrix в таком случае наследовал бы и Matrix_base и Const_bit_matrix, создавая классическую проблему ромбовидного наследования с Const_matrix_base на вершине. С ней можно бороться виртуальным наследованием, но, всё же, мне не нравится этот путь.
отказ от Const интерфейсов, пусть будут интерфейсы с const- и не-const- методами. Их const- часть это и есть "Const" интерфейс. Таким образом, виртуальное наследование не требуется, число интерфейсов вдвое меньше, иерархия проще;
у не-Const_ интерфейсов, тем не менее, могут быть наследники, реализующие только const-методы (например, вычисляющие элементы матрицы по формуле, зависящей от индексов), а не-const-методы формально закрывающие заглушками, которые бросают исключение, если это возможно (если нет noexcept). Предполагается, что объекты таких наследников должны возвращаться фабричными методами как указатели на константу, пользователь не должен снимать эту константу (иначе, фактически влечёт UB).
На занятиях 23.10.19 рассматривался вопрос об отделении const-only (read-only) части интерфейсных классов в отдельные интерфейсные классы. Например, у нас мог бы быть класс Const_matrix_base с методом shape, от которого наследовали бы Matrix_base с методом reshape и Const_bit_matrix с методом get. Bit_matrix в таком случае наследовал бы и Matrix_base и Const_bit_matrix, создавая классическую проблему ромбовидного наследования с Const_matrix_base на вершине. С ней можно бороться виртуальным наследованием, но, всё же, мне не нравится этот путь.