Cop.Borovkov.Var3/Lab3/Models/StudentViewModel.cs

@@ -1,5 +1,4 @@
 using Lab3.Database.DTO;
-using System.Globalization;
 
 namespace Lab3.Models
 {

Lab5-6/lab5.md

@@ -0,0 +1,94 @@
+# Лабораторная работа №5.
+# Применение структурных паттернов.
+
+## Задание
+1) Дать описание паттернов, указанных во вариантах, для каких целей они могут применяться,
+    какие участники там фигурируют.
+2) На основе задания из 3 лабораторной работы, для каждого паттерна придумать сущности,
+   относящиеся к той же предметной области, что описаны в задании и реализация которых 
+    бы в приложении потребовала применения паттерна.
+    ### Ограничения:
+    - На каждый паттерн свои сущности
+    - В качестве источника сущностей использовать предметную область задания 3 лабораторной работы, а не элементы разработки (что-то типа «У меня паттерн Singleton, укажу ка я класс-подключение к БД через него», не принимается).
+3) Создать диаграммы классов, отражающие взаимодействие новых
+сущностей (а также используемый паттерн) с классами,
+созданными в рамках 3 лабораторной работы. Отдельно отметить
+классы, которые являются участниками паттерна
+
+## Вариант 3: _Adapter, Composite, Proxy_
+### Паттерн Adapter
+Паттерн Адаптер используется для того,
+чтобы объекты с несовместимыми интерфейсами могли работать вместе.
+Он оборачивает один интерфейс в другой, 
+делая несовместимые классы совместимыми без изменения их исходного кода.
+
+Задачи, которые решает паттерн Adapter:
+- Интеграция стороннего кода или библиотек: 
+когда требуется использовать стороннюю библиотеку с вашим приложением, 
+но её интерфейс отличается от имеющегося интерфейса.
+- Обратная совместимость: когда нужно подключить новый код к старому интерфейсу, не изменяя существующий.
+- Упрощение взаимодействия: уменьшает сложность работы с несколькими несовместимыми компонентами.
+
+Участники:
+- Target: представляет объекты, которые используются клиентом.
+- Client: использует объекты Target для реализации своих задач.
+- Adaptee: представляет адаптируемый класс, который хотелось бы использовать у клиента вместо объектов Target.
+- Adapter: сам адаптер, который позволяет работать с объектами Adaptee как с объектами Target.
+
+**Пример реализации для рассматриваемой предметной области:**<br>
+
+Классы, реализующие паттерн:
+- IStudentTracker (Target) – Интерфейс системы отслеживания успеваемости студентов
+- StudentManager (Client) – Использует данные о успеваемости, для определеня судьбы студентов  
+- AttendanceTracker (Adaptee) – Реализализовывает систему отслеживания посещаемости студентов
+- StudentTrackerAdapter (Adapter) – "оборачивает" стороннюю систему и преобразует её в интерфейс, ожидаемый клиентом
+
+![img_3.png](img_3.png)
+
+### Паттерн Composite
+Паттерн Компоновщик (Composite) объединяет группы объектов в древовидную структуру
+по принципу "часть-целое и позволяет клиенту одинаково работать как с отдельными объектами,
+так и с группой объектов.
+
+Образно реализацию паттерна можно представить в виде меню, 
+которое имеет различные пункты. Эти пункты могут содержать подменю, в которых,
+в свою очередь, также имеются пункты. То есть пункт меню служит с одной стороны частью меню,
+а с другой стороны еще одним меню. В итоге мы однообразно можем работать как с пунктом меню,
+так и со всем меню в целом.
+
+Участники:
+
+- Component – определяет интерфейс для всех компонентов в древовидной структуре
+- Composite – представляет компонент, который может содержать другие компоненты 
+и реализует механизм для их добавления и удаления
+- Leaf – представляет отдельный компонент, который не может содержать другие компоненты
+- Client – клиент, который использует компоненты
+
+Классы, реализующие паттерн:
+- IStudent (Component) – Студент обучающийся в вузе
+- Group (Composite) – Группировка студентов (групаа в потоке, поток, курс...)
+- Student (Leaf) – Конкретный студент
+- University (Client) – Обеспечивает обучение студентов
+
+![img.png](img.png)
+
+### Паттерн Proxy
+
+Паттерн Заместитель (Proxy) предоставляет объект-заместитель, который управляет доступом к другому объекту.
+То есть создается объект-суррогат, который может выступать в роли другого объекта и замещать его.
+
+Участники:
+
+- Subject – определяет общий интерфейс для Proxy и RealSubject. Поэтому Proxy может использоваться вместо RealSubject
+- RealSubject – представляет реальный объект, для которого создается прокси
+- Proxy – заместитель реального объекта. Хранит ссылку на реальный объект, контролирует к нему доступ,
+может управлять его созданием и удалением. При необходимости Proxy переадресует запросы объекту RealSubject
+- Client – использует объект Proxy для доступа к объекту RealSubject
+
+Классы, реализующие паттерн:
+- IStudent (Subject) – Студент
+- Student (RealSubject) – Студент из группы
+- Elder (Proxy) – Староста отвечает на вопросы преподователя, при надомности спрашивает студентов группы 
+- Lecturer (Client) - Задаёт вопросы студентам через старосту
+
+![img_2.png](img_2.png)

Lab5-6/lab6.md

@@ -0,0 +1,92 @@
+# Лабораторная работа №6.
+# Применение структурных паттернов.
+
+## Задание
+1) Дать описание паттернов, указанных во вариантах, для каких целей они могут применяться,
+    какие участники там фигурируют.
+2) На основе задания из 3 лабораторной работы, для каждого паттерна придумать сущности,
+   относящиеся к той же предметной области, что описаны в задании и реализация которых 
+    бы в приложении потребовала применения паттерна.
+    ### Ограничения
+    - На каждый паттерн свои сущности
+    - В качестве источника сущностей использовать предметную область задания 3 лабораторной работы,
+   а не элементы разработки (что-то типа «У меня паттерн Singleton,
+   укажу ка я класс-подключение к БД через него», не принимается).
+3) Создать диаграммы классов, отражающие взаимодействие новых
+сущностей (а также используемый паттерн) с классами,
+созданными в рамках 3 лабораторной работы. Отдельно отметить
+классы, которые являются участниками паттерна
+
+## Вариант 3 _AbstractFactory, FactoryMethod, ObjectPool._
+
+### Паттерн AbstractFactory
+
+Паттерн "Абстрактная фабрика" (Abstract Factory) предоставляет интерфейс для создания семейств
+взаимосвязанных объектов с определенными интерфейсами без указания конкретных типов данных объектов.
+
+Участники
+
+- AbstractProductA и AbstractProductB – абстрактные классы, определяющие интерфейс для классов,
+объекты которых будут создаваться в программе
+- ProductA1 / ProductA2 и ProductB1 / ProductB2 – конкретные классы, 
+представляющие конкретную реализацию абстрактных классов.
+- AbstractFactory - Абстрактный класс фабрики определяет методы для создания объектов.
+Причем методы возвращают абстрактные продукты, а не их конкретные реализации.
+- Client – класс клиента, использующий класс фабрики для создания объектов.
+При этом он использует исключительно абстрактный класс фабрики AbstractFactory
+и абстрактные классы продуктов AbstractProductA и AbstractProductB и никак не зависит от их конкретных реализаций.
+
+Классы, реализующие паттерн:
+
+- IReportFactory (Abstract Factory) интерфейс фабрики для создания отчетов.
+- FivePointReportFactory (Concrete Factory) фабрика для 5-балльной системы.
+- HundredPointReportFactory (Concrete Factory) фабрика для 100-балльной системы.
+- IPerformanceReport (Abstract Product) интерфейс для отчета по успеваемости.
+- FivePointPerformanceReport и HundredPointPerformanceReport (Concrete Products) конкретные реализации отчетов по успеваемости для 5- и 10-балльной систем.
+- ILaggingStudentsReport (Abstract Product) интерфейс для отчета по отстающим студентам.
+- FivePointLaggingStudentsReport и HundredPointLaggingStudentsReport (Concrete Products) отчеты по отстающим студентам для 5- и 10-балльной систем.
+- ReportManager (Client) класс, который обрабатывает отчеты
+
+![img_4.png](img_4.png)
+
+### Паттерн FactoryMethod
+
+Фабричный метод (Factory Method) - это паттерн, который определяет интерфейс для создания объектов некоторого класса, 
+но непосредственное решение о том, объект какого класса создавать происходит в подклассах. 
+То есть паттерн предполагает, что базовый класс делегирует создание объектов классам-наследникам.
+
+Участники:
+
+- Product – интерфейс или абстрактный класс, определяющий структуру создаваемых объектов.
+- ConcreteProductA и ConcreteProductB – конкретные реализации интерфейса “Product”, представляющие первый и второй тип продукта.
+- Creator – абстрактный класс или интерфейс, который определяет фабричный метод для создания объектов типа “Product”.
+- ConcreteCreatorA и ConcreteCreatorB – конкретные реализации “Creator”, которая создаёт объекты типа “ConcreteProductA” и “ConcreteCreatorB” соответственно.
+
+Классы, реализующие паттерн:
+
+- Product IReport – определяет интерфейс для всех отчетов.
+- ConcreteProductA и ConcreteProductB GradeReport и AttendanceReport – конкретные реализации интерфейса “IReport”.
+- Creator ReportCreator – определяет фабричный метод для создания объектов типа “IReport”.
+- ConcreteCreatorA и ConcreteCreatorB GradeReportCreator и AttendanceReportCreator – конкретные реализации “ReportCreator”.
+
+![img_5.png](img_5.png)
+
+### Паттерн ObjectPool
+
+Object Pool (пул объектов) — это поведенческий паттерн, который используется для оптимизации управления ресурсами. 
+Он позволяет многократно использовать уже созданные объекты вместо их повторного создания и уничтожения. 
+Это особенно полезно, когда создание объектов является дорогой операцией с точки зрения времени или ресурсов.
+
+Участники:
+
+- Pool – управляет коллекцией объектов. Отвечает за выдачу и возврат объектов из пула. Решает, когда создавать новый объект или использовать существующий.
+- ReusableObject (повторно используемый объект) - объект, который находится в пуле и может быть многократно использован. Включает логику и состояние объекта.
+- Client - получает объект из пула для использования. Возвращает объект обратно в пул, когда он больше не нужен.
+
+Классы, реализующие паттерн:
+
+- Pool FormatPool – управляет доступностью объектов “Format”. Позволяет выдавать объекты формы обучения для студентов.
+- ReusableObject Format – содержит данные, связанные с конкретной формой обучения.
+- Client Student – представляет студента и содержит данные о нем.
+
+![img_6.png](img_6.png)

Lab5-6/lab7.md

@@ -0,0 +1,74 @@
+# Лабораторная работа №7.
+# Применение структурных паттернов.
+
+## Задание
+1) Дать описание паттернов, указанных во вариантах, для каких целей они могут применяться,
+    какие участники там фигурируют.
+2) На основе задания из 3 лабораторной работы, для каждого паттерна придумать сущности,
+   относящиеся к той же предметной области, что описаны в задании и реализация которых 
+    бы в приложении потребовала применения паттерна.
+    ### Ограничения
+    - На каждый паттерн свои сущности
+    - В качестве источника сущностей использовать предметную область задания 3 лабораторной работы,
+   а не элементы разработки (что-то типа «У меня паттерн Singleton,
+   укажу ка я класс-подключение к БД через него», не принимается).
+3) Создать диаграммы классов, отражающие взаимодействие новых
+сущностей (а также используемый паттерн) с классами,
+созданными в рамках 3 лабораторной работы. Отдельно отметить
+классы, которые являются участниками паттерна
+
+## Вариант 3 _Mediator, Mediator (2 различных реализации), Strategy._
+
+### Паттерн Mediator
+
+Паттерн "Посредник" (Mediator) представляет такой шаблон проектирования, 
+который обеспечивает взаимодействие множества объектов без необходимости ссылаться друг на друга.
+Тем самым достигается слабосвязанность взаимодействующих объектов.
+
+Участники
+
+- Mediator - представляет интерфейс для взаимодействия с объектами Colleague.
+- Colleague - представляет интерфейс для взаимодействия с объектом Mediator.
+- ConcreteColleague1 и ConcreteColleague2 - конкретные классы коллег, 
+которые обмениваются друг с другом через объект Mediator.
+- ConcreteMediator - конкретный посредник, реализующий интерфейс типа Mediator.
+
+Классы, реализующие паттерн:
+- Secretary Mediator - Секретарь
+- Client Colleague - Участник вузовской системы 
+- Teacher ConcreteColleague1 - Преподователь
+- Student ConcreteColleague2 - Студент
+- Dean`s Office ConcreteMediator - Деканат
+
+![img_8.png](img_8.png)
+
+- ILms Mediator - Сайт лмс
+- User Colleague - Пользователь лмс
+- Teacher ConcreteColleague1 - Преподователь
+- Student ConcreteColleague2 - Студент
+- Lms ConcreteMediator - Логика сайта лмс
+
+![img_7.png](img_7.png)
+
+### Паттерн Strategy
+
+Strategy (Стратегия) — шаблон проектирования, который определяет набор алгоритмов, инкапсулирует каждый из них 
+и обеспечивает их взаимозаменяемость.
+В зависимости от ситуации мы можем легко заменить один используемый алгоритм другим. 
+При этом замена алгоритма происходит независимо от объекта, который использует данный алгоритм.
+
+Участники:
+
+- IStrategy: интерфейс, который определяет метод Algorithm(). Это общий интерфейс для всех реализующих его алгоритмов.
+Вместо интерфейса здесь также можно было бы использовать абстрактный класс.
+- ConcreteStrategy1 и ConcreteStrategy2: классы, которые реализуют интерфейс IStrategy, 
+предоставляя свою версию метода Algorithm(). Подобных классов-реализаций может быть множество.
+- Context: класс, который хранит ссылку на объект IStrategy и связан с интерфейсом IStrategy отношением агрегации.
+
+Классы, реализующие паттерн:
+
+- IStrategy IStudentWorkChecker – общий интерфейс для всех стратегий проверку индивидуальной работы студента.
+- СourseWorkChecker, LabWorkChecker - классы, реализующие проверку ирс
+- Context Teacher – Преподаватель выбирает подходящцю стратегию для проверки работы
+
+![img_10.png](img_10.png)