WPF и привязка данных — бесплатный тест онлайн

Вопрос 1 из 25

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

<Window x:Class="MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid>
        <TextBox Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
    </Grid>
</Window>

Разбор фрагмента: xAML не описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Разбор фрагмента: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются при компиляции. Разбор фрагмента: xAML описывает дерево, ресурсы и привязки, а code-behind должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Разбор фрагмента: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext не проявляются во время выполнения. Разбор фрагмента: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения.

Вопрос 2 из 25

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

<Window x:Class="MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Window.Resources>
        <Style x:Key="EditorText" TargetType="TextBox">
            <Setter Property="MinWidth" Value="180" />
        </Style>
    </Window.Resources>
    <Grid>
        <TextBox Style="{StaticResource EditorText}"
                 Text="{Binding Name, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
    </Grid>
</Window>

Сохранить на ревью: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются при компиляции. Сохранить на ревью: xAML не описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Сохранить на ревью: xAML описывает дерево, ресурсы и привязки, а code-behind должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Сохранить на ревью: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext не проявляются во время выполнения. Сохранить на ревью: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения.

Вопрос 3 из 25

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

<Window x:Class="MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <StackPanel DataContext="{Binding Editor}">
        <TextBlock Text="{Binding Name}" />
        <TextBox Text="{Binding Name, UpdateSourceTrigger=LostFocus}" />
    </StackPanel>
</Window>

Добавить регрессионную проверку: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются при компиляции. Добавить регрессионную проверку: xAML не описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Добавить регрессионную проверку: xAML описывает дерево, ресурсы и привязки, а code-behind должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Добавить регрессионную проверку: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext не проявляются во время выполнения. Добавить регрессионную проверку: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения.

Вопрос 4 из 25

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

Закрепить рабочее решение: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются при компиляции. Закрепить рабочее решение: xAML не описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Закрепить рабочее решение: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Закрепить рабочее решение: xAML описывает дерево, ресурсы и привязки, а code-behind должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext проявляются во время выполнения. Закрепить рабочее решение: xAML описывает дерево, ресурсы и привязки, а code-behind не должен становиться хранилищем всей предметной логики; ошибки ресурсов и DataContext не проявляются во время выполнения.

Вопрос 5 из 25

Какое утверждение точнее отделяет «Разметка XAML» от соседних механизмов?

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

Вопрос 6 из 25

Раздел «Привязка Binding»: в примере с EditorViewModel важна не форма записи, а поведение. Какое утверждение его описывает?

Class EditorViewModel
    Public Property Name As String
End Class
Public Class MainWindow
    Public Sub New(vm As EditorViewModel)
        InitializeComponent()
        DataContext = vm
    End Sub
End Class

Наблюдаемое поведение: условие «Binding читает Source или DataContext и путь свойства» влияет только на диагностику; поведение определяет «Mode и UpdateSourceTrigger задают направление и момент обновления». Наблюдаемое поведение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Наблюдаемое поведение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger не задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Наблюдаемое поведение: binding не читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Наблюдаемое поведение: достаточно подтвердить «Binding читает Source или DataContext и путь свойства»; условие «Mode и UpdateSourceTrigger задают направление и момент обновления» можно не проверять отдельно.

Вопрос 7 из 25

Раздел «Привязка Binding»: на ревью предлагают упростить участок с EditorViewModel. Какое замечание защищает поведение программы, а не стиль записи?

Option Strict On
Namespace ReviewCase18_2
    Class EditorViewModel
        Public Property Name As String
    End Class
    Public Class MainWindow
        Public Sub New(reviewVm As EditorViewModel)
            InitializeComponent()
            DataContext = reviewVm
        End Sub
    End Class
End Namespace

Зафиксировать в ревью: условие «Binding читает Source или DataContext и путь свойства» влияет только на диагностику; поведение определяет «Mode и UpdateSourceTrigger задают направление и момент обновления». Зафиксировать в ревью: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger не задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Зафиксировать в ревью: достаточно подтвердить «Binding читает Source или DataContext и путь свойства»; условие «Mode и UpdateSourceTrigger задают направление и момент обновления» можно не проверять отдельно. Зафиксировать в ревью: binding не читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Зафиксировать в ревью: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию.

Вопрос 8 из 25

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

Option Explicit On
Option Infer On
Namespace BoundaryCase18_2
    Class EditorViewModel
        Public Property Name As String
    End Class
    Public Class MainWindow
        Public Sub New(edgeVm As EditorViewModel)
            InitializeComponent()
            DataContext = edgeVm
        End Sub
    End Class
End Namespace

Зафиксировать ожидаемое поведение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Зафиксировать ожидаемое поведение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger не задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Зафиксировать ожидаемое поведение: binding не читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Зафиксировать ожидаемое поведение: условие «Binding читает Source или DataContext и путь свойства» влияет только на диагностику; поведение определяет «Mode и UpdateSourceTrigger задают направление и момент обновления». Зафиксировать ожидаемое поведение: достаточно подтвердить «Binding читает Source или DataContext и путь свойства»; условие «Mode и UpdateSourceTrigger задают направление и момент обновления» можно не проверять отдельно.

Вопрос 9 из 25

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

Закрепить рабочее решение: опечатка в Binding.Path ломает компиляцию, а UpdateSourceTrigger меняет только момент обновления интерфейса из модели. Закрепить рабочее решение: binding не читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Закрепить рабочее решение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger не задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Закрепить рабочее решение: достаточно подтвердить «Binding читает Source или DataContext и путь свойства»; условие «Mode и UpdateSourceTrigger задают направление и момент обновления» можно не проверять отдельно. Закрепить рабочее решение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию.

Вопрос 10 из 25

Что можно считать надёжным рабочим правилом для раздела «Привязка Binding»?

Надёжное обобщение: достаточно подтвердить «Binding читает Source или DataContext и путь свойства»; условие «Mode и UpdateSourceTrigger задают направление и момент обновления» можно не проверять отдельно. Надёжное обобщение: binding не читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Надёжное обобщение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger задают направление и момент обновления, а неверный путь обычно не ломает компиляцию. Надёжное обобщение: условие «Binding читает Source или DataContext и путь свойства» влияет только на диагностику; поведение определяет «Mode и UpdateSourceTrigger задают направление и момент обновления». Надёжное обобщение: binding читает Source или DataContext и путь свойства; Mode и UpdateSourceTrigger не задают направление и момент обновления, а неверный путь обычно не ломает компиляцию.

Вопрос 11 из 25

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

Imports System.ComponentModel
Imports System.Runtime.CompilerServices
Class EditorViewModel
    Implements INotifyPropertyChanged
    Private _name As String
    Public Property Name As String
        Get : Return _name : End Get
        Set(value As String)
            If _name = value Then Return
            _name = value
            RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(NameOf(Name)))
        End Set
    End Property
    Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged
End Class

Наблюдаемое поведение: wPF периодически перечитывает обычные CLR-свойства из DataContext, поэтому INotifyPropertyChanged нужен лишь для коллекций. Наблюдаемое поведение: iNotifyPropertyChanged не сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Наблюдаемое поведение: свойства»; условие «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте» можно не учитывать на обычном входе. Наблюдаемое поведение: iNotifyPropertyChanged сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Наблюдаемое поведение: достаточно обеспечить «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте»; условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» можно отдельно не проверять.

Вопрос 12 из 25

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

Option Strict On
Imports System.ComponentModel
Imports System.Runtime.CompilerServices
Namespace ReviewCase18_3
    Class EditorViewModel
        Implements INotifyPropertyChanged
        Private _name As String
        Public Property Name As String
            Get : Return _name : End Get
            Set(value As String)
                If _name = value Then Return
                _name = value
                RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(NameOf(Name)))
            End Set
        End Property
        Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged
    End Class
End Namespace

Не менять условие: iNotifyPropertyChanged сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Не менять условие: iNotifyPropertyChanged не сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Не менять условие: условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» влияет только на диагностику; поведение определяет «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте». Не менять условие: достаточно обеспечить «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте»; условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» можно отдельно не проверять. Не менять условие: wPF периодически перечитывает обычные CLR-свойства из DataContext, поэтому INotifyPropertyChanged нужен лишь для коллекций.

Вопрос 13 из 25

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

Option Explicit On
Option Infer On
Imports System.ComponentModel
Imports System.Runtime.CompilerServices
Namespace BoundaryCase18_3
    Class EditorViewModel
        Implements INotifyPropertyChanged
        Private _name As String
        Public Property Name As String
            Get : Return _name : End Get
            Set(value As String)
                If _name = value Then Return
                _name = value
                RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(NameOf(Name)))
            End Set
        End Property
        Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged
    End Class
End Namespace

Закрепить тестом: условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» влияет только на диагностику; поведение определяет «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте». Закрепить тестом: iNotifyPropertyChanged не сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Закрепить тестом: достаточно обеспечить «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте»; условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» можно отдельно не проверять. Закрепить тестом: wPF периодически перечитывает обычные CLR-свойства из DataContext, поэтому INotifyPropertyChanged нужен лишь для коллекций. Закрепить тестом: iNotifyPropertyChanged сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте.

Вопрос 14 из 25

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

Закрепить рабочее решение: iNotifyPropertyChanged сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Закрепить рабочее решение: достаточно обеспечить «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте»; условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» можно отдельно не проверять. Закрепить рабочее решение: iNotifyPropertyChanged не сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Закрепить рабочее решение: условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» влияет только на диагностику; поведение определяет «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте». Закрепить рабочее решение: wPF периодически перечитывает обычные CLR-свойства из DataContext, поэтому INotifyPropertyChanged нужен лишь для коллекций.

Вопрос 15 из 25

Что точнее всего описывает механизм «Уведомления об изменении свойств»?

Технически точный принцип: свойства»; условие «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте» можно не учитывать на обычном входе. Технически точный принцип: iNotifyPropertyChanged сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте. Технически точный принцип: wPF периодически перечитывает обычные CLR-свойства из DataContext, поэтому INotifyPropertyChanged нужен лишь для коллекций. Технически точный принцип: достаточно обеспечить «без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте»; условие «INotifyPropertyChanged сообщает имя уже изменённого свойства» можно отдельно не проверять. Технически точный принцип: iNotifyPropertyChanged не сообщает имя уже изменённого свойства; без события интерфейс не узнает об изменении обычного CLR-свойства в существующем объекте.

Вопрос 16 из 25

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

Class SaveCommand
    Implements ICommand
    Private ReadOnly canSave As Func(Of Boolean)
    Private ReadOnly save As Action
    Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
        Return canSave()
    End Function
    Public Sub Execute(parameter As Object) Implements ICommand.Execute
        save()
    End Sub
    Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged
End Class

Наблюдаемое поведение: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged не должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Наблюдаемое поведение: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Наблюдаемое поведение: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс не показывает устаревшую доступность. Наблюдаемое поведение: wPF постоянно вызывает CanExecute сам, поэтому CanExecuteChanged не нужен даже при изменении условий доступности команды. Наблюдаемое поведение: iCommand не отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность.

Вопрос 17 из 25

Раздел «Команды интерфейса»: какой вывод должен пережить рефакторинг этого фрагмента?

Option Strict On
Namespace ReviewCase18_4
    Class SaveCommand
        Implements ICommand
        Private ReadOnly canSave As Func(Of Boolean)
        Private ReadOnly save As Action
        Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
            Return canSave()
        End Function
        Public Sub Execute(parameter As Object) Implements ICommand.Execute
            save()
        End Sub
        Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged
    End Class
End Namespace

Сохранить на ревью: wPF постоянно вызывает CanExecute сам, поэтому CanExecuteChanged не нужен даже при изменении условий доступности команды. Сохранить на ревью: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged не должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Сохранить на ревью: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Сохранить на ревью: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс не показывает устаревшую доступность. Сохранить на ревью: iCommand не отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность.

Вопрос 18 из 25

Раздел «Команды интерфейса»: обычный сценарий проходит. Что следует закрепить отдельным граничным тестом?

Option Explicit On
Option Infer On
Namespace BoundaryCase18_4
    Class SaveCommand
        Implements ICommand
        Private ReadOnly canSave As Func(Of Boolean)
        Private ReadOnly save As Action
        Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
            Return canSave()
        End Function
        Public Sub Execute(parameter As Object) Implements ICommand.Execute
            save()
        End Sub
        Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged
    End Class
End Namespace

Зафиксировать ожидаемое поведение: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged не должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Зафиксировать ожидаемое поведение: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Зафиксировать ожидаемое поведение: iCommand не отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Зафиксировать ожидаемое поведение: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс не показывает устаревшую доступность. Зафиксировать ожидаемое поведение: wPF постоянно вызывает CanExecute сам, поэтому CanExecuteChanged не нужен даже при изменении условий доступности команды.

Вопрос 19 из 25

Какое решение соответствует реальному времени жизни объектов и правилам «Команды интерфейса»?

Оставить в коде и тестах условие: wPF постоянно вызывает CanExecute сам, поэтому CanExecuteChanged не нужен даже при изменении условий доступности команды. Оставить в коде и тестах условие: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс не показывает устаревшую доступность. Оставить в коде и тестах условие: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Оставить в коде и тестах условие: iCommand не отделяет действие и условие доступности от кнопки; CanExecuteChanged должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность. Оставить в коде и тестах условие: iCommand отделяет действие и условие доступности от кнопки; CanExecuteChanged не должен обновляться при изменении условий, иначе интерфейс показывает устаревшую доступность.

Вопрос 20 из 25

Что точнее всего описывает механизм «Команды интерфейса»?

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

Вопрос 21 из 25

Раздел «Безопасность данных»: в примере с LoginViewModel важна не форма записи, а поведение. Какое утверждение его описывает?

Class LoginViewModel
    Public Property UserName As String
    Public Property Password As String

    Public Function Validate() As Boolean
        If String.IsNullOrWhiteSpace(UserName) Then Return False
        If String.IsNullOrEmpty(Password) Then Return False
        Return UserName.Length >= 3 AndAlso Password.Length >= 12
    End Function
End Class

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

Вопрос 22 из 25

Раздел «Безопасность данных»: что следует зафиксировать в ревью, чтобы ошибка не переехала из сборки в выполнение?

Option Strict On
Namespace ReviewCase18_5
    Class LoginViewModel
        Public Property UserName As String
        Public Property Password As String

        Public Function Validate() As Boolean
            If String.IsNullOrWhiteSpace(UserName) Then Return False
            If String.IsNullOrEmpty(Password) Then Return False
            Return UserName.Length >= 4 AndAlso Password.Length >= 13
        End Function
    End Class
End Namespace

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

Вопрос 23 из 25

Раздел «Безопасность данных»: для участка с LoginViewModel нужен отрицательный тест. Какой контракт стоит проверить, меняя только одно условие?

Option Explicit On
Option Infer On
Namespace BoundaryCase18_5
    Class LoginViewModel
        Public Property UserName As String
        Public Property Password As String

        Public Function Validate() As Boolean
            If String.IsNullOrWhiteSpace(UserName) Then Return False
            If String.IsNullOrEmpty(Password) Then Return False
            Return UserName.Length >= 2 AndAlso Password.Length >= 11
        End Function
    End Class
End Namespace

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

Вопрос 24 из 25

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

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

Вопрос 25 из 25

Какое утверждение точнее отделяет «Безопасность данных» от соседних механизмов?

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