Вы находитесь на странице: 1из 33

Contents

1. Этапы жизненного цикла программного обеспечения 2


2. Agile-манифест 2
3. Scrum Framework (Роли, артефакты, мероприятия) 3
4. Kanban Method 4
5. Системы управления версиями. Subversion и Git 5
6. Модели ветвления в Git 5
7. Заинтересованные лица / Стейкхолдеры 7
8. Способы спецификации требований 7
9. Пользовательские истории (User Story) 8
10. Очки истории (Story Points) 9
11. Диаграмма сценариев использования (Use case diagram) в UML 9
12. Диаграмма деятельности (Activity diagram) в UML 10
13. Структурный анализ 10
14. Принципы объектно-ориентированной методологии проектирования 11
15. Принципы объектно-ориентированного программирования 11
16. Принципы SOLID 12
17. Диаграмма классов (Class diagram) в UML 12
18. Порождающие шаблоны проектирования 13
19. Поведенческие шаблоны проектирования 14
20. Структурные шаблоны проектирования 14
21. Шаблон Model - View - Presenter (MVP) 14
22. Внедрение зависимостей 15
23. Типы данных в языке C# 15
24. Конструкторы 15
25. Деструкторы 16
26. Методы 16
27. Модификаторы доступа 16
28. Наследование 16
29. Перегрузка методов (конструкторов) 16
30. Перегрузка операторов 16
31. Переопределение методов 16
32. Свойства 16
33. Интерфейсы 16
34. Абстрактные классы 16
35. Класс object 16
36. Обобщения 16
37. Интерфейс IEnumerable 16
38. События и делегаты 17
39. Рефлексия 17
40. Исключения 17
41. Среда, безопасная к к несоответствию типов данных 17
42. Пространства имен 17
43. Компиляция исходного кода в .NET 17
44. Качество программного обеспечения 17
45. Оценка и контроль качества ПО 18
46. Тестирование программного обеспечения 19
47. Mock & Stub 19
48. Критерии полноты тестирования 19
49. Техника разработки через тестирование 19

1. Этапы жизненного цикла программного обеспечения


• Анализ требований
• Проектирование
• Разработка
• Тестирование
• Эксплуатация и сопровождение

2. Agile-манифест
Мы постоянно открываем для себя более совершенные методы разработки программного
обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря
проделанной работе мы смогли осознать, что:

• Люди и взаимодействие важнее процессов и инструментов.


• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
3. Scrum Framework (Роли, артефакты, мероприятия)
Роли:

• Владелец продукта (Product Owner)


o Определяет функциональность продукта
o Определяет даты релиза и содержимое
o Приоритизирует задачи
o Регулярно общается с пользователями
o Анализирует обратную связь и меняет направление разработки при
необходимости
o Принимает или отклоняет результаты работы
o Ответственнен за прибыль продукта
• Scrum мастер
o Следит за корректным применением принципов Agile и процессов (ритуалов)
Scrum
o Организует работу команды и обеспечивает её всем необходимым
o Защищает команду, несёт ответственность за её эффективность
o Только один человек
• Команда
o Обычно 6-9 человек.
o Кросс-функциональная: разработчики, тестироващики, дезайнеры, etc.
o Взаимозаменяемая
o Самоорганизующаяся
o Фиксированный состав (в ходе спринта)

Артефакты:

• Product Backlog — это приоритезированный список имеющихся на данный момент


бизнес требований и технических требований к системе. 
• Sprint Backlog — содержит функциональность, выбранную Product Owner из Product
Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. 
• Increment — сумма всех выполненных задач из Product Backlog в рамках спринта и
значение инкрементов всех предыдущих спринтов.

Мероприятия:

• Планирование спринта (Sprint planning)


• Ежедневное Scrum-совещание (Daily Scrum) — 3 вопроса за 15 минут:
o Что я сделал с момента прошлой встречи?
o Что я сделаю сегодня?
o Вижу ли я препятствия для себя и команды, которые могли бы затруднить
достижение цели спринта?
• Обзор итогов спринта (Sprint Review)
• Ретроспективное совещание (Sprint Retrospective)
• Обсуждение беклога (Baclog refinement meeting)
4. Kanban Method

На пример Kanban доски выше виден прицнип ограничения незавершённой работы (WIP) путём
ограничения количества карточек в колонке, что вынуждает команду реагировать на любой затык
до того как это приведёт к проблемам.

Диаграмма выполнения работ в Kanban Method отображает Cycle Time (время на выполнение
одной карточки) и Work In Progress (количество незавершённой работы в момент времени).
5. Системы управления версиями. Subversion и Git
SVN – централизованная VCS

Git – распределённая VCS

Базовые знания о процессе работы SVN: edit file -> svn add file -> svn commit

Базовые знания о процессе работы Git: edit file -> git add file -> git commit file -> git push

Способы перетащить изменения из отдной ветки в другую в Git:

• git merge
• git rebase
• git cherry-pick

6. Модели ветвления в Git


Git flow

• Ветка develop для полной истории


• Ветка master для урезанной истории
• Каждая новая функциональность разрабатывается в своей feature ветке
GitHub flow

• Никих develop, release и hotfix веток


• Любая работа (новая функциональность или исправление ошибок) выполняется в
отдельной ветке, порождённая от master

GitLab flow

• Любая работа (новая функциональность или исправление ошибок) выполняется в


отдельной ветке
• Дополнительные ветки для среды тестирования (если нужно)
• Дополнительные ветки для стабильнцх версий (если нужно)
7. Заинтересованные лица / Стейкхолдеры
Stakeholdet – англ. держатель доли, заинтересованное лицо в проекте.

• Те, кто активно вовлечен в проект и работает в нем.


• Те, на чьи интересы может повлиять проект и кто будет пользоваться его результатами.
• Те, кто в проект не вовлечен, но кто, в силу своего положения или профессиональной
деятельности, может на него влиять.

RACI матрица разделения полномочий:

• Responsible – ответственный непосредственно за выполнение работы


• Accountable – подотчетный, такую роль может занимать только один человек на одной
задаче
• Consulted – один сотрудник или группа, с которыми проводятся консультации
касательно задачи и мнения которых должно учитываться
• Informed – сотрудники, уведомляемые о выполнении конкретной задачи

8. Способы спецификации требований


Списки требований:
Достоинства

• Обеспечивает контрольный список требований.


• Обеспечивает договор между заказчиками и разработчиками.
• Для большой системы может обеспечить описание высокого уровня.

Недостатки

• Такие списки могут занимать сотни страниц. Фактически невозможно прочитать такие
документы в целом и получить чёткое понимание системы.
• Такие списки требований перечисляют отдельные требования абстрактно, оторванно
друг от друга и от контекста использования (и возможно с противоречиями)
• Эти списки создают ложное чувство взаимопонимания между заинтересованными
лицами и разработчиками.
• Эти списки дают заинтересованным лицам ложное чувство защищённости, что
разработчики должны достигнуть определённых вещей. Однако, из-за природы этих
списков, они неизбежно упускают важные требования, которые будут выявлены позже
в процессе. Разработчики могут использовать новые требования для пересмотра
сроков и условий в их пользу.

Прототипы (Опытные образцы):


Достоинства

• Позволяют представить на что будет похожа система


• Облегчают пользователям принятие проектных решений
• Отлично подходят для пользовательских интерфейсов

Недостатки
• Сложно объяснить почему нужно время на разработку окончательного продукта
• Зачастую приходится использовать прототип в реальной системе из-за нежелания
начинать всё сначала
• Риск потратить слишком много времени дизайн не оставив запаса на разработку
системы
• Мало полезны для сложной обработки данных

Сценарии использования: см. вопросы «Пользовательские истории» и «Диаграмма сценариев


использования в UML»

9. Пользовательские истории (User Story)


Запись, содержащая

• Один пользователь
• Одно действие
• Одна ценность

Примеры:

• Как, <роль пользователя>,


я бы хотел <что-то сделать>,
<с такой-то целью>
• Для достижения <цель>,
в качечтве <роль пользователя>,
Я бы хотел <функциональность>

Мнемоника INVEST (какой должна быть хорошая история):

• Independent Независимая
• Negotiable Обсуждаемая
• Valuable Ценная
• Estimable Оцениваемая
• Small Маленькая
• Testable Тестируемая
10. Очки истории (Story Points)
Очки истории это еденица измерения задач, позволяющая сравнить две задачи по сложности
выполнения. Эта оценка не привязана ко времени (если набор задач на 100SP занимает 1000
часов это вовсе не значит что 1SP = 10 ч.) и к конкретному участнику команды

Идея в том, что бы от предсказаний «мы угадаем мелодию за 10 часов» перейти к статистике «мы
угадываем мелодии на 20-25SP каждые 2 недели, давайте построим прогноз из соображений
лучшего и худшего сценариев»:

11. Диаграмма сценариев использования (Use case diagram) в UML


Ключ

евые элементы: актёр / актор (actor) и сценарий использования (use case).

Актёр / Актор — роль, исполняемая внешней сущностью, взаимодействующей с системой.


Актёром может быть человек, группа пользователей, другая система (внешняя по отношению к
проектируемой).

Сценарий использования — еденица функциональности, выполняемой системой в


сотрудничестве с одним или несколькими акторами и которая даёт наблюдаемый результат,
имеющий ценность для акторов.

Отношения между акторами: обобщение (generalization)


Отношения между сценариями использования: включение (include), расширение (extend)
12.

Диаграмма деятельности (Activity diagram) в UML

13. Структурный анализ


Ключевые элементы: принципы и диаграммы построения модели

Методология SADT (Structured  Analysis  and  Design  Technique) является наиболее известной


методикой структурно-функционального моделирования сложных систем (разработана в 1973 г.
Дугласом Россом (D.Ross).
Представляет собой совокупность методов, правил и процедур, предназначенных для построения
функциональной модели системы.

Модель SADT представляет собой серию диаграмм с сопроводительной документацией,


разбивающих сложный объект на составные части, которые представлены в виде блоков.

Принципы структурного анализа:

● Принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения


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

Диаграммы SADT:

● Диаграмма потоков данных DFD (Data Flow Diagram)


● Диаграмма сущность-связб ERD (Entity-Relationship Diagram)
● Диаграмма переходов состояний STD (State Transition Diagrams)

14. Принципы объектно-ориентированной методологии проектирования


● Абстрагирование — Выделение таких существенных характеристик объектов, которые
отличают его ото всех других объектов и которые четко определяют особенности данного
объекта с точки зрения дальнейшего рассмотрения и анализа. Только существенное для
данной задачи и ничего более. Минимальной единицей абстракции в ООМ является класс.
● Ограничение доступа — Процесс защиты отдельных элементов объекта, не
затрагивающий существенных характеристик объекта, как целого.
● Модульность — Свойство системы, связанное с возможностью декомпозиции на ряд тесно
связанных частей (модулей). Модульность опирается на дискретное программирование
объектов, которые можно модернизировать или заменять, не воздействуя на другие
объекты и систему в целом.
● Существование иерархий — Ранжирование, упорядочивание по некоторым правилам
объектов системы.

15. Принципы объектно-ориентированного программирования


● Абстракция
● Инкапсуляция
● Наследование
● Полиморфизм

16. Принципы SOLID


● S - Принцип единственной ответственности (The Single Responsibility Principle)
«Каждый класс выполняет лишь одну задачу.»
● O - Принцип открытости/закрытости (The Open Closed Principle)
«Программные сущности должны быть открыты для расширения, но закрыты для
модификации.»
● L - Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«Объекты в программе должны быть заменяемыми на экземпляры их подтипов без
изменения правильности выполнения программы.»
● I - Принцип разделения интерфейса (The Interface Segregation Principle)
«Много интерфейсов, специально предназначенных для клиентов, лучше, чем один
интерфейс общего назначения.»
● D - Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»

17. Диаграмма классов (Class diagram) в UML


Виды отношений:

Различие между композицией и агрегацией: Приведём наглядный пример. Комната является


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

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

В данном вопросе рассматриваются:

● Одиночка (Singleton)
● Фабричный метод
● Абстрактная фабрика

Достоинства шаблонов проектирования:

● Готовые конструкции для решения проблем


● Общая номенклатура для одинаковых решений

Недостатки шаблонов проектирования:

● Нарушение принципа DRY: отказ от повторного использования в пользу дублирования


● Соблазн подогнать проблему под шаблон проектирования
● Соблазн попробовать шаблон там, где он не нужен

Недостатки шаблона проектирования Одиночка (Singleton):

● Нарушение принципа Single Responsibility (класс отвечает за какое-то дело и за


собственное время жизни)
o Проблемы с расширяемостью
o Копипаста при создании других синглтонов
● Скрытые зависимости
● Проблемы тестируемостью

19. Поведенческие шаблоны проектирования


Поведенческие шаблоны проектирования определяют алгоритмы и способы реализации
взаимодейтсвия объектов.

В данном вопросе рассматриваются:

● Итератор
● Наблюдатель
● Команда
● Состояние

Достоинства шаблонов проектирования:

● Готовые конструкции для решения проблем


● Общая номенклатура для одинаковых решений

Недостатки шаблонов проектирования:

● Нарушение принципа DRY: отказ от повторного использования в пользу дублирования


● Соблазн подогнать проблему под шаблон проектирования
● Соблазн попробовать шаблон там, где он не нужен

20. Структурные шаблоны проектирования


Структурные шаблоны проектирования отвечают на вопрос «как из классов и объектов образуются
более крупные архитектуры».

В данном вопросе рассматриваются:

● Заместитель (Proxy)
● Адаптер (Wrapper)
● Фасад (Facade)

Достоинства шаблонов проектирования:

● Готовые конструкции для решения проблем


● Общая номенклатура для одинаковых решений

Недостатки шаблонов проектирования:

● Нарушение принципа DRY: отказ от повторного использования в пользу дублирования


● Соблазн подогнать проблему под шаблон проектирования
● Соблазн попробовать шаблон там, где он не нужен

21. Шаблон Model - View - Presenter (MVP)


Шаблон проектирования, используемый для построения пользовательского интерфейса и
решающий проблему связанности бизнес-логики и логики отображения.

Существует несколько подходов реализации MVP, однако здесь и далее речь идёт о подходе
Passive View.
● Представление (View) — Отображение данных от модели.
● Модель — бизнес-логика приложения.
● Представитель (Presenter) — Изменение модели и обновление отображения данных.

22. Внедрение зависимостей


Внедрение зависимостей — это способ обработки зависимостей вне зависимого класса, когда
зависимому классу не нужно ничего делать.

23. Типы данных в языке C#

Типы значений:

 Целочисленные типы (byte, sbyte, short, ushort, int, uint, long, ulong)

 Типы с плавающей запятой (float, double)

 Тип decimal

 Тип bool
 Тип char

 Перечисления enum

 Структуры (struct)

Ссылочные типы:

 Тип object

 Тип string

 Классы (class)

 Интерфейсы (interface)

 Делегаты (delegate)

24. Конструкторы
a. Оператор new
Оператор new динамически выделяет память для объекта и возвращает
ссылку на эту область памяти. Таким образом переменная, определенная в
данной конструкции не является объектом, она лишь ссылается на объект,
который был физически создан в памяти компьютера оператором new

b. Конструктор по умолчанию
Каждый класс C# снабжается конструктором по умолчанию, который при
необходимости может быть переопределен. По определению
такой конструктор никогда не принимает аргументов. После размещения
нового объекта в памяти конструктор по умолчанию гарантирует
установку всех полей в соответствующие стандартные значения.

c. Передача параметров в конструктор наследуемого класса


Дочерний класс наследует все те же свойства, методы, поля, которые
есть в классе-родителе. Единственное, что не передается при
наследовании, это конструкторы базового класса.
d. Статический конструктор
Статический конструктор – это специальный метод статического или нестатического класса.
Необходим для инициализации статических полей. Также используется для вызова статических
методов и однократного выполнения инструкций.
Программист не может вызвать статический конструктор, его вызывает среда выполнения (CLR)
автоматически в двух случаях:
 обращение к статическому члену;
 создание экземпляра нестатического типа со статическими членами.
Программист может лишь изменить реализацию статического конструктора, определив его в
области действия типа.

25. Деструкторы
e. Интерфейс Idisposable
Интерфейс IDisposable объявляет один единственный метод Dispose, в
котором при реализации интерфейса в классе должно происходить
освобождение неуправляемых ресурсов.

f. Конструкция using

Конструкция using оформляет блок кода и создает объект некоторого класса,


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

g. «сборка мусора»
При использовании же ссылочных типов, например, объектов классов, для
них также будет отводиться место в стеке, только там будет храниться не
значение, а адрес на участок памяти в хипе или куче, в котором и будут
находиться сами значения данного объекта. И если объект класса
перестает использоваться, то при очистке стека ссылка на участок памяти
также очищается, однако это не приводит к немедленной очистке самого
участка памяти в куче. Впоследствии сборщик мусора (garbage collector)
увидит, что на данный участок памяти больше нет ссылок, и очистит его.

26. Методы
h. Вызов методов
Если переменные хранят некоторые значения, то методы содержат собой
набор инструкций, которые выполняют определенные действия. По сути
метод - это именованный блок кода, который выполняет некоторые
действия.
i. Передача параметров / аргументов в методы
По умолчанию, в языке программирования C#, аргументы в методы передаются
по значению! Но большинство типов, используемых программистами, являются
всё-таки ссылочными типами, и в результате, в метод попадает копия ссылки,
j. Использование параметров с модификаторами ref и out
Модификатор ref предназначен для указания того, что параметр метода
должен передаваться по ссылке а не по значению. Другими словами, если у
методу нужно принудительно передать аргумент по ссылке, то при
объявлении метода перед соответствующим формальным параметром
нужно указать модификатор ref.

Модификатор параметра out используется, если необходимо


выполнение двух условий:
 методу не нужно передавать значение;
 метод обязательно должен возвращать значение с помощью параметра.
Модификатор out для параметра с именем param типа type указывается в начале
его объявления

k. Использование переменного количества аргументов


Модификатор params используется для объявления параметра-массива, который
сможет получить некоторое количество аргументов (в том числе и нулевое).
Количество элементов в массиве будет равно числу аргументов, переданных
методу.
l. Возвращение методом значений
Метод может возвращать значение, какой-либо результат. В примере
выше были определены два метода, которые имели тип void. Методы с
таким типом не возвращают никакого значения. Они просто выполняют
некоторые действия.
m. Методы расширения
Методы расширения (extension methods) позволяют добавлять новые
методы в уже существующие типы без создания нового производного
класса. Эта функциональность бывает особенно полезна, когда нам
хочется добавить в некоторый тип новый метод, но сам тип (класс или
структуру) мы изменить не можем, поскольку у нас нет доступа к
исходному коду. 
n. Вызов методов базового класса

Ключевое слово base используется для доступа к членам базового из производного


класса в следующих случаях:

 Вызов метода базового класса, который был переопределен другим методом.


 Определение конструктора базового класса, который должен вызываться при
создании экземпляров производного класса.

Доступ к базовому классу разрешен только в конструкторе, методе экземпляра или


методе доступа к свойству экземпляра.

Использование ключевого слова base в статическом методе является


недопустимым.

o. Ключевое слово this


Ключевое слово this ссылается на текущий экземпляр класса, а также
используется в качестве модификатора первого параметра метода
расширения.

27. Модификаторы доступа

 private: закрытый или приватный компонент класса или структуры. Приватный


компонент доступен только в рамках своего класса или структуры.
 private protected: компонент класса доступен из любого места в своем
классе или в производных классах, которые определены в той же сборке.
 protected: такой компонент класса доступен из любого места в своем классе
или в производных классах. При этом производные классы могут располагаться
в других сборках.
 internal: компоненты класса или структуры доступен из любого места кода в
той же сборке, однако он недоступен для других программ и сборок.
 protected internal: совмещает функционал двух
модификаторов protected и internal. Такой компонент класса доступен из
любого места в текущей сборке и из производных классов, которые могут
располагаться в других сборках.
 public: публичный, общедоступный компонент класса или структуры. Такой
компонент доступен из любого места в коде, а также из других программ и
сборок.

28. Наследование
Предотвращение наследования
Предотвращение наследования с помощью ключевого слова sealed

Проблемы, решаемые наследованием

Проблема круга и элипса


Как с точки зрения объектно-ориентированного подхода правильно объединить в
единую иерархию два класса - класс Эллипс и класс Окружность:

Унаследовав Эллипс от Окружности?


Или унаследовав Окружность от Эллипса?

Без разницы. Приверженцы обоих подходов рассматривают различные атрибуты


объектов, которых пытаются классифицировать. Но они не рассматривают самого
главного - назначения объектов и цели классификации.

Проблема мноественного наследования

Наиболее очевидная проблема связана с переопределением функций.

Допустим , есть два класса A и B, оба из которых определяют метод doSomething .


Теперь вы определяете третий класс C , который наследуется как от A , так и от B, но
вы не переопределяете метод doSomething .

29. Перегрузка методов (конструкторов)


перегруженными называют методы, которые отличаются сигнатурами, но при этом имеют
одинаковые имена.

C# также поддерживает сокращенную запись перегруженных методов:


float F(float x) => x - 2 / x;
int F(int x) => x - 2 / x;
Перегруженные методы могут отличаться только модификаторами

30. Перегрузка операторов


Перегрузка операторов заключается в определении в классе, для объектов которого мы
хотим определить оператор, специального метода:

public static возвращаемый_тип operator


оператор(параметры)
{ }
Этот метод должен иметь модификаторы public static, так как перегружаемый оператор
будет использоваться для всех объектов данного класса. Далее идет название
возвращаемого типа. Возвращаемый тип представляет тот тип, объекты которого мы хотим
получить. К примеру, в результате сложения двух объектов Counter мы ожидаем получить
новый объект Counter. А в результате сравнения двух мы хотим получить объект типа bool,
который указывает истинно ли условное выражение или ложно. Но в зависимости от задачи
возвращаемые типы могут быть любыми.
Затем вместо названия метода идет ключевое слово operator и собственно сам оператор. И
далее в скобках перечисляются параметры. Бинарные операторы принимают два параметра,
унарные - один параметр. И в любом случае один из параметров должен представлять тот
тип - класс или структуру, в котором определяется оператор.

p. Ограничения при перегрузке операторов


При перегрузке операторов надо учитывать, что не все операторы можно перегрузить. В
частности, мы можем перегрузить следующие операторы:

• унарные операторы +, -, !, ~, ++, --


• бинарные операторы +, -, *, /, %
• операции сравнения ==, !=, <, >, <=, >=
• логические операторы &&, ||

И есть ряд операторов, которые нельзя перегрузить, например, операцию равенства = или
тернарный оператор ?:, а также ряд других.

q. Индексаторы
Индексаторы позволяют индексировать объекты и обращаться к данным по
индексу. Фактически с помощью индексаторов мы можем работать с объектами как с
массивами. По форме они напоминают свойства со стандартными блоками get и set,
которые возвращают и присваивают значение.

Подобно методам индексаторы можно перегружать. В этом случае также индексаторы


должны отличаться по количеству, типу или порядку используемых параметров.

31. Переопределение методов


Чтобы сказать системе, что нам нужна возможность переопределить метод, нужно
использовать слово virtual. К примеру, при описании класса Object метод ToString()
имеет подобную запись.
public virtual string ToString()

Отметив метод словом virtual мы оповещаем систему, что метод может быть
переопределен в любом наследнике. А учитывая возможность построения
древовидной структуры наследования — возможность переопределения будет очень
полезной фичей.
override
Если было использовано это ключевое слово, на выходе будет использоваться
переопределенный метод. Вне зависимости от того, как было оформлено обращение
к методу.
new
Использование этого ключевого слова говорит системе о том, что мы не хотим
перекрыть реализацию метода в базовом классе. То есть, при необходимости сможем
получить доступ к методу предка.

32. Свойства
Кроме обычных методов в языке C# предусмотрены специальные методы доступа, которые
называют свойства. Они обеспечивают простой доступ к полям классов и структур, узнать
их значение или выполнить их установку.

Определение свойств
Стандартное описание свойства имеет следующий синтаксис:

1 [модификаторы] тип_свойства
2 название_свойства
3 {
4 get { действия, выполняемые при
5 получении значения свойства}
set { действия, выполняемые при
установке значения свойства}
}
Вначале определения свойства могут идти различные модификаторы, в частности,
модификаторы доступа. Затем указывается тип свойства, после которого идет название
свойства. Полное определение свойства содержит два блока: get и set.

В блоке get выполняются действия по получению значения свойства. В этом блоке с


помощью оператора return возвращаем некоторое значение.

В блоке set устанавливается значение свойства. В этом блоке с помощью параметра value
мы можем получить значение, которое передано свойству.

Блоки get и set еще называются акссесорами или методами доступа (к значению свойства),
а также геттером и сеттером.

То есть по сути свойство ничего не хранит, оно выступает в роли посредника между
внешним кодом и переменной name.

33. Интерфейсы
Для определения интерфейса используется ключевое слово interface. Как правило,
названия интерфейсов в C# начинаются с заглавной буквы I, например, IComparable,
IEnumerable (так называемая венгерская нотация), однако это не обязательное требование,
а больше стиль программирования.

Что может определять интерфейс? В целом интерфейсы могут определять следующие


сущности:

• Методы
• Свойства
• Индексаторы
• События
• Статические поля и константы (начиная с версии C# 8.0)

Однако интерфейсы не могут определять нестатические переменные.

То есть интерфейс описывает некоторый функционал, который должен быть у объекта.

Методы и свойства интерфейса могут не иметь реализации, в этом они сближаются с


абстрактными методами и свойствами абстрактных классов. В данном случае интерфейс
определяет метод Move, который будет представлять некоторое передвижение. Он не имеет
реализации, не принимает никаких параметров и ничего не возвращает.

То же самое в данном случае касается свойства Name. На первый взгляд оно похоже на
автоматическое свойство. Но в реальности это определение свойства в интерфейсе, которое
не имеет реализации, а не автосвойство.

Еще один момент в объявлении интерфейса: если его члены - методы и свойства не имеют
модификаторов доступа, но фактически по умолчанию доступ public, так как цель
интерфейса - определение функционала для реализации его классом. Это касается также и
констант и статических переменных, которые в классах и структурах по умолчанию имееют
модификатор private. В интерфейсах же они имеют по умолчанию модификатор public.

r. Использование интерфейсных ссылок


Такая переменная может ссылаться на любой объект, реализующий ее интерфейс. При
вызове метода для объекта посредством интерфейсной ссылки выполняется его вариант,
реализованный в классе данного объекта. Этот процесс аналогичен применению ссылки
на базовый класс для доступа к объекту производного класса.
Переменной ссылки на интерфейс доступны только методы, объявленные в ее
интерфейсе. Поэтому интерфейсную ссылку нельзя использовать для доступа к любым
другим переменным и методам, которые не поддерживаются объектом класса,
реализующего данный интерфейс.
Ключевое слово as
Определить, поддерживает ли данный тип тот или иной интерфейс, можно с
использованием ключевого слова as. Если объект удается интерпретировать как
указанный интерфейс, то возвращается ссылка на интересующий интерфейс, а если нет, то
ссылка null. Следовательно, перед продолжением в коде необходимо предусмотреть
проверку на null.

Ключевое слово is
Проверить, был ли реализован нужный интерфейс, можно также с помощью
ключевого слова is. Если запрашиваемый объект не совместим с указанным
интерфейсом, возвращается значение false, а если совместим, то можно спокойно
вызывать члены этого интерфейса без применения логики try/catch.

s. Явная реализация интерфейсов


При явной реализации указывается название метода или свойства вместе с
названием интерфейса, при этом мы не можем использовать модификатор public, то
есть методы являются закрытыми.

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

34. Абстрактные классы


Главное отличие абстрактных классов состоит в том, что мы не можем использовать
конструктор абстрактного класса для создания его объекта.

Кроме обычных свойств и методов абстрактный класс может иметь абстрактные члены
классов, которые определяются с помощью ключевого слова abstract и не имеют никакого
функционала. В частности, абстрактными могут быть:

• Методы
• Свойства
• Индексаторы
• События

Абстрактные члены классов не должны иметь модификатор private. При этом производный
класс обязан переопределить и реализовать все абстрактные методы и свойства, которые
имеются в базовом абстрактном классе. При переопределении в производном классе такой
метод или свойство также объявляются с модификатором override (как и при обычном
переопределении виртуальных методов и свойств). Также следует учесть, что если класс
имеет хотя бы одный абстрактный метод (или абстрактные свойство, индексатор, событие),
то этот класс должен быть определен как абстрактный.
Абстрактные члены также, как и виртуальные, являются частью полиморфного интерфейса.
Но если в случае с виртуальными методами мы говорим, что класс-наследник наследует
реализацию, то в случае с абстрактными методами наследуется интерфейс, представленный
этими абстрактными методами.

35. Класс object


t. Упаковка и распаковка

Если переменная типа object используется в левой части оператора присваивания,


то компилятор выполняет так называемую упаковку. Если переменная или
значение типа object используется в правой части оператора присваивания, то
компилятор выполняет распаковку.
Таким образом можно дать следующие определения. Упаковка — это процесс
сохранения значения простого типа (int, char, double …) в экземпляре объекта
(object). Распаковка — это процесс вытягивания упакованного значения (int, double,
char …) из объекта (object).

36. Обобщения
Обобщенные типы позволяют указать конкретный тип, который будет использоваться.
Угловые скобки в описании class Account<T> указывают, что класс является обобщенным, а
тип T, заключенный в угловые скобки, будет использоваться этим классом. Необязательно
использовать именно букву T, это может быть и любая другая буква или набор символов.
Причем сейчас нам неизвестно, что это будет за тип, это может быть любой тип. Поэтому
параметр T в угловых скобках еще называется универсальным параметром, так как
вместо него можно подставить любой тип.

Например, вместо параметра T можно использовать объект int, то есть число,


представляющее номер счета. Это также может быть объект string, либо или любой другой
класс или структура. Если в скобках указан допустим тип <int>, то при попытке присвоить
значение определённого свойства переменной другого типа мы получим ошибку
компиляции. Тем самым мы избежим проблем с типобезопасностью. Таким образом,
используя обобщенный вариант класса, мы снижаем время на выполнение и количество
потенциальных ошибок. Кроме обобщенных классов можно также создавать обобщенные
методы, которые точно также будут использовать универсальные параметры.

37. Интерфейс IEnumerable


Основной для большинства коллекций является реализация интерфейсов IEnumerable и
IEnumerator. Благодаря такой реализации мы можем перебирать объекты в цикле foreach.

Перебираемая коллекция должна реализовать интерфейс IEnumerable.


Интерфейс IEnumerable имеет метод, возвращающий ссылку на другой интерфейс -
перечислитель.

u. Foreach
Оператор цикла foreach предназначен для перебора элементов коллекции или
массива. Общая форма оператора foreach следующая
foreach(type identifier in container){ // операторы // ...}

где
• type – тип переменной с именем identifier;
• identifier – имя переменной, которая используется в качестве итератора.
Переменная identifier приобретает значение следующего элемента цикла на
каждом шаге выполнения цикла foreach. Тип переменной identifier должен
совпадать с типом массива или коллекции container. Связь между identifier и
container реализуется с помощью союза in;
• container – имя коллекции или массива, который просматривается.

Оператор цикла foreach работает следующим образом. При вхождении в цикл,


переменной identifier присваивается первый элемент массива (коллекции) container.
На каждом следующем шаге итерации выбирается следующий элемент из
container, который сохраняется в переменной identifier. Цикл завершается, когда
будут пересмотрены все элементы массива (коллекции) container.

v. Конструкции yield return и yield break.


Итератор по сути представляет блок кода, который использует оператор yield для
перебора набора значений. Данный блок кода может представлять тело метода, оператора
или блок get в свойствах.

Итератор использует две специальных инструкции:

• yield return: определяет возвращаемый элемент


• yield break: указывает, что последовательность больше не имеет элементов

оператор yield можно использовать внутри любого метода, только такой метод
должен возвращать объект интерфейса IEnumerable. Подобные методы еще называют
именованными итераторами.

38. События и делегаты


Делегаты представляют такие объекты, которые указывают на методы. То есть делегаты -
это указатели на методы и с помощью делегатов мы можем вызвать данные методы.
Для объявления делегата используется ключевое слово delegate, после которого идет
возвращаемый тип, название и параметры. delegate void Message();

События сигнализируют системе о том, что произошло определенное действие. И если нам
надо отследить эти действия, то как раз мы можем применять события.

События объявляются в классе с помощью ключевого слова event, после которого


указывается тип делегата, который представляет событие:

delegate void AccountHandler(string


message);
event AccountHandler Notify;

39. Рефлексия
Рефлексия представляет собой процесс выявления типов во время выполнения
приложения. Каждое приложение содержит набор используемых классов, интерфейсов, а
также их методов, свойств и прочих кирпичиков, из которых складывается приложение. И
рефлексия как раз и позволяет определить все эти составные элементы приложения.

Основной функционал рефлексии сосредоточен в пространстве имен System.Reflection

w. Класс System.Type и оператор typeof


Type является корневым классом для функциональных возможностей рефлексии и основным
способом доступа к метаданным. С помощью членов класса Type можно
получить сведения об объявленных в типе элементах: конструкторах, методах, полях, свойствах и
событиях класса, а также о модуле и сборке, в которых развернут данный класс . Некоторые из
его свойств и методов:
• Метод FindMembers() возвращает массив объектов MemberInfo данного типа
• Метод GetConstructors() возвращает все конструкторы данного типа в виде набора
объектов ConstructorInfo
• Метод GetEvents() возвращает все события данного типа в виде массива объектов
EventInfo
• Метод GetFields() возвращает все поля данного типа в виде массива объектов
FieldInfo
• Свойство Name возвращает имя типа
• Свойство Assembly возвращает название сборки, где определен тип
• Свойство Namespace возвращает название пространства имен, где определен тип

Чтобы управлять типом и получать всю информацию о нем, нам надо сперва получить
данный тип. Это можно сделать с помощью ключевого слова typeof.

x. Атрибуты
40. Исключения
При использовании блока try...catch..finally вначале выполняются все инструкции в блоке
try. Если в этом блоке не возникло исключений, то после его выполнения начинает
выполняться блок finally. И затем конструкция try..catch..finally завершает свою работу.

Если же в блоке try вдруг возникает исключение, то обычный порядок выполнения


останавливается, и среда CLR начинает искать блок catch, который может обработать
данное исключение. Если нужный блок catch найден, то он выполняется, и после его
завершения выполняется блок finally.

Если нужный блок catch не найден, то при возникновении исключения программа аварийно
завершает свое выполнение.

y. Генерация исключений
z. Обработка исключений
aa. Часто используемые исключения

bb. Часто встречающиеся исключения


ЧАСТО ВСТРЕЧАЮЩИЕСЯ ИСКЛЮЧЕНИЯ

Тип исключения Описание Пример


Exception Базовый класс для всех Отсутствует (используйте
исключений. производный класс этого
исключения).
IndexOutOfRangeException Вызывается средой Индексирование массива вне
выполнения только при допустимого диапазона:
неправильной индексации arr[arr.Length+1]
массива.
NullReferenceException Вызывается средой object o = null;
o.ToString();
выполнения только в том
случае, если имеется ссылка
на пустой объект.
InvalidOperationException Вызывается методами в Вызов Enumerator.MoveNext()
недопустимом состоянии. после удаления элемента из
базовой коллекции.
ArgumentException Базовый класс для всех Отсутствует (используйте
исключений аргументов. производный класс этого
исключения).
ArgumentNullException Вызывается методами, String s = null;
"Calculate".IndexOf(s);
которые не допускают пустой
аргумент.
ArgumentOutOfRangeException Вызывается методами,
проверяющими попадание
аргументов в заданный
диапазон.
41. Среда, безопасная к несоответствию типов данных
42. Пространства имен
Обычно определяемые классы и другие типы в .NET не существуют сами по себе, а
заключаются в специальные контейнеры - пространства имен. Пространства имен
позволяют организовать код программы в логические блоки, поволяют объединить и
отделить от остального кода некоторую функциональность, которая связана некоторой
общей идеей или которая выполняет определенную задачу.

Для определения пространства имен применяется ключевое слово namespace, после


которого идет название название пространства имен

cc. Псевдонимы
Псевдонимы – это стандартные названия предопределённых типов, но нужно
подчеркнуть, что они всегда присутствуют в C# (неважно подключено ли пространство
имён System).
Примерами из реальной жизни существования системных названий (типов) и их
псевдонимов являются некоторые человеческие имена. Например, Александр и Николай
– это системные названия, а Саша и Коля – их псевдонимы.
При создании переменной, используйте название-псевдоним, когда это возможно, а не
полное имя типа.
43. Компиляция исходного кода в .NET

44. Качество программного обеспечения


Качество программного обеспечения это способность программного продукта при
заданных условиях удовлетворять установленным или предполагаемым потребностям
[ISO/IEC 25000:2014].
Основные аспекты:

Характеристики качества:

● Функциональная пригодность
● Уровень производительности
● Совместимость
● Удобство использования
● Надёжность
● Защищённость
● Сопровождаемость
● Переносимость (мобильность)

45. Оценка и контроль качества ПО


Верификация (лат. verum «истинный», facere «делать») обозначает проверку того, что ПО
разработано в соответствии со всеми установленными требованиями к нему или что
очередной этап разработки выполнен в соответствии с ограничениями,
сформулированными на предшествующих этапах. 
Соответствует ли продукт требованиям?

Валидация (лат. validus «здоровый, крепкий, сильный»)— это проверка того, что сам


продукт правилен, т.е. подтверждение того, что он действительно удовлетворяет
требованиям и ожиданиям пользователей, заказчиков и других заинтересованных сторон. 
Подходит ли продукт для конкретного использования, применения?

Методы контроля качества:

● Методы и техники, связанные с выяснением свойств ПО во время его работы.


● Методы и техники определения показателей качества на основе симуляции работы ПО
с помощью моделей разного рода.
● Методы и техники, нацеленные на выявление нарушений формализованных правил
построения исходного кода ПО, проектных моделей и документации.
● Методы и техники обычного или формализованного анализа проектной документации
и исходного кода для выявления их свойств.

46. Тестирование программного обеспечения


Схема процесса тестирования

Уровни тестирования:

● System tests
● Integration tests
● Unit tests

Стратегии тестирования:

● Black box
● White box
● Gray box

47. Mock & Stub


48. Критерии полноты тестирования
● Покрытие операторов
● Покрытие условий
● Покрытие входных данных
● Покрытие требований

49. Техника разработки через тестирование


● Добавить тест
● Запустить тест (убедится, что тест не бесполезен)
● Написать кода чтобы пройти тест
● Запустить тест (убедиться, что тест пройден)
● Рефакторинг кода
● ???
● PROFIT!!!

Вам также может понравиться