- •Назначение и структура платформы .Net (NetFrameWork). Виды net-приложений и их базовые концепции (Console, WinForms, wpf, asp.Net).
- •2. Управляемый и неуправляемый код. Взаимодействие с унаследованным кодом. Структура сборки net - приложения.
- •Назначение, достоинства и недостатки msil. Процесс компиляции и исполнения net – приложения.
- •Назначение и состав общей системы типов cts. Основные используемые типы в Net-приложениях.
- •Отличительные особенности сборки, пространства имен и типов. Подключение библиотечных и дополнительных пространств имен.
- •Освобождение памяти и сборка мусора net–приложений. Стратегия поколений объектов.
- •Конфигурирование net - приложений. Назначение файлов Machine.Config, App.Config, App.Exe.Config
- •Понятие и назначение делегата. Пример использования делегата в ооп на c#.
- •Понятие и назначение события. Примеры использования событий в c#.
- •Основные элементы управления WinForms-приложений. Возможности управления поведением элементов при изменении размеров формы (элементы Anchor и Dock).
- •Виды окон, используемых для приложений WinForms. Состав файлов формы и их назначение.
- •12. Списки, очереди, стеки, словари, их применение и сравнение с массивами. Интерфейс iEnumerable и его назначение
- •13. Обработка и генерация исключений. Создание собственных исключений для приложения.
- •14. Локализация WinForms-приложений. Понятие ресурсов и подчиненной сборки.
- •15. Развертывание net-приложений. Развертывание xcopy и управление встроенными каталогами. Понятие строгого имени и развертывание общих сборок.
- •16. Понятие и назначение домена приложений. Достоинства и недостатки домена по сравнению с потоками и процессами.
- •17. Основные цели, достоинства и недостатки ооп.
- •18. Понятие объекта и задач построения ис с точки зрения объектов. Назначение и структура crc-карточек.
- •1 9. Понятия инкапсуляции и абстракции, их назначение в ооп.
- •20. Назначение и структура языка uml
- •21. Отношение зависимости, ассоциации, агрегации и композиции между классами.
- •24. Базовые принципы программирования dry, kiss, yagni.
- •25. Принцип единственности ответственности и шаблон проектирования Expert.
- •26. Шаблоны проектирования High Cohesion и Low Coupling.
- •27. Шаблон проектирования Creator
- •28. Назначение модульного тестирования. Понятие единицы автономного тестирования.
- •29. Тестирование методом черного и белого ящиков и их применение к модульному тестированию.
- •30. Назначение и целесообразность использования заглушек.
- •31. Назначение подставного объекта и его отличие от заглушки.
- •34. Понятие полиморфизма и его основные виды (классический полиморфизм, перегрузка, параметрический полиморфизм).
- •35. Классический полиморфизм на основе наследования и его применение в базовых принципах проектирования.
- •36. Обоснованность применения наследования или композиции классов. Отрицательное правило наследования.
- •37. Понятие и назначение интерфейса. Отличие реализации интерфейса от наследования. Выбор предпочтения между наследованием и реализацией интерфейса.
- •38. Состав и назначение solid-принципов.
- •39. Понятие шаблона проектирования и структура шаблонов grasp.
- •40. Принцип открытости/закрытости (ocp) и его соответствие шаблонам полиморфизм и защита от изменений.
- •41. Формулировка и назначение принципа подстановки Liskov (lsv).
- •42. Назначение и структура принципа разделения интерфейсов (isp).
- •43. Назначение и структура принципа инверсии зависимостей (dip).
- •44. Формулировка, назначение и примеры использования принципа наименьшего знания (plk).
- •45. Назначение и формулировка шаблона Controller. Основные виды контроллеров и управление сложностью функционирования ис.
- •46. Назначение, формулировка и примеры использования шаблона чистая синтетика.
- •49. Назначение правила разработки тестовых случаев (test case) и тестовых комплектов
- •50. Классификация видов тестирования
31. Назначение подставного объекта и его отличие от заглушки.
Перед применением подставного объекта он подвергается настройке, в ходе которой задается ожидаемый сценарий его взаимодействия с тестируемым модулем. Задается последовательность вызовов методов подставного объекта, ожидаемые значения их входных аргументов, а также (внимание!) выходные значения (если есть), которые будут переданы тестируемому модулю. Таким образом, подставной объект способен как контролировать опосредованный вывод тестируемого модуля, так и управлять его опосредованным вводом, что делает его воистину неоценимым инструментом для тестирования межмодульного интерфейса (или интеграционного тестирования).
Заглушка просто принимает аргументы и обладает минимумом функционала. В подставные объекты же вложена логика, позволяющая управлять возвращаемыми значениями и ожидать определенных входных значений.
Подставной объект – такой поддельный объект, который определяет, прошел автономный тест или нет. Проверка делается не внутри подстановочного объекта, а именно в тесте.
Подставной объект может стать причиной не прохождения теста, заглушка – нет.
Пример:
Interface IWeb
{
Void Log(string message); //выводит сообщение(Message)
}
Public class FakeWeb:IWeb //класс для подстановочного объекта
{
Public string error;
Public FakeWeb(string message)
{
Error = message;
}
}
Public class LogAnalyzer {
Private IWeb service;
Public LogAnalyzer(IWeb service)
{
This.service = service;
}
Public void Analyze(string filename)
{
If (бла бла бла)
{
Service.Log(filename);
}
}
//тесты
FakeWeb service = new FakeWeb();
LogAnalyzer log = new LogAnalyzer(service); //тут взаимодействие между фейк классом(подстановкой) FakeWeb и тестируемым классом log.
String filename = “qwerty.txt”;
Log.Analyze(filename);
StringAssert.Contains(“qwerty.txt”, service.error);
(?) 32. Правила назначения имен классов, полей и методов. (С#)
Главное, чтобы названия соответствовали тому, за что отвечает поле, класс, метод. Не были слишком короткие. Главное – читабельность кода.
Pascal casing (каждое новое слово с заглавной) описываются имена:
всех определений типов, в том числе пользовательских классов, перечислений, событий, делегатов и структур;
значения перечислений;
readonly полей и констант;
интерфейсов;
методов;
пространств имен (namespace);
свойств;
публичных полей;
Camel casing (первое слово с маленькой, остальные с большой) Описываются имена:
локальных переменных;
аргументов методов;
защищенных (protected) полей.
Применяются следующие суффиксы и префиксы:
имена пользовательских классов исключений всегда заканчиваются суффиксом “Exception”;
имена интерфейсов всегда начинаются с префикса «I»;
имена пользовательских атрибутов всегда заканчиваются суффиксом «Attribute»;
имена делегатов обработчиков событий всегда оканчиваются суффиксом EventHandler, имена классов-наследников от EventArgs всегда заканчиваются суффиксом EventArgs.
Венгерская запись имен – слева или справа добавляется тип переменной. Имена классов д/б существительными, а методов – глаголами.
Если функция принимает в качестве аргумента флаг – ф-цию надо разделить.
Предпочтительны функции без аргументов, 3 и больше аргументов – плохо.
(?) 33. Правила написания комментариев в коде и автоматизированное формирование документации.
Начинайте каждый метод и процедуру с описания в комментарии того, что данный метод или процедура делает, параметров, возвращаемого значения и возможных ошибок и исключений. Опишите в комментариях роль каждого файла и класса, содержимое каждого поля класса и основные шаги сложного кода. Пишите комментарии по мере разработки кода.
Используйте комментарии без фанатизма. Использование комментариев не должно выходить за рамки. Когда вы пишите комментарий, то должны просто описать входящие и возвращаемые данные.
Нужно помнить, что желание написать комментарий говорит о сложности вашего алгоритма. Возможного его стоит упростить или разбить на части.
Автоматизированное форматирование настраивается в свойствах IDE.
Можно делать описание функций с помощью /// в C#.