Наследование и интерфейсы — бесплатный тест онлайн

Вопрос 1 из 20

Раздел «Наследование классов»: код использует MustInherit. Какой вывод останется верным при других допустимых входных данных?

MustInherit Class Document
    Public MustOverride Function Render() As String
End Class
Class PdfDocument
    Inherits Document
    Public Overrides Function Render() As String
        Return "pdf"
    End Function
End Class

Наблюдаемое поведение: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта не делает иерархию хрупкой. Наблюдаемое поведение: inherits не наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Наблюдаемое поведение: inherits наследует одну базовую реализацию и не выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Наблюдаемое поведение: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Наблюдаемое поведение: inherits наследует несколько базовых реализаций и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой.

Вопрос 2 из 20

Раздел «Наследование классов»: что должно остаться явным после переработки участка с MustInherit?

Option Strict On
Namespace ReviewCase7_1
    MustInherit Class Document
        Public MustOverride Function Render() As String
    End Class
    Class PdfDocument
        Inherits Document
        Public Overrides Function Render() As String
            Return "pdf"
        End Function
    End Class
End Namespace

Сохранить на ревью: inherits не наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Сохранить на ревью: inherits наследует несколько базовых реализаций и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Сохранить на ревью: inherits наследует одну базовую реализацию и не выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Сохранить на ревью: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Сохранить на ревью: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта не делает иерархию хрупкой.

Вопрос 3 из 20

Раздел «Наследование классов»: какой результат следует зафиксировать до запуска отрицательного сценария?

Option Explicit On
Option Infer On
Namespace BoundaryCase7_1
    MustInherit Class Document
        Public MustOverride Function Render() As String
    End Class
    Class PdfDocument
        Inherits Document
        Public Overrides Function Render() As String
            Return "pdf"
        End Function
    End Class
End Namespace

Проверить на границе: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Проверить на границе: inherits наследует одну базовую реализацию и не выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Проверить на границе: inherits не наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Проверить на границе: inherits наследует несколько базовых реализаций и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Проверить на границе: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта не делает иерархию хрупкой.

Вопрос 4 из 20

Раздел «Наследование классов»: как уменьшить риск дефекта, не подменяя причину запасным значением?

Не скрывать за запасным сценарием: inherits наследует несколько базовых реализаций и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Не скрывать за запасным сценарием: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Не скрывать за запасным сценарием: inherits наследует одну базовую реализацию и не выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Не скрывать за запасным сценарием: inherits не наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Не скрывать за запасным сценарием: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта не делает иерархию хрупкой.

Вопрос 5 из 20

Раздел «Наследование классов»: какой вывод описывает семантику, а не предпочтение в оформлении?

Технически точный принцип: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Технически точный принцип: inherits наследует одну базовую реализацию и не выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Технически точный принцип: inherits наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта не делает иерархию хрупкой. Технически точный принцип: inherits наследует несколько базовых реализаций и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой. Технически точный принцип: inherits не наследует одну базовую реализацию и выражает отношение подстановки; наследование ради повторного использования кода без общего контракта делает иерархию хрупкой.

Вопрос 6 из 20

Какой контракт действительно соблюдает показанный фрагмент из раздела «Реализация интерфейсов»?

Interface IClock
    Function UtcNow() As DateTimeOffset
End Interface
Class FixedClock
    Implements IClock
    Public Function UtcNow() As DateTimeOffset Implements IClock.UtcNow
        Return DateTimeOffset.UnixEpoch
    End Function
End Class

Наблюдаемое поведение: implements не требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Наблюдаемое поведение: implements требует явно связать члены класса с интерфейсом и не позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Наблюдаемое поведение: implements требует неявно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Наблюдаемое поведение: implements требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Наблюдаемое поведение: implements требует автоматически связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены.

Вопрос 7 из 20

Раздел «Реализация интерфейсов»: что должно остаться явным после переработки участка с IClock?

Option Strict On
Namespace ReviewCase7_2
    Interface IClock
        Function UtcNow() As DateTimeOffset
    End Interface
    Class FixedClock
        Implements IClock
        Public Function UtcNow() As DateTimeOffset Implements IClock.UtcNow
            Return DateTimeOffset.UnixEpoch
        End Function
    End Class
End Namespace

Проверить перед объединением: implements требует неявно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Проверить перед объединением: implements не требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Проверить перед объединением: implements требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Проверить перед объединением: implements требует явно связать члены класса с интерфейсом и не позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Проверить перед объединением: implements требует автоматически связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены.

Вопрос 8 из 20

Раздел «Реализация интерфейсов»: какое правило нельзя считать проверенным одним обычным примером?

Option Explicit On
Option Infer On
Namespace BoundaryCase7_2
    Interface IClock
        Function UtcNow() As DateTimeOffset
    End Interface
    Class FixedClock
        Implements IClock
        Public Function UtcNow() As DateTimeOffset Implements IClock.UtcNow
            Return DateTimeOffset.UnixEpoch
        End Function
    End Class
End Namespace

Добавить регрессионную проверку: implements требует автоматически связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Добавить регрессионную проверку: implements требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Добавить регрессионную проверку: implements не требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Добавить регрессионную проверку: implements требует явно связать члены класса с интерфейсом и не позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Добавить регрессионную проверку: implements требует неявно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены.

Вопрос 9 из 20

Раздел «Реализация интерфейсов»: что нужно сделать частью контракта рабочего модуля?

Закрепить рабочее решение: implements требует автоматически связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Закрепить рабочее решение: implements требует явно связать члены класса с интерфейсом и не позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Закрепить рабочее решение: implements требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Закрепить рабочее решение: implements не требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Закрепить рабочее решение: implements требует неявно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены.

Вопрос 10 из 20

Раздел «Реализация интерфейсов»: какой вывод описывает семантику, а не предпочтение в оформлении?

Надёжное обобщение: implements не требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Надёжное обобщение: implements требует явно связать члены класса с интерфейсом и не позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Надёжное обобщение: implements требует явно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Надёжное обобщение: implements требует неявно связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены. Надёжное обобщение: implements требует автоматически связать члены класса с интерфейсом и позволяет скрыть реализацию за небольшим контрактом, удобным для тестирования и замены.

Вопрос 11 из 20

Раздел «Полиморфное переопределение»: какое утверждение позволяет предсказать поведение фрагмента по правилам Visual Basic и .NET?

Class BaseParser
    Public Overridable Function Parse(text As String) As Integer
        Return Integer.Parse(text)
    End Function
End Class
Class SafeParser
    Inherits BaseParser
    Public Overrides Function Parse(text As String) As Integer
        Dim value As Integer
        If Not Integer.TryParse(text, value) Then Return 0
        Return value
    End Function
End Class

Overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и является полиморфным переопределением. Overrides не участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Overrides участвует в виртуальном вызове и не должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь не скрывает имя при статическом типе и не является полиморфным переопределением.

Вопрос 12 из 20

Раздел «Полиморфное переопределение»: какой комментарий к изменению будет технически обоснован?

Option Strict On
Namespace ReviewCase7_3
    Class BaseParser
        Public Overridable Function Parse(reviewText As String) As Integer
            Return Integer.Parse(reviewText)
        End Function
    End Class
    Class SafeParser
        Inherits BaseParser
        Public Overrides Function Parse(reviewText As String) As Integer
            Dim value As Integer
            If Not Integer.TryParse(reviewText, value) Then Return 0
            Return value
        End Function
    End Class
End Namespace

Зафиксировать в ревью: overrides участвует в виртуальном вызове и не должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Зафиксировать в ревью: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Зафиксировать в ревью: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и является полиморфным переопределением. Зафиксировать в ревью: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь не скрывает имя при статическом типе и не является полиморфным переопределением. Зафиксировать в ревью: overrides не участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением.

Вопрос 13 из 20

Раздел «Полиморфное переопределение»: для фрагмента с BaseParser добавляют регрессионный тест. Какой контракт он должен защищать?

Option Explicit On
Option Infer On
Namespace BoundaryCase7_3
    Class BaseParser
        Public Overridable Function Parse(edgeText As String) As Integer
            Return Integer.Parse(edgeText)
        End Function
    End Class
    Class SafeParser
        Inherits BaseParser
        Public Overrides Function Parse(edgeText As String) As Integer
            Dim value As Integer
            If Not Integer.TryParse(edgeText, value) Then Return 0
            Return value
        End Function
    End Class
End Namespace

Зафиксировать ожидаемое поведение: overrides не участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Зафиксировать ожидаемое поведение: overrides участвует в виртуальном вызове и не должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Зафиксировать ожидаемое поведение: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь не скрывает имя при статическом типе и не является полиморфным переопределением. Зафиксировать ожидаемое поведение: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и является полиморфным переопределением. Зафиксировать ожидаемое поведение: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением.

Вопрос 14 из 20

Раздел «Полиморфное переопределение»: какой выбор не превращает скрытую ошибку в тихое продолжение работы?

Сделать явным правилом модуля: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Сделать явным правилом модуля: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и является полиморфным переопределением. Сделать явным правилом модуля: overrides не участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Сделать явным правилом модуля: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь не скрывает имя при статическом типе и не является полиморфным переопределением. Сделать явным правилом модуля: overrides участвует в виртуальном вызове и не должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением.

Вопрос 15 из 20

Раздел «Полиморфное переопределение»: какое правило остаётся верным для современного Visual Basic?

Рабочее правило: overrides участвует в виртуальном вызове и не должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Рабочее правило: overrides не участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Рабочее правило: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь не скрывает имя при статическом типе и не является полиморфным переопределением. Рабочее правило: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и не является полиморфным переопределением. Рабочее правило: overrides участвует в виртуальном вызове и должен сохранять смысл базового контракта; Shadows лишь скрывает имя при статическом типе и является полиморфным переопределением.

Вопрос 16 из 20

Раздел «Обращение к базовому классу»: что здесь является частью контракта, а не особенностью одного удачного запуска?

Class BaseJob
    Public Sub New(name As String)
        If String.IsNullOrWhiteSpace(name) Then Throw New ArgumentException(NameOf(name))
    End Sub
End Class
Class ExportJob
    Inherits BaseJob
    Public Sub New(name As String)
        MyBase.New(name)
    End Sub
End Class

Наблюдаемое поведение: myBase не вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Наблюдаемое поведение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Наблюдаемое поведение: нарушение условия «MyBase вызывает реализацию или конструктор базового класса» допустимо, если тест подтверждает «это полезно для расширения поведения». Наблюдаемое поведение: достаточно выполнить одно из двух условий: «MyBase вызывает реализацию или конструктор базового класса» или «это полезно для расширения поведения». Наблюдаемое поведение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но должно обходить важные инварианты производного типа.

Вопрос 17 из 20

Раздел «Обращение к базовому классу»: перед объединением правки нужно проверить один принцип. Какой именно?

Option Strict On
Namespace ReviewCase7_4
    Class BaseJob
        Public Sub New(reviewName As String)
            If String.IsNullOrWhiteSpace(reviewName) Then Throw New ArgumentException(NameOf(reviewName))
        End Sub
    End Class
    Class ExportJob
        Inherits BaseJob
        Public Sub New(reviewName As String)
            MyBase.New(reviewName)
        End Sub
    End Class
End Namespace

Проверить перед объединением: нарушение условия «MyBase вызывает реализацию или конструктор базового класса» допустимо, если тест подтверждает «это полезно для расширения поведения». Проверить перед объединением: достаточно выполнить одно из двух условий: «MyBase вызывает реализацию или конструктор базового класса» или «это полезно для расширения поведения». Проверить перед объединением: myBase не вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Проверить перед объединением: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но должно обходить важные инварианты производного типа. Проверить перед объединением: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа.

Вопрос 18 из 20

Раздел «Обращение к базовому классу»: какое правило нельзя считать проверенным одним обычным примером?

Option Explicit On
Option Infer On
Namespace BoundaryCase7_4
    Class BaseJob
        Public Sub New(edgeName As String)
            If String.IsNullOrWhiteSpace(edgeName) Then Throw New ArgumentException(NameOf(edgeName))
        End Sub
    End Class
    Class ExportJob
        Inherits BaseJob
        Public Sub New(edgeName As String)
            MyBase.New(edgeName)
        End Sub
    End Class
End Namespace

Зафиксировать ожидаемое поведение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но должно обходить важные инварианты производного типа. Зафиксировать ожидаемое поведение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Зафиксировать ожидаемое поведение: нарушение условия «MyBase вызывает реализацию или конструктор базового класса» допустимо, если тест подтверждает «это полезно для расширения поведения». Зафиксировать ожидаемое поведение: достаточно выполнить одно из двух условий: «MyBase вызывает реализацию или конструктор базового класса» или «это полезно для расширения поведения». Зафиксировать ожидаемое поведение: myBase не вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа.

Вопрос 19 из 20

Раздел «Обращение к базовому классу»: что здесь важнее локального удобства: какой контракт должен быть виден в коде?

Закрепить рабочее решение: достаточно выполнить одно из двух условий: «MyBase вызывает реализацию или конструктор базового класса» или «это полезно для расширения поведения». Закрепить рабочее решение: myBase не вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Закрепить рабочее решение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Закрепить рабочее решение: нарушение условия «MyBase вызывает реализацию или конструктор базового класса» допустимо, если тест подтверждает «это полезно для расширения поведения». Закрепить рабочее решение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но должно обходить важные инварианты производного типа.

Вопрос 20 из 20

Раздел «Обращение к базовому классу»: какое обобщение не зависит от случайных деталей показанного примера?

Надёжное обобщение: нарушение условия «MyBase вызывает реализацию или конструктор базового класса» допустимо, если тест подтверждает «это полезно для расширения поведения». Надёжное обобщение: достаточно выполнить одно из двух условий: «MyBase вызывает реализацию или конструктор базового класса» или «это полезно для расширения поведения». Надёжное обобщение: myBase не вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Надёжное обобщение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но не должно обходить важные инварианты производного типа. Надёжное обобщение: myBase вызывает реализацию или конструктор базового класса; это полезно для расширения поведения, но должно обходить важные инварианты производного типа.