- •1. Назначение языка
- •2. Способы использования языка
- •3. Нотация языка uml
- •Виды диаграмм uml
- •5. Диаграмма прецедентов (use case diagram)
- •6. Диаграмма классов (class diagram)
- •7. Диаграмма объектов (object diagram)
- •8. Диаграмма последовательностей (sequence diagram)
- •9. Диаграмма взаимодействия (кооперации, collaboration diagram)
- •10. Диаграмма состояний (statechart diagram)
- •11. Диаграмма активности (деятельности, activity diagram)
- •12. Диаграмма развертывания (deployment diagram)
- •13. Ооп и последовательность построения диаграмм
- •14. Отображение класса и его элементов на диаграмме uml
- •15. Способы использования объектов класса
- •16. Моделирование наследования в uml
- •17. Отношения между классами
- •18. Отношение зависимости между классами
- •19. Отношение ассоциации между классами
- •20. Композиция и агрегация классов
- •21. Сравнение диаграмм активностей и блок-схем
- •22. Моделирование процессов диаграммами активности
- •23. Моделирование операций диаграммами активности
- •24. Правила построения диаграммам активности
- •Составление перечня деятельностей в системе
- •Принятие решения о необходимости построения диаграммы деятельностей
- •25. Диаграмма кооперации
- •26. Диаграмма последовательностей как диаграмма взаимодействия
- •27. Диаграмма кооперации как альтернатива диаграмм последовательностей
- •28. Диаграмма кооперации как диаграмма взаимодействий объектов
- •29. Типы сообщений: синхронные, асинхронные и ответные, потерянные и найденные.
- •30. Уровни экземпляров и спецификации в диаграммах кооперации
- •31. Мультиобъекты, композитные и активные объекты в диаграммах кооперации.
- •32. Диаграммы взаимодействия с разветвленным потоком управления
- •33. Нефункциональные требования и их отображение на диаграммах прецедентов
- •34. Понятие эктора и отношения между экторами
- •35. Отношения включения и расширения между экторами
- •36. Причины использования прецедентов.
- •37. Прецеденты в прямом и обратном проектировании
- •38. Обзор case-средств для построения диаграмм uml
- •Visio поддерживает множество локальных языков
- •39. Критерии выделения прецедентов
- •40. Понятие шаблона проектирования
- •41. Основные шаблоны grasp
- •Information Expert (Информационный эксперт)
- •Indirection (Посредник)
- •42. Описание шаблонов проектирования GoF
- •43. Классификация шаблонов проектирования GoF
- •44. Структурные шаблоны проектирования
- •56. Понятие рефакторинга программ
- •57. Анти-шаблоны управления разработкой программ
- •Раздувание по (Software bloat): Разрешение последующим версиям системы требовать всё больше и больше ресурсов
- •58. Анти-шаблоны разработки программ
- •59. Анти-шаблоны в объектно-ориентированном программировании
- •60. Анти-шаблоны в программировании
- •61. Методологические анти-шаблоны
- •62. Анти-шаблоны управления конфигурацией
- •63. Примеры организационных анти-шаблонов
- •64. Социальные анти-шаблоны
- •Шаблоны параллельного программирования (Concurrency)
- •Другие типы шаблонов
- •66. Шаблон делегирования
- •Простой пример
- •67. Шаблон функционального дизайна
- •68. Неизменяемый объект (шаблон проектирования)
- •69. Интерфейс (шаблон проектирования)
- •70. Порождающие шаблоны проектирования
- •71. Абстрактная фабрика (шаблон проектирования)
- •72. Строитель (шаблон проектирования)
- •73. Фабричный метод (шаблон проектирования)
- •74. Отложенная инициализация (шаблон проектирования)
- •75. Объектный пул (шаблон проектирования)
- •76. Прототип (шаблон проектирования)
- •77. Получение ресурса есть инициализация (шаблон проектирования)
- •78. Одиночка (шаблон проектирования)
- •79. Структурные шаблоны
- •80. Адаптер (шаблон проектирования)
- •81. Мост (шаблон проектирования)
- •82. Компоновщик (шаблон проектирования)
- •83. Декоратор (шаблон проектирования)
- •84. Фасад (шаблон проектирования)
- •85. Приспособленец (шаблон проектирования)
- •86. Заместитель (шаблон проектирования)
- •87. Поведенческие шаблоны
- •88. Цепочка ответственности (шаблон проектирования)
- •89. Команда (шаблон проектирования)
- •90. Интерпретатор (шаблон проектирования)
- •91. Итератор (шаблон проектирования)
- •92. Посредник (шаблон проектирования)
- •93. Хранитель (шаблон проектирования)
- •94. Наблюдатель (шаблон проектирования)
- •95. Состояние (шаблон проектирования)
- •96. Стратегия (шаблон проектирования)
- •97. Шаблоны параллельного программирования Шаблоны параллельного программирования (Concurrency)
- •Пример реализации Пример c#
- •Следствия
- •98. Модель-представление-контроллер (шаблон проектирования)
- •99. Технология использования шаблонов проектирования
44. Структурные шаблоны проектирования
Структурные шаблоны — шаблоны проектирования, в которых рассматривается вопрос о том, как из классов и объектов образуются более крупные структуры.
Использование
Структурные шаблоны уровня класса используют наследование для составления композиций из интерфейсов и реализаций. Простой пример — использование множественного наследования для объединения нескольких классов в один. В результате получается класс, обладающий свойствами всех своих родителей. Особенно полезен этот шаблон, когда нужно организовать совместную работу нескольких независимо разработанных библиотек.
Шаблоны
Адаптер
Мост
Компоновщик
Декоратор
Фасад
Front Controller (англ.)
Приспособленец
Заместитель
45. Шаблоны централизованного управления
46. Шаблоны управления на основе событий
47. Шаблоны взаимодействия с базами данных
48. Структурные шаблоны интеграции
49. Понятие анти-шаблона или ловушки проектирования
Анти-паттерны (anti-patterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем. Они изучаются, как категория, в случае когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем.
Термин происходит из информатики, из книги «Банды четырёх» Шаблоны проектирования, которая заложила примеры практики хорошего программирования. Авторы назвали эти хорошие методы «шаблонами проектирования», и противоположными им являются «анти-паттерны». Частью хорошей практики программирования является избегание анти-паттернов.
Концепция также прекрасно подходит к машиностроению. Несмотря на то, что термин нечасто используется вне программной инженерии, концепция является универсальной.
Анти-паттерны в управлении разработкой ПО
Дым и зеркала (Smoke and mirrors): Демонстрация того, как будут выглядеть ненаписанные функции (название происходит от двух излюбленных способов, которыми фокусники скрывают свои секреты)
Раздувание ПО (Software bloat): Разрешение последующим версиям системы требовать всё больше и больше ресурсов
Функции для галочки: Превращение программы в конгломерат плохо реализованных и не связанных между собой функций (как правило, для того, чтобы заявить в рекламе, что функция есть)
Анти-паттерны в разработке ПО
Инверсия абстракции (Abstraction inversion): Создание простых конструкций поверх сложных (спорный)
Неопределённая точка зрения (Ambiguous viewpoint): Представление модели без спецификации её точки рассмотрения
Большой комок грязи (Big ball of mud): Система с нераспознаваемой структурой
Блоб (Blob): см. Божественный объект (God object)
Бензиновая фабрика (Gas factory): Необязательная сложность дизайна
Затычка на ввод данных (Input kludge): Забывчивость в спецификации и выполнении поддержки возможного неверного ввода
Раздувание интерфейса (Interface bloat): Изготовление интерфейса очень мощным и очень трудным для осуществления
Магическая кнопка (Magic pushbutton): Выполнение результатов действий пользователя в виде неподходящего (недостаточно абстрактного) интерфейса. Например, в системах типа Delphi это написание прикладной логики в обработчиках нажатий на кнопку
Перестыковка (компьютер) (Re-Coupling): Процесс внедрения ненужной зависимости
Дымоход (Stovepipe system): Редко поддерживаемая сборка плохо связанных компонентов
Гонки (Race hazard, Race condition): непредвидение возможности наступления событий в порядке, отличном от ожидаемого
Анти-паттерны в объектно-ориентированном программировании
Базовый класс-утилита (BaseBean): Наследование функциональности из класса-утилиты вместо делегирования к нему
Вызов предка (CallSuper): Для реализации прикладной функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка
Ошибка пустого подкласса (Empty subclass failure): Создание класса (в Perl), который не проходит «проверку пустоты подкласса» («Empty Subclass Test») из-за различного поведения по сравнению с классом, который наследуется от него без изменений
Божественный объект (God object): Концентрация слишком большого количества функций в одной части системы (классе)
Объектная клоака (Object cesspool): Переиспользование объектов, находящихся в непригодном для переиспользования состоянии
Полтергейст (компьютер) (Poltergeist): Объекты, чьё единственное предназначение — передавать информацию другим объектам
Проблема йо-йо (Yo-yo problem): Чрезмерная размытость сильно связанного кода (например, выполняемого по порядку) по иерархии классов
Одиночество (антипаттерн) (Singletonitis): Избыточное использование паттерна одиночка
Методологические анти-паттерны
Анти-паттерны управления конфигурацией
Анти-паттерны в программировании
50. Методы настройки и обеспечения гибкости проектов
51. Понятие стратегии и классов стратегии
52. Способы реализации классов стратегии
53. Деструкторы классов стратегии
54. Неполная конкретизация классов стратегии
55. Функторы и их использование
Фу́нктор (англ. function object) — концепция программирования, позволяющая использовать объект класса как функцию. Как правило, функторы используются для написания callback-функций.
Java
Поскольку в Java функции не являются объектами первого класса, функторы представляют собой интерфейс с единственным методом, как правило, реализованный в виде безымянного вложенного класса):
List<String> list = Arrays.asList("10", "1", "20", "11", "21", "12");
Collections.sort(list, new Comparator<String>() {
public int compare(String o1, String o2) {
return Integer.valueOf(o1).compareTo(Integer.valueOf(o2));
}
});
В C# для программирования функторов используются делегаты.