Структуры и неизменяемые типы — бесплатный тест онлайн

Вопрос 1 из 20

Что именно следует из фрагмента с `struct Report`?

s=(x_1:T_1,\ldots,x_n:T_n)

struct Report
    values::Vector{Float64}
    name::String
end
r = Report([1.0, 2.0], "day")
push!(r.values, 3.0)
@show r

Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. После объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния.

Вопрос 2 из 20

Какой контрольный тест лучше всего проверит правило, связанное с `struct Report`?

struct Report
    values::Vector{Float64}
    name::String
end
r = Report([1.0, 2.0], "day")
push!(r.values, 3.0)
@show r

Проверить на отдельном примере, что неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Проверить на отдельном примере, что `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния. Проверить на отдельном примере, что поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Проверить на отдельном примере, что проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Проверить на отдельном примере, что после объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён.

Вопрос 3 из 20

Какой контракт следует закрепить при переработке строки `struct Report`?

struct Report
    values::Vector{Float64}
    name::String
end
r = Report([1.0, 2.0], "day")
push!(r.values, 3.0)
@show r

Сохранить в реализации правило: После объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Сохранить в реализации правило: Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Сохранить в реализации правило: Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Сохранить в реализации правило: Неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Сохранить в реализации правило: `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния.

Вопрос 4 из 20

Какой результат приёмочного теста подтвердит корректность участка с `struct Report`?

s=(x_1:T_1,\ldots,x_n:T_n)

Приёмка должна подтвердить, что проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Приёмка должна подтвердить, что после объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Приёмка должна подтвердить, что поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Приёмка должна подтвердить, что `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния. Приёмка должна подтвердить, что неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку.

Вопрос 5 из 20

Что следует сообщить пользователю библиотеки о поведении `struct Report`?

Указать в документации: Неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Указать в документации: Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Указать в документации: После объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Указать в документации: `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния. Указать в документации: Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое.

Вопрос 6 из 20

Что именно следует из фрагмента с `mutable struct Counter`?

s_t\to s_{t+1}

mutable struct Counter
    value::Int
    limit::Int
end
function bump!(c::Counter)
    c.value < c.limit || return false
    c.value += 1
    return true
end
@show bump!(Counter(0, 1))

Неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния. Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. `mutable struct` разрешает записать значение почти каждого типа в поле независимо от объявления поля.

Вопрос 7 из 20

Какой тест точнее всего зафиксирует границу поведения `mutable struct Counter`?

mutable struct Counter
    value::Int
    limit::Int
end
function bump!(c::Counter)
    c.value < c.limit || return false
    c.value += 1
    return true
end
@show bump!(Counter(0, 1))

Проверить на отдельном примере, что проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Проверить на отдельном примере, что поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Проверить на отдельном примере, что `mutable struct` разрешает записать значение почти каждого типа в поле независимо от объявления поля. Проверить на отдельном примере, что неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Проверить на отдельном примере, что `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния.

Вопрос 8 из 20

Какую гарантию должна сохранить правка участка с `mutable struct Counter`?

mutable struct Counter
    value::Int
    limit::Int
end
function bump!(c::Counter)
    c.value < c.limit || return false
    c.value += 1
    return true
end
@show bump!(Counter(0, 1))

Сохранить в реализации правило: Неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Сохранить в реализации правило: Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Сохранить в реализации правило: `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния. Сохранить в реализации правило: Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Сохранить в реализации правило: `mutable struct` разрешает записать значение почти каждого типа в поле независимо от объявления поля.

Вопрос 9 из 20

Какой результат приёмочного теста подтвердит корректность участка с `mutable struct Counter`?

s_t\to s_{t+1}

Приёмка должна подтвердить, что `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния. Приёмка должна подтвердить, что поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Приёмка должна подтвердить, что неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Приёмка должна подтвердить, что проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Приёмка должна подтвердить, что `mutable struct` разрешает записать значение почти каждого типа в поле независимо от объявления поля.

Вопрос 10 из 20

Что следует сообщить пользователю библиотеки о поведении `mutable struct Counter`?

Указать в документации: Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Указать в документации: Неизменяемый `struct` делает глубоко неизменяемыми все поля, поэтому массив внутри него нельзя менять через ссылку. Указать в документации: `mutable struct` допускает изменение полей, но это не отменяет требований к типам полей и согласованности состояния. Указать в документации: `mutable struct` разрешает записать значение почти каждого типа в поле независимо от объявления поля. Указать в документации: Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние.

Вопрос 11 из 20

Что именно следует из фрагмента с `new(float(lo), float(hi))`?

x\in\mathcal{D}\Rightarrow\operatorname{new}(x)\in\mathcal{I}

struct Interval
    lo::Float64
    hi::Float64
    function Interval(lo, hi)
        lo <= hi || throw(ArgumentError("lo > hi"))
        new(float(lo), float(hi))
    end
end
@show Interval(1, 3)

Внутренний конструктор контролирует все пути создания экземпляра и может проверять аргументы до вызова `new`; внешние конструкторы удобны для преобразования входов. После объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Инвариант типа должен сохраняться после любого публичного действия; открытая мутация связанных полей легко создаёт состояние, которое конструктор изначально запрещал. Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние.

Вопрос 12 из 20

Что нужно подтвердить отдельным примером для `new(float(lo), float(hi))`?

struct Interval
    lo::Float64
    hi::Float64
    function Interval(lo, hi)
        lo <= hi || throw(ArgumentError("lo > hi"))
        new(float(lo), float(hi))
    end
end
@show Interval(1, 3)

Проверить на отдельном примере, что инвариант типа должен сохраняться после любого публичного действия; открытая мутация связанных полей легко создаёт состояние, которое конструктор изначально запрещал. Проверить на отдельном примере, что поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Проверить на отдельном примере, что после объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Проверить на отдельном примере, что внутренний конструктор контролирует все пути создания экземпляра и может проверять аргументы до вызова `new`; внешние конструкторы удобны для преобразования входов. Проверить на отдельном примере, что проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние.

Вопрос 13 из 20

Какой контракт следует закрепить при переработке строки `new(float(lo), float(hi))`?

struct Interval
    lo::Float64
    hi::Float64
    function Interval(lo, hi)
        lo <= hi || throw(ArgumentError("lo > hi"))
        new(float(lo), float(hi))
    end
end
@show Interval(1, 3)

Сохранить в реализации правило: Внутренний конструктор контролирует все пути создания экземпляра и может проверять аргументы до вызова `new`; внешние конструкторы удобны для преобразования входов. Сохранить в реализации правило: После объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Сохранить в реализации правило: Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Сохранить в реализации правило: Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Сохранить в реализации правило: Инвариант типа должен сохраняться после любого публичного действия; открытая мутация связанных полей легко создаёт состояние, которое конструктор изначально запрещал.

Вопрос 14 из 20

Как проверить, что новая реализация `new(float(lo), float(hi))` не изменила обещанное пользователю поведение?

x\in\mathcal{D}\Rightarrow\operatorname{new}(x)\in\mathcal{I}

Приёмка должна подтвердить, что внутренний конструктор контролирует все пути создания экземпляра и может проверять аргументы до вызова `new`; внешние конструкторы удобны для преобразования входов. Приёмка должна подтвердить, что инвариант типа должен сохраняться после любого публичного действия; открытая мутация связанных полей легко создаёт состояние, которое конструктор изначально запрещал. Приёмка должна подтвердить, что поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое. Приёмка должна подтвердить, что после объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Приёмка должна подтвердить, что проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние.

Вопрос 15 из 20

Какое утверждение о `new(float(lo), float(hi))` является переносимым правилом, а не особенностью одного запуска?

Указать в документации: Внутренний конструктор контролирует все пути создания экземпляра и может проверять аргументы до вызова `new`; внешние конструкторы удобны для преобразования входов. Указать в документации: Проверка инварианта нужна только в конструкторе: публичные изменяющие методы не способны нарушить уже созданное состояние. Указать в документации: Инвариант типа должен сохраняться после любого публичного действия; открытая мутация связанных полей легко создаёт состояние, которое конструктор изначально запрещал. Указать в документации: После объявления внешнего конструктора он становится единственной точкой создания экземпляра, даже если внутренний конструктор явно не переопределён. Указать в документации: Поля обычного `struct` нельзя переназначать после создания, хотя изменяемые объекты внутри полей могут менять своё содержимое.

Вопрос 16 из 20

Какое утверждение точнее всего объясняет участок с `0 <= n <= available(a) || throw(ArgumentError("reserve"))`?

\forall t:\;I(s_t)=\mathrm{true}

mutable struct Account
    balance::Int
    reserved::Int
end
available(a) = a.balance - a.reserved
function reserve!(a, n)
    0 <= n <= available(a) || throw(ArgumentError("reserve"))
    a.reserved += n
end

Для `mutable struct` присваивание полю автоматически повторяет проверки внутреннего конструктора и потому не может нарушить инвариант. Аннотации типов полей сами проверяют отношения между значениями, например что счётчик не превышает размер связанного буфера. Инвариант должен сохраняться после каждого публичного действия: даже корректно созданный объект можно испортить методом, который несогласованно меняет связанные данные. Если внутренний конструктор проверил объект один раз, любые последующие публичные методы уже не способны создать запрещённое состояние. Неизменяемость внешнего `struct` гарантирует сохранность инварианта, даже если наружу возвращается ссылка на изменяемый массив из его поля.

Вопрос 17 из 20

Что нужно подтвердить отдельным примером для `0 <= n <= available(a) || throw(ArgumentError("reserve"))`?

mutable struct Account
    balance::Int
    reserved::Int
end
available(a) = a.balance - a.reserved
function reserve!(a, n)
    0 <= n <= available(a) || throw(ArgumentError("reserve"))
    a.reserved += n
end

Проверить на отдельном примере, что неизменяемость внешнего `struct` гарантирует сохранность инварианта, даже если наружу возвращается ссылка на изменяемый массив из его поля. Проверить на отдельном примере, что если внутренний конструктор проверил объект один раз, любые последующие публичные методы уже не способны создать запрещённое состояние. Проверить на отдельном примере, что аннотации типов полей сами проверяют отношения между значениями, например что счётчик не превышает размер связанного буфера. Проверить на отдельном примере, что инвариант должен сохраняться после каждого публичного действия: даже корректно созданный объект можно испортить методом, который несогласованно меняет связанные данные. Проверить на отдельном примере, что для `mutable struct` присваивание полю автоматически повторяет проверки внутреннего конструктора и потому не может нарушить инвариант.

Вопрос 18 из 20

Какое решение устраняет риск вокруг `0 <= n <= available(a) || throw(ArgumentError("reserve"))`, не меняя поведение на допустимых данных?

mutable struct Account
    balance::Int
    reserved::Int
end
available(a) = a.balance - a.reserved
function reserve!(a, n)
    0 <= n <= available(a) || throw(ArgumentError("reserve"))
    a.reserved += n
end

Сохранить в реализации правило: Аннотации типов полей сами проверяют отношения между значениями, например что счётчик не превышает размер связанного буфера. Сохранить в реализации правило: Для `mutable struct` присваивание полю автоматически повторяет проверки внутреннего конструктора и потому не может нарушить инвариант. Сохранить в реализации правило: Неизменяемость внешнего `struct` гарантирует сохранность инварианта, даже если наружу возвращается ссылка на изменяемый массив из его поля. Сохранить в реализации правило: Инвариант должен сохраняться после каждого публичного действия: даже корректно созданный объект можно испортить методом, который несогласованно меняет связанные данные. Сохранить в реализации правило: Если внутренний конструктор проверил объект один раз, любые последующие публичные методы уже не способны создать запрещённое состояние.

Вопрос 19 из 20

Какой результат приёмочного теста подтвердит корректность участка с `0 <= n <= available(a) || throw(ArgumentError("reserve"))`?

\forall t:\;I(s_t)=\mathrm{true}

Приёмка должна подтвердить, что инвариант должен сохраняться после каждого публичного действия: даже корректно созданный объект можно испортить методом, который несогласованно меняет связанные данные. Приёмка должна подтвердить, что если внутренний конструктор проверил объект один раз, любые последующие публичные методы уже не способны создать запрещённое состояние. Приёмка должна подтвердить, что аннотации типов полей сами проверяют отношения между значениями, например что счётчик не превышает размер связанного буфера. Приёмка должна подтвердить, что неизменяемость внешнего `struct` гарантирует сохранность инварианта, даже если наружу возвращается ссылка на изменяемый массив из его поля. Приёмка должна подтвердить, что для `mutable struct` присваивание полю автоматически повторяет проверки внутреннего конструктора и потому не может нарушить инвариант.

Вопрос 20 из 20

Как сформулировать границу механизма `0 <= n <= available(a) || throw(ArgumentError("reserve"))` без чрезмерного обещания?

Указать в документации: Если внутренний конструктор проверил объект один раз, любые последующие публичные методы уже не способны создать запрещённое состояние. Указать в документации: Для `mutable struct` присваивание полю автоматически повторяет проверки внутреннего конструктора и потому не может нарушить инвариант. Указать в документации: Инвариант должен сохраняться после каждого публичного действия: даже корректно созданный объект можно испортить методом, который несогласованно меняет связанные данные. Указать в документации: Неизменяемость внешнего `struct` гарантирует сохранность инварианта, даже если наружу возвращается ссылка на изменяемый массив из его поля. Указать в документации: Аннотации типов полей сами проверяют отношения между значениями, например что счётчик не превышает размер связанного буфера.