Спецификация для типа в классе с использованием шаблонов (вместо наследования)

Question

При наследовании от класса вы знаете требования и ограничения, налагаемые на вас, просто просматривая иерархию. Например, вы можете узнать, просто посмотрев родительский класс (ы), какие методы должны быть определены (чисто виртуальные). Если кто-то решит использовать шаблоны вместо этого (если он отвечает всем требованиям), тогда все будет не так ясно. Методы класса шаблона могут ожидать нескольких методов для type.

Я наткнулся на сложный класс, который мне нужно использовать. Я не знал, какие методы должен иметь мой type (класс / объект). Единственный способ, которым я мог это выяснить, - это компилировать, где компилятор сообщал мне, какие методы ожидались. Это как наследование от абстрактного класса без доступа к заголовочному файлу. Это немного болезненно, так как выяснение спецификаций метода (подпись) отнимает много времени.

Теперь оригинальный разработчик класса мог поместить некоторую документацию относительно того, какие методы должны присутствовать и их подписи, но я не могу не задаться вопросом, есть ли способ, которым код может быть самодокументирован (или уже и я не знаю, как просмотреть это?). Компиляция и просмотр ошибок не может быть единственным способом, не так ли?

Answer 1

По сути, вы описываете проблему, которую C ++ 0x * собирались решить, предоставив программистам способ применения требований к type во время компиляции. Однако он был удален в июле 2009 года из-за нехватки времени.

В Boost существует решение только для библиотеки, которое называется Библиотека проверки концепций (BCCL). Однако существуют различия между BCCL и концепциями C ++ 0x. Это самая близкая вещь к понятиям, которые мы имеем для текущего языка.

Если вам не нужно использовать BCCL, лучше всего подойдет документация.

Answer 2

C ++ 11 добавил static_assert (который может быть эмулирован в C ++ 03 с помощью BOOST_STATIC_ASSERT).Теперь вы можете написать множество таких утверждений, которые сработают во время компиляции, и добавить в них удобочитаемую документацию о том, почему это утверждение сработало.В зависимости от того, какие средства вы должны протестировать (например, C ++ 11 type_traits или только boost.type_traits), вы можете делать с ним более или менее (также рассмотрите возможность использования decltype для проверки возможности выполнения определенных действий, возможно, в сочетании с трюком sizeofсложно сказать в общем)

Answer 3

Было предложение о концепциях в C ++ 11, которое решило бы эту проблему: концепция - это, по сути, описание интерфейса, которому должен соответствовать параметр шаблона.Вы можете получить аналогичные функциональные возможности из Boost Concept Check Library , если вам это нужно сейчас, но класс должен быть спроектирован так, чтобы с самого начала использовать концептуальные утверждения, поэтому вам не повезет, если у вас естьсуществующая библиотека.

Answer 4

Использование композиции и чисто виртуальных классов позволяет избежать этой проблемы.Использовать и понимать интерфейсы проще.Понять, как реализация реализует интерфейс, проще.Модульное тестирование проще.

struct B {
  virtual ~B() {}
  virtual void foo() const = 0;
  virtual void bar() const = 0;
};

struct D : public B {
  virtual ~D() {}
  virtual void foo() const {foo_thing.call();}
  virtual void bar() const {bar_thing.call();}
private:
  some_foo_like_thing foo_thing;
  some_bar_like_thing bar_thing;
};

Я надеюсь, что говорить о том, что должно и не должно быть в чисто виртуальном интерфейсе, будет проще, хотя пробег может варьироваться.;)

Чем больше информации требуется, чтобы оценить что-то, тем сложнее рассуждать об этом.Если ваш класс полагается на реализацию своего родителя, то вы, по сути, должны понимать его и каждого из его предшественников.Не только интерфейс, но и реализация.

Если бы я собирался разработать язык, наследование реализации даже не было бы вариантом.