В таком случае, мы можем использовать паттерн Фабричный метод для создания объектов файлов. Абстрактный класс "Файл" определяет абстрактный метод "создатьФайл()", который будет реализован в каждом подклассе для создания объектов соответствующего типа.

4. 
   Простая фабрика (Simple Factory)
   

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

Плюсы простой фабрики:

• 
  Упрощение процесса создания объектов. Фабрика позволяет скрыть сложную логику создания объектов от клиентского кода, что упрощает его использование.
  
• 
  Повышение гибкости. При использовании простой фабрики, клиентский код зависит от абстракции интерфейса, а не от конкретных классов. Это позволяет легко заменять создаваемые объекты без изменения клиентского кода.
  
• 
  Улучшение поддерживаемости кода. Логика создания объектов инкапсулирована в одном месте, что делает код более читабельным, понятным и легким для изменения.
  

Минусы простой фабрики:

• 
  Ограниченность вариантов создаваемых объектов. Простая фабрика позволяет создавать только определенный набор объектов, которые предусмотрены в её реализации. Добавление нового типа объекта может потребовать изменения кода фабрики.
  
• 
  Нарушение принципа открытости/закрытости. Если требуется добавить новый тип объекта, то необходимо изменить код фабрики, что может привести к изменению уже существующего функционала.
  

Пример

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

5. 
   Прототип(Prototype)
   

Прототип (Prototype) - это паттерн проектирования, который позволяет создавать новые объекты путем копирования уже существующего объекта-прототипа. Таким образом, паттерн Прототип позволяет создавать объекты, избегая сложностей, связанных с созданием объектов с нуля.

---

Плюсы прототипа:

• 
  Избегание сложной логики создания объектов: Прототип позволяет создавать новые объекты на основе существующих объектов-прототипов. Это упрощает процесс создания объектов, так как не требуется сложной логики конструирования объектов с нуля.
  
• 
  Гибкость и увеличение производительности: Прототип позволяет динамически создавать новые объекты, в зависимости от текущего состояния приложения или потребностей. Это может быть полезно, когда требуется создание большого количества объектов с различными конфигурациями, так как необходимо лишь клонировать существующий прототип, а не создавать каждый объект с нуля.
  
• 
  Сокрытие сложной логики создания: Прототип абстрагирует клиентский код от деталей создания объектов. Клиенту не нужно знать, как создаются объекты, достаточно иметь доступ к прототипам и их методу клонирования.
  

Минусы прототипа:

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

Пример

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

6. 
   Одиночка (Singleton)
   

---

Одиночка (Singleton) - это паттерн проектирования, который гарантирует, что класс имеет только один экземпляр, и предоставляет глобальную точку доступа к этому экземпляру. Одиночка контролирует процесс создания своего единственного объекта и предоставляет доступ к этому объекту из любой части программы..
Плюсы

• 
  контролируемый доступ к единственному экземпляру;
  
• 
  уменьшение числа имён;
  
• 
  допускает уточнение операций и представления;
  
• 
  допускает переменное число экземпляров;
  
• 
  большая гибкость, чем у операций класса.
  

Минусы

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

Пример

Одиночка является класс "Логгер", используемый для записи логов в приложении. При использовании Одиночки можно гарантировать, что в системе будет только один экземпляр логгера, и все компоненты приложения будут использовать этот экземпляр для записи логов.
3.Поведенческие шаблоны

1. 
   Цепочка обязанностей (Chain of Responsibility)
   

Цепочка обязанностей (Chain of Responsibility) - это паттерн проектирования, который позволяет передавать запросы по цепочке потенциальных обработчиков, пока один из них не обработает запрос или пока запрос не достигнет конца цепочки. Этот паттерн позволяет избежать привязки отправителя запроса к его получателю и позволяет множеству объектов иметь возможность обработки запроса.

Плюсы

• 
  Гибкость и расширяемость: Паттерн цепочки обязанностей позволяет гибко настраивать порядок обработки запросов и добавлять или удалять обработчики в цепочку без изменения клиентского кода. Это делает систему более гибкой и расширяемой, позволяя легко вносить изменения.
  
• 
  Распределение ответственности: Цепочка обязанностей позволяет распределить ответственность за обработку запроса между несколькими объектами. Каждый объект в цепочке может принять решение о том, может ли он обработать запрос или должен передать его следующему объекту. Это позволяет добиться логической разделенности и уменьшить связанность между объектами.
  
• 
  Повышение поддерживаемости: Использование цепочки обязанностей упрощает поддержку кода, так как изменение логики обработки запроса происходит только в одном месте - в соответствующем обработчике. Это позволяет избежать разбросанных изменений по всей системе.
  

---

Минусы

• 
  Не гарантирует обработку запроса: В цепочке обязанностей ни один объект не обязан обработать запрос, и он может достичь конца цепочки без обработки. Это может быть проблемой, если запрос должен быть обязательно обработан или если нет явного обработчика по умолчанию.
  
• 
  Возможна задержка в обработке: Каждый объект в цепочке должен принять решение о передаче запроса следующему объекту или его обработке. Если цепочка очень длинная или обработка запросов требует больших ресурсов, это может привести к задержкам в обработке запроса.
  

Пример

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

2. 
   Команда (Command)
   

Команда (Command) - это паттерн проектирования, который инкапсулирует запрос в виде объекта, позволяя параметризовать клиентские запросы. Он преобразует запросы на выполнение определенных операций в объекты, что позволяет передавать их как аргументы, сохранять их в истории, отменять или повторять операции

Плюсы

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

Минусы

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

---

Пример

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

3. 
   Итератор (Iterator)
   

Итератор (Iterator) - это паттерн проектирования, который предоставляет способ последовательного доступа к элементам коллекции без раскрытия ее внутренней структуры. Итератор обеспечивает единый интерфейс для перебора элементов, что позволяет клиентскому коду обходить коллекцию без необходимости знать ее конкретную реализацию.

Плюсы

• 
  Упрощает перебор элементов коллекции, скрывая ее внутреннюю структуру.
  
• 
  Позволяет клиентскому коду работать с коллекцией и перебирать ее элементы, не зависимо от ее конкретной реализации.
  
• 
  Повышает безопасность итерации, предотвращая некорректные операции со стороны клиента.
  
• 
  Позволяет одновременно перебирать элементы коллекции разными способами, используя различные итераторы.
  

Минусы

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

Примеры

Обработка файлов:

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

4. 
   Посредник (Mediator)
   

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

• 
  Уменьшение связанности: Паттерн Посредник помогает уменьшить связанность между объектами, так как они не взаимодействуют напрямую. Это облегчает изменения в системе и добавление новых объектов, не затрагивая уже существующие.
  
• 
  Упрощение коммуникации: Посредник централизует всю коммуникацию между объектами, что делает ее более управляемой и понятной. Объекты не обязаны знать о существовании друг друга, что снижает сложность кода.
  
• 
  Повышение переиспользуемости: Посредник может быть использован повторно в различных ситуациях и с разными группами объектов. Это позволяет повысить переиспользуемость кода и упростить его тестирование.
  

---

Смотрите также файлы

• Отчет по производственной практике (по профилю специальности) Обучающегося.docx

• Дипломды жмыс 5В010500 Арнайы жне инклюзивті білім беру мамандыы араанды . 2022 азастан Республикасы.doc

• Планконспект по военнополитической подготовке с личным составом инженернотехнического батальона войсковой части 43294. Тема 8 Ратная слава России. Занятие 5 Войско древнерусского государства (ix начало xii). Учебные вопросы.docx

• Рекомендации по подготовке презентации.pdf

• Опишите какими качествами должен обладать успешный лидер (Идеальный лидер). Какие черты характера у него должны быть.docx