- •Назначение и структура платформы .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. Классификация видов тестирования
44. Формулировка, назначение и примеры использования принципа наименьшего знания (plk).
Инкапсуляция, которую принято отождествлять с закрытыми полями, является частью более общего принципа сокрытия информации (принципа наименьшего знания). Согласно которому детали непосредственной реализации различных компонентов системы скрыты, поскольку не обязательны для обеспечения их взаимодействия.
Объекты взаимодействуют друг с другом через интерфейсы, опуская детали реализации, о которых знать другим объектам не нужно.
45. Назначение и формулировка шаблона Controller. Основные виды контроллеров и управление сложностью функционирования ис.
Контроллер отвечает за обработку входных системных событий, делегируя обязанности по их обработке компетентным классам. Компонентный класс должен удовлетворять одному из следующих условий:
Класс представляет всю систему в целом, устройство или подсистему (внешний контроллер)
Класс представляет сценарий некоторого прецедента, в рамках которого выполняется обработка всех системных событий. Для всех системных событий в рамках одного сценария прецедента используется один и тот же класс-контроллер.
Прецедент (или вариант использования) описывает некоторый целостный фрагмент поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта.
Первым типом контроллеров является внешний контроллер (facade controller или Front Controller), представляющий всю систему, устройство или подсистему. Если применяется контроллер прецедента (use case controller), то для каждого прецедента должен существовать отдельный контроллер. Не объект предметной области, а искусственная конструкция.
Проблема: кто должен отвечать за обработку системных событий?
Системное событие – это событие высокого уровня, генерируемое внешним исполнителем (событие с внешним входом). Системные события связаны с системными операциями, т.е. операциями, выполняемыми системой в ответ на внешние воздействия.
Решение: делегирование обязанностей по обработке системных сообщений классу, удовлетворяющему одному из следующих условий:
класс представляет всю систему в целом (внешний контроллер);
класс представляет активный объект из реального мира (например, роль человека), который может участвовать в решении задачи (контроллер роли);
класс представляет искусственный обработчик всех системных событий некоторого прецедента использования системы и обычно называется <Прецедент>Handler (контроллер прецедента);
для системных событий множества родственных сценариев для всех прецедентов используется один и тот же контроллер. Например, для сценария создания и удаления пользователя, можно иметь один UserController, вместо двух отдельных контроллеров вариантов использования;
для всех системных событий одного нетривиального сеанса используется один контроллер. Сеанс - это реализация взаимодействия с исполнителем. Сеансы могут иметь произвольную длину, но зачастую организованы в рамках одного прецедента (сеанса прецедента
Контроллер – это объект, не относящийся к интерфейсу пользователя и отвечающий за обработку системных событий. Контроллер определяет методы для выполнения системных операций. Выбор наиболее подходящего контроллера определяется другими факторами, в частности степенью зацепления и связыванием
Первым типом контроллеров является внешний контроллер, представляющий всю «систему». Основная идея сводится к выбору некоторого класса, имя которого охватывает все слои приложения. Этот класс обеспечивает главную точку вызова всех служб из интерфейса пользователя и обращения к остальным слоям. Этот класс может представлять физический объект, например систему управления продажами или всю программную часть системы, или любые другие понятия, выбранные разработчиком для представления системы в целом.
Если применяется искусственный контроллер прецедента (use case controller), то для каждого прецедента должен существовать отдельный контроллер. Заметим, что это не объект из предметной области, а искусственная конструкция, поддерживающая функционирование системы. Например, если в системе розничной торговли используются прецеденты Buy Item и Return Item, то в ней должны быть реализованы контроллеры BuyItemHandler и ReturnItemHandler.
Достоинства:
улучшение условий для повторного использования компонентов. Этот шаблон обеспечивает обработку процессов предметной области на уровне реализации объектов, а не на уровне интерфейса. Обязанности контроллера могут быть технически реализованы в объектах интерфейса, однако в этом случае программный код и логические решения, относящиеся к процессам предметной области, будут жестко связаны с элементами интерфейса;
контроль состояния прецедента. Иногда необходимо удостовериться, что системные операции выполняются в некоторой определенной последовательности. Например, необходимо гарантировать, чтобы операция «Сделать оплату» выполнялась только после операции «Завершить продажу», для чего необходимо накапливать информацию о последовательности событий. Для этой цели удобно использовать контроллер, особенно контроллер прецедента.
Плохо спроектированный класс контроллера имеет низкую степень зацепления: он выполняет слишком много обязанностей и является несфокусированным. Такой контроллер называется раздутым (bloated controller). Признаки раздутого контроллера таковы.
в системе имеется единственный класс контроллера, получающий все системные сообщения, которых поступает слишком много. Такая ситуация зачастую возникает при использовании внешнего или ролевого контроллера;
контроллер сам выполняет все задачи, не делегируя обязанности другим классам. Обычно это приводит к нарушению основных принципов шаблонов «Эксперт» и «Сильное зацепление»;
контроллер имеет много атрибутов и содержит значительный объем информации о системе или предметной области, которую необходимо распределить между другими объектами, либо дублирует информацию, хранящуюся в других объектах.