Файл: уфимский университет науки и технологий факультет математики и информационных технологий кафедра программирования и экономической информатики.docx

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 10.11.2023

Просмотров: 177

Скачиваний: 8

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Минусы использования паттерна "Состояние":

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

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

  • Распределение поведения по классам состояний: При использовании паттерна "Состояние" логика поведения объекта может быть распределена по нескольким классам состояний. Это может затруднить понимание и поддержку логики, поскольку она разделена между различными классами.

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

Пример

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

3.10. шаблонный метод (Template Method)

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

Простыми словами: Шаблонный метод определяет каркас выполнения определённого алгоритма, но реализацию самих этапов делегирует дочерним классам.

Плюсы использования паттерна "Шаблонный метод":

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

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

  • Сокрытие деталей реализации: Паттерн "Шаблонный метод" позволяет скрыть детали реализации алгоритма от клиентского кода. Клиенты взаимодействуют с базовым классом, используя только публичные методы, не заботясь о внутренних шагах и деталях реализации.


Минусы использования паттерна "Шаблонный метод":

  • Жесткая структура: Паттерн "Шаблонный метод" определяет жесткую структуру алгоритма в суперклассе. Это означает, что изменение этой структуры может быть сложным, поскольку требует изменений в суперклассе и всех его подклассах.

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

  • Нарушение инкапсуляции: Шаблонный метод требует, чтобы подклассы имели доступ к внутренним методам суперкласса. Это может привести к нарушению инкапсуляции, поскольку подклассы получают прямой доступ к внутренним деталям реализации суперкласса.

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

  • Затруднения с отладкой: Шаблонный метод усложняет процесс отладки, поскольку алгоритм разделен на несколько методов, каждый из которых может быть переопределен подклассами. Это может затруднить понимание и отслеживание последовательности выполнения алгоритма.

Пример

Допустим, вы собрались строить дома. Этапы будут такими:

  1. Подготовка фундамента.

  2. Возведение стен.

  3. Настил крыши.

  4. Настил перекрытий.

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


    1. Принцип единственной обязанности

Принцип единственной обязанности (Single Responsibility Principle) - это один из принципов SOLID, который устанавливает, что каждый класс должен иметь только одну причину для изменения. Согласно этому принципу, класс должен быть ответственен только за выполнение одной конкретной задачи или иметь только одну обязанность.

Основные идеи принципа единственной обязанности:



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

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

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

Плюсы

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

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

  • Улучшение тестируемости: Более специализированные классы проще тестировать, так как их поведение ограничено и предсказуемо.

Минусы

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

  • Возможное увеличение сложности: Разделение функциональности на слишком маленькие классы может привести к излишней сложности и усложнению взаимодействия между классами.

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



    1. Принцип открытости/закрытости

Принцип открытости/закрытости (Open/Closed Principle) - это один из принципов SOLID, который устанавливает, что программные сущности, такие как классы, модули или функции, должны быть открытыми для расширения, но закрытыми для модификации. Согласно этому принципу, изменение поведения сущности должно быть достигнуто путем добавления нового кода, а не изменения существующего.

Основные идеи принципа открытости/закрытости:

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

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

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


Плюсы

  • Расширяемость: Благодаря принципу открытости/закрытости добавление новой функциональности становится проще и безопаснее. Расширение существующих классов или модулей позволяет сохранять совместимость с существующим кодом и избегать его поломки.

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

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

Минусы

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

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

  • Необходимость правильного определения границ модулей: Для успешной реализации принципа открытости/закрытости необходимо ясно определить границы модулей или компонентов. Неправильное определение границ может привести к нежелательным зависимостям и сложностям при поддержке и тестировании.

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

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

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


    1. 1   2   3   4   5