Каков наиболее широко используемый проект с открытым исходным кодом, который использует дизайн контракта?
Большую часть времени опасно использовать защищенный, потому что Вы повреждаете несколько инкапсуляцию своего класса, который мог быть сломан плохо разработанным производным классом.
, Но у меня есть один хороший пример: Скажем, Вы можете некоторый универсальный контейнер. Это имеет внутреннюю реализацию и внутренние средства доступа. Но необходимо предложить по крайней мере 3 открытого доступа его данным: карта, hash_map, подобный вектору. Тогда у Вас есть что-то как:
template <typename T, typename TContainer>
class Base
{
// etc.
protected
TContainer container ;
}
template <typename Key, typename T>
class DerivedMap : public Base<T, std::map<Key, T> > { /* etc. */ }
template <typename Key, typename T>
class DerivedHashMap : public Base<T, std::hash_map<Key, T> > { /* etc. */ }
template <typename T>
class DerivedVector : public Base<T, std::vector<T> > { /* etc. */ }
я использовал этот вид кода меньше чем месяц назад (таким образом, код из памяти). После некоторых взглядов я полагаю что, в то время как универсальный Основной контейнер должен быть абстрактным классом, даже если бы это может жить вполне хорошо, потому что использование, непосредственно Основное, было бы такой болью, которую это должно быть запрещено.
Сводка Таким образом, Вы защитили данные, используемые производным классом. Однако, мы должны взять интервал o, считают факт, Базовый класс должен быть абстрактным.
1 ответ
"Не-Эйфелева" часть вашего вопроса интересна. Контракты приобретают весь смысл, когда они поддерживаются языком программирования, иначе это просто хороший синтаксис для комментариев.
Это подводит нас к языкам, поддерживающим контракты. Я знаю трех, кроме Эйфеля:
- ESC / Java добавляет контракты в Java, используя язык с именем JML .
- Контракты .NET для всех языков .NET (работает на уровень байт-кода)
- Frama-C добавляет контракты в C, используя язык ACSL
Первые два имеют исполняемые контракты. Преимущества: можно использовать как утверждения во время выполнения. Недостатки: не хватает выразительной силы, чтобы полностью указать, что функция делает в контракте. Вы можете в основном писать только проверки на вменяемость.
С другой стороны, контракты ACSL более выразительны и невыполнимы. Они позволяют полностью указать, что функция сортировки всегда должна завершаться и оставлять те же элементы, что и в исходном массиве, по порядку. Контракты ACSL можно использовать для статического анализа, особенно для вычисления самых слабых предварительных условий в стиле Хоара.
И только будучи действительно знакомым с последним (отказ от ответственности: я работаю над Frama-C, но часть ACSL - это работа многих людей, некоторые из которых внесли гораздо больше, чем я), я могу только упомянуть «ACSL на примере», библиотеку C с открытым исходным кодом с контрактами ACSL, которая в настоящее время разрабатывается Fraunhofer FIRST. Он еще не выпущен, но будет частью проекта Device-soft . Я уверен, что вы могли бы получить предварительную версию, если бы вам было интересно.