- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
2. Объектно-ориентированное проектирование (часть 2) презентация
Содержание
- 1. 2. Объектно-ориентированное проектирование (часть 2)
- 2. Шаблон Controller Проблема Кто должен отвечать за
- 3. Контроллеры Классы, обязанности которых состоят в обработке
- 4. 1-Й ВАРИАНТ Все системные операции выполняются одним внешним контроллером *
- 5. 2-Й ВАРИАНТ Системные операции распределены между несколькими контроллерами прецедента *
- 6. Выбор варианта Выбор между вариантом использования внешнего
- 7. РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТА «ОФОРМЛЕНИЕ ПРОДАЖИ» Реализация прецедента показывает,
- 8. Диаграммы взаимодействия Реализация прецедентов представляется в виде
- 9. Прецедент «Оформление продажи» На текущей итерации рассмотрены
- 10. Операция makeNewSale Операция makeNewSale() Ссылки
- 11. Диаграмма последовательности
- 12. Операция enterItem Операция enterItem(iID: ItemID, quantity:
- 13. Обработка enterItem Ранее было установлено, что объект
- 14. Класс ProductCatalog На основе анализа предметной области
- 15. Диаграмма кооперации
- 16. Операция endSale Операция endSale() Ссылки
- 17. Диаграмма кооперации
- 18. Вычисление общей стоимости В соответствии с
- 19. Операция makePayment Операция makePayment(amount: Money) Ссылки Прецеденты:
- 20. Создание Payment В соответствии с шаблоном Creator
- 21. Регистрация покупки
- 22. Вычисление сдачи В роли частичных экспертов могут
- 23. Вычисление сдачи
- 24. РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТА «ЗАПУСК СИСТЕМЫ» Практически все системы
- 25. Запуск приложения Представляется системной операцией StartUp, которая
- 26. Запуск приложения Должен быть выбран исходный объект
- 27. Выбор исходного объекта В качестве исходного выбирается
- 28. Операция StartUp Операция StartUp() Ссылки Прецеденты: Запуск
- 29. Операция StartUp Постусловия (продолжение) Создан экземпляр класса
- 30. Диаграмма кооперации
- 31. Подключение уровня интерфейса До сих пор проектирование
- 32. Связь уровней приложения
- 33. СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ
- 34. Идентификация классов На основе анализа диаграмм взаимодействия
- 35. Определение методов классов Сообщения, передаваемые классу, определяют
- 36. Методы классов
- 37. Ассоциации и навигация Линии связи и навигации
- 38. Ассоциации между классами
- 39. Отношения зависимости Означает наличие у одного из
- 40. РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ
- 41. Программный код На заключительном этапе итерации проектное
- 42. Порядок реализации классов Классы нужно реализовывать и
- 43. Вариант последовательности реализации
- 44. Тестирование модулей Осуществляется с использованием утилит модульного
- 45. Синхронизация артефактов На этапе реализации программного кода
- 46. Переход к новой итерации
- 47. ВТОРАЯ ИТЕРАЦИЯ
- 48. Задачи Реализация поддержки внешних служб (начисление налоговых платежей) Сложные правила вычисления стоимости Подключаемые бизнес-правила
- 49. Задача1: Поддержка внешних служб Каждая из систем
- 50. Шаблон Adapter Проблема Как обеспечить взаимодействие с
- 51. Пример
- 52. Шаблон Factory Проблема Какой класс должен отвечать
- 53. Обоснование решения Действительно, если бы обязанности по
- 54. Объект-фабрика
- 55. Объект-фабрика Методы класса-фабрики возвращают результат с типом
- 56. Шаблон Singleton Использование объекта-фабрики порождает новую проблему
- 57. Шаблон Singleton Проблема Как обеспечить взаимодействие с
- 58. Шаблон Singleton
- 59. Реализация метода getInstance() // статический метод public
- 60. Пример обращения к объекту-фабрике public class Register
- 61. Задача2: Сложные правила вычисления стоимости Проблема заключается
- 62. Шаблон Strategy Проблема Как спроектировать надежные, но
- 63. Шаблон Strategy
- 64. Терминология Объекты классов, реализующих различные стратегии называются
- 65. Взаимодействие объекта-стратегии с объектом Sale При отправке
- 66. Взаимодействие объекта-стратегии с объектом Sale
- 67. Создание объектов стратегий Так же, как и
- 68. Фабрика стратегий
- 69. Создание объекта стратегии
- 70. Почему две фабрики «Каждому виду объектов своя
- 71. Задача 3:Подключение бизнес-правил Требуется подключить правила, отменяющие
- 72. Генератор правил Реализацию тех или иных бизнес-правил
- 73. Шаблон Facade Проблема Как обеспечить унифицированный интерфейс
- 74. Шаблон Facade В данном случае можно определить
- 75. Пример обращения к объекту фасада public class
- 76. Конец лекции
Шаблон Controller Проблема Кто должен отвечать за обработку системных сообщений? Решение Обязанности по обработке системных сообщений назначаются классу, который: представляет систему в целом; представляет сценарий некоторого прецедента, в рамках которого обрабатываются
Слайд 2Шаблон Controller
Проблема Кто должен отвечать за обработку системных сообщений?
Решение Обязанности по
обработке системных сообщений назначаются классу, который:
представляет систему в целом;
представляет сценарий некоторого прецедента, в рамках которого обрабатываются системные сообщения
представляет систему в целом;
представляет сценарий некоторого прецедента, в рамках которого обрабатываются системные сообщения
*
Слайд 3Контроллеры
Классы, обязанности которых состоят в обработке системных сообщений называются классами контроллера
Классы
контроллера не относятся к интерфейсу пользователя
В рассматриваемом примере возможны два варианта решения
В рассматриваемом примере возможны два варианта решения
*
Слайд 6Выбор варианта
Выбор между вариантом использования внешнего контроллера (facade controller) и вариантом
контроллеров прецедентов определяется, в основном требованиями соблюдения малой степени сцепления и высокой связности
*
Слайд 7РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТА «ОФОРМЛЕНИЕ ПРОДАЖИ»
Реализация прецедента показывает, как определенный прецедент представляется в
рамках модели проектирования в терминах взаимодействующих объектов
Слайд 8Диаграммы взаимодействия
Реализация прецедентов представляется в виде диаграмм взаимодействия, начинающихся с соответствующего
системного сообщения
Диаграммы взаимодействия включают процессы передачи сообщений между программными объектами, участвующими в реализации прецедента
Диаграммы взаимодействия включают процессы передачи сообщений между программными объектами, участвующими в реализации прецедента
Слайд 9Прецедент «Оформление продажи»
На текущей итерации рассмотрены следующие системные события и соответствующие
операции:
Начать оформление покупки (makeNewSale)
Ввести данные товара (enterItem)
Завершить оформление покупки (endSale)
Оформить платеж (makePayment)
Для наглядности каждая операция будет представлена отдельной диаграммой
Начать оформление покупки (makeNewSale)
Ввести данные товара (enterItem)
Завершить оформление покупки (endSale)
Оформить платеж (makePayment)
Для наглядности каждая операция будет представлена отдельной диаграммой
Слайд 10Операция makeNewSale
Операция
makeNewSale()
Ссылки
Прецеденты: Оформление продажи
Предусловия
Отсутствуют
Постусловия
Создан экземпляр s класса
Sale
Экземпляр s связан с объектом класса Registor
Установлены атрибуты экземпляра s
Экземпляр s связан с объектом класса Registor
Установлены атрибуты экземпляра s
Слайд 12Операция enterItem
Операция
enterItem(iID: ItemID, quantity: integer)
Ссылки
Прецеденты: Оформление продажи
Предусловия
Инициирована продажа
Постусловия
Создан экземпляр sli класса SalesLineItem
Экземпляр sli связан с объектом класса Sale
Атрибуту sli.quantity присвоено значение quantity
Экземпляр sli связан с классом ProductSpecification
Слайд 13Обработка enterItem
Ранее было установлено, что объект Sale должен создаваться объектом Registor
Объект
Sale создает объект SalesLineItem и добавляет его в свой контейнер
Затем необходимо получить описание товара ProductSpecification для экземпляра SalesLineItem
Кто должен поставлять эту информацию?
Затем необходимо получить описание товара ProductSpecification для экземпляра SalesLineItem
Кто должен поставлять эту информацию?
Слайд 14Класс ProductCatalog
На основе анализа предметной области и в соответствии с шаблоном
Expert эта обязанность должна быть назначена классу ProductCatalog
Этот класс должен содержать коллекцию экземпляров класса ProductSpecification
Запрос на получение описания товара должен отправлять объект Register
Этот класс должен содержать коллекцию экземпляров класса ProductSpecification
Запрос на получение описания товара должен отправлять объект Register
Слайд 16Операция endSale
Операция
endSale()
Ссылки
Прецеденты: Оформление продажи
Предусловия
Инициирована продажа
Постусловия
Атрибуту isComplete экземпляра
класса Sale присвоено значение true
Слайд 18Вычисление общей стоимости
В соответствии с описанием данного прецедента после завершения
оформления продажи система должна вычислить общую стоимость покупки
Слайд 19Операция makePayment
Операция makePayment(amount: Money)
Ссылки Прецеденты: Оформление продажи
Предусловия Инициирована продажа
Постусловия
Создан экземпляр
p класса Payment
Экземпляр p связан с объектом класса Sale
Атрибуту amountTendered присвоено значение amount
Экземпляр Sale связан с экземпляром класса Store для его добавления в журнал продаж
Экземпляр p связан с объектом класса Sale
Атрибуту amountTendered присвоено значение amount
Экземпляр Sale связан с экземпляром класса Store для его добавления в журнал продаж
Слайд 20Создание Payment
В соответствии с шаблоном Creator и с учетом требований слабого
сцепления и сильной связности обязанность создавать экземпляры класса Payment назначена объекту класса Sale, активно использующему информацию экземпляра Payment
Слайд 22Вычисление сдачи
В роли частичных экспертов могут выступать объекты классов:
Sale (информация о
полной стоимости)
Payment (информация о внесенной покупателем сумме)
Экземпляр класса Sale является создателем объекта класса Payment и может запросить у него сумму платежа
Payment (информация о внесенной покупателем сумме)
Экземпляр класса Sale является создателем объекта класса Payment и может запросить у него сумму платежа
Слайд 24РЕАЛИЗАЦИЯ ПРЕЦЕДЕНТА «ЗАПУСК СИСТЕМЫ»
Практически все системы включают прецедент «Запуск системы» и
системную операцию, связанную с запуском приложения
Слайд 25Запуск приложения
Представляется системной операцией StartUp, которая является абстракцией реального процесса загрузки
и инициализации приложения
Диаграмма взаимодействия для операции StartUp строится в последнюю очередь, когда уже известна информация об основных системных операциях
Диаграмма взаимодействия для операции StartUp строится в последнюю очередь, когда уже известна информация об основных системных операциях
Слайд 26Запуск приложения
Должен быть выбран исходный объект предметной области; соответствующий программный объект
создается первым
Этот объект наделяется обязанностью создания других объектов, наличие которых необходимо для начала работы приложения, а также их инициализации
Этот объект наделяется обязанностью создания других объектов, наличие которых необходимо для начала работы приложения, а также их инициализации
Слайд 27Выбор исходного объекта
В качестве исходного выбирается объект, наиболее приближенный к корню
иерархии объектов
В нашем случае это может быть Register либо Store
Исходя из требования высокой степени связности, выберем объект Store
В нашем случае это может быть Register либо Store
Исходя из требования высокой степени связности, выберем объект Store
Слайд 28Операция StartUp
Операция StartUp()
Ссылки Прецеденты: Запуск системы
Предусловия Отсутствуют
Постусловия
Создан экземпляр класса Store
Создан
экземпляр pc класса ProductCatalog
Экземпляр pc связан с экземпляром класса Store
Создан экземпляр ps класса ProductSpecification
Экземпляр ps связан с объектом класса Product Catalog
Экземпляр pc связан с экземпляром класса Store
Создан экземпляр ps класса ProductSpecification
Экземпляр ps связан с объектом класса Product Catalog
Слайд 29Операция StartUp
Постусловия (продолжение)
Создан экземпляр класса Register
Экземпляр класса Store связан с экземпляром
класса Register
Экземпляр pc связан с экземпляром класса Register
Экземпляр pc связан с экземпляром класса Register
Слайд 31Подключение уровня интерфейса
До сих пор проектирование велось на уровне объектов предметной
области
Для подключения уровня пользовательского интерфейса потребуем, чтобы инициализирующая программа создавала и объекты уровня пользовательского интерфейса и исходный объект уровня предметной области с их связыванием
Для подключения уровня пользовательского интерфейса потребуем, чтобы инициализирующая программа создавала и объекты уровня пользовательского интерфейса и исходный объект уровня предметной области с их связыванием
Слайд 34Идентификация классов
На основе анализа диаграмм взаимодействия можно выделить следующие классы:
Register
Sale
ProductCatalog
ProductSpecification
SalesLineItem
Store
Payment
Слайд 35Определение методов классов
Сообщения, передаваемые классу, определяют большую часть его методов
Иногда на
диаграмме классов можно размещать дополнительную информацию о типах передаваемых методами параметров и возвращаемых результатов
Слайд 37Ассоциации и навигация
Линии связи и навигации устанавливаются на основе анализа диаграмм
взаимодействия
Такие ассоциации интерпретируются как видимость целевого класса для класса-источника, обеспечиваемая с помощью атрибутов (атрибут класса-источника является ссылкой на экземпляр целевого класса)
Такие ассоциации интерпретируются как видимость целевого класса для класса-источника, обеспечиваемая с помощью атрибутов (атрибут класса-источника является ссылкой на экземпляр целевого класса)
Слайд 39Отношения зависимости
Означает наличие у одного из классов информации о другом классе
Изображается
пунктирной линией
Объект класса Register получает информацию об объекте класса ProductSpecification в виде возвращаемого значения метода getSpecification, а объект класса Sale – через параметр метода makeLineItem
Объект класса Register получает информацию об объекте класса ProductSpecification в виде возвращаемого значения метода getSpecification, а объект класса Sale – через параметр метода makeLineItem
Слайд 41Программный код
На заключительном этапе итерации проектное решение отображается в программный код
При
этом производится описание классов с добавлением атрибутов-ссылок, а также записывается реализация методов на основе соответствующих диаграмм взаимодействия
Слайд 42Порядок реализации классов
Классы нужно реализовывать и тестировать в рамках модулей, начиная
с минимально сцепленных
В нашем проекте это классы Payment и ProductSpecification
Затем реализуются классы со все большей степенью сцепления
Примеры реализации
В нашем проекте это классы Payment и ProductSpecification
Затем реализуются классы со все большей степенью сцепления
Примеры реализации
Слайд 44Тестирование модулей
Осуществляется с использованием утилит модульного тестирования (NUnit, JUnit и т.д.)
Широко
используемой является практика программирования на основе тестирования, когда тесты пишутся до написания кода
Тем самым обеспечивается тотальный и неформальный характер тестирования
Тем самым обеспечивается тотальный и неформальный характер тестирования
Слайд 45Синхронизация артефактов
На этапе реализации программного кода проясняются многие детали, не учтенные
на стадиях анализа и проектирования
Поэтому после завершения кодирования необходимо произвести синхронизацию основных артефактов – концептуальной модели, проектного решения и программного кода
Поэтому после завершения кодирования необходимо произвести синхронизацию основных артефактов – концептуальной модели, проектного решения и программного кода
Слайд 48Задачи
Реализация поддержки внешних служб (начисление налоговых платежей)
Сложные правила вычисления стоимости
Подключаемые бизнес-правила
Слайд 49Задача1: Поддержка внешних служб
Каждая из систем начисления налоговых платежей имеет собственный
интерфейс и обладает собственным поведением
Необходимо обеспечить возможность подключения разрабатываемой системы к любой из систем начисления налоговых платежей
Необходимо обеспечить возможность подключения разрабатываемой системы к любой из систем начисления налоговых платежей
Слайд 50Шаблон Adapter
Проблема Как обеспечить взаимодействие с различными внешними системами?
Решение Преобразовать интерфейс
внешней системы к другому виду с помощью промежуточного объекта-адаптера
Слайд 52Шаблон Factory
Проблема Какой класс должен отвечать за создание объектов-адаптеров? Как определять
тип создаваемого адаптера?
Решение Создать искусственный (не представляющий понятия предметной области) объект и назначить ему группу обязанностей по созданию других объектов
Решение Создать искусственный (не представляющий понятия предметной области) объект и назначить ему группу обязанностей по созданию других объектов
Слайд 53Обоснование решения
Действительно, если бы обязанности по созданию новых объектов были поручены
одному из объектов уровня предметной области (например, Register), то это нарушило бы принцип разделения обязанностей
Кроме того, это уменьшило бы связность соответствующего объекта уровня предметной области
Кроме того, это уменьшило бы связность соответствующего объекта уровня предметной области
Слайд 55Объект-фабрика
Методы класса-фабрики возвращают результат с типом интерфейса, а не класса
Это позволяет
объекту-фабрике создавать любую реализацию интерфейса
Информацию о типе создаваемого адаптера объект-фабрика должен получать из внешнего источника
Информацию о типе создаваемого адаптера объект-фабрика должен получать из внешнего источника
Слайд 56Шаблон Singleton
Использование объекта-фабрики порождает новую проблему проектирования – кто должен создавать
саму фабрику и как получить к ней доступ?
При этом очевидно, что в рамках приложения нужен всего лишь один экземпляр фабрики, доступ к которому возможен для любых объектов
При этом очевидно, что в рамках приложения нужен всего лишь один экземпляр фабрики, доступ к которому возможен для любых объектов
Слайд 57Шаблон Singleton
Проблема Как обеспечить взаимодействие с объектом-фабрикой различных объектов системы, используя
при этом единственную точку доступа?
Решение Определить статический метод класса, возвращающий объект-фабрику
Решение Определить статический метод класса, возвращающий объект-фабрику
Слайд 59Реализация метода getInstance()
// статический метод
public static synchronized ServicesFactory getInstance( )
{
if
(instance == null)
instance = new ServicesFactory( );
return instance;
}
instance = new ServicesFactory( );
return instance;
}
Слайд 60Пример обращения к объекту-фабрике
public class Register
{
public void initialize ( )
{ …выполняем
необходимые действия
// обращаемся к объекту-фабрике через вызов
// статического метода getInstance ( )
ServicesFactory. getInstance ( ). getAccountAdapter();
…выполняем необходимые действия
}
// другие методы
}
// обращаемся к объекту-фабрике через вызов
// статического метода getInstance ( )
ServicesFactory. getInstance ( ). getAccountAdapter();
…выполняем необходимые действия
}
// другие методы
}
Слайд 61Задача2: Сложные правила вычисления стоимости
Проблема заключается в обеспечении возможности вычисления стоимости
покупки с учетом различного рода скидок (сезонных, постоянным клиентам и т.д.)
Политика скидок может изменяться с течением времени, причем достаточно часто
Политика скидок может изменяться с течением времени, причем достаточно часто
Слайд 62Шаблон Strategy
Проблема Как спроектировать надежные, но изменяемые алгоритмы (стратегии)? Каким способом
вносить изменения?
Решение Определить для каждого алгоритма отдельный класс со стандартным интерфейсом
Решение Определить для каждого алгоритма отдельный класс со стандартным интерфейсом
Слайд 64Терминология
Объекты классов, реализующих различные стратегии называются объектами стратегий
Объект, к которому применяется
варьируемый алгоритм называется контекстным объектом
В нашем примере контекстным объектом является объект класса Sale
В нашем примере контекстным объектом является объект класса Sale
Слайд 65Взаимодействие объекта-стратегии с объектом Sale
При отправке объекту класса Sale сообщения getTotal
он делегирует часть своих задач объекту стратегии
При этом контекстный объект передает объекту стратегии ссылку на самого себя (this) для обеспечения параметрической видимости
При этом контекстный объект передает объекту стратегии ссылку на самого себя (this) для обеспечения параметрической видимости
Слайд 67Создание объектов стратегий
Так же, как и в случае адаптеров, создание объектов
стратегий следует осуществлять на основе шаблона Factory
Единственный объект-фабрика должен получать и выполнять запрос на создание объекта стратегии определенного типа
Единственный объект-фабрика должен получать и выполнять запрос на создание объекта стратегии определенного типа
Слайд 70Почему две фабрики
«Каждому виду объектов своя фабрика» – такой подход позволяет
понизить степень связанности в системе
Объект-фабрика ServicesFactory имеет дело только с объектами-адаптерами, а объект-фабрика PricingStrategyFactory – с объектами-стратегиями
Объект-фабрика ServicesFactory имеет дело только с объектами-адаптерами, а объект-фабрика PricingStrategyFactory – с объектами-стратегиями
Слайд 71Задача 3:Подключение бизнес-правил
Требуется подключить правила, отменяющие некоторые действия, например:
при наличии подарочного
сертификата может быть приобретен только один товар – все операции enterItem, кроме первой должны быть отменены;
при проведении благотворительной акции могут приобретаться товары стоимостью не выше некоторой пороговой
при проведении благотворительной акции могут приобретаться товары стоимостью не выше некоторой пороговой
Слайд 72Генератор правил
Реализацию тех или иных бизнес-правил целесообразно выделить в особую подсистему
– «генератор правил»
Правила и их реализация подвержены частым изменениям, поэтому связывание с этой подсистемой должно быть минимальным
Правила и их реализация подвержены частым изменениям, поэтому связывание с этой подсистемой должно быть минимальным
Слайд 73Шаблон Facade
Проблема Как обеспечить унифицированный интерфейс с набором разрозненных интерфейсов и
реализаций, подверженных частым изменениям
Решение Определить одну точку взаимодействия с подсистемой – фасадный объект и возложить на него обязанность по взаимодействию с компонентами подсистемы
Решение Определить одну точку взаимодействия с подсистемой – фасадный объект и возложить на него обязанность по взаимодействию с компонентами подсистемы
Слайд 74Шаблон Facade
В данном случае можно определить подсистему «генератор правил», которую можно
реализовать либо на основе шаблона Strategy, либо с помощью интерпретатора правил, считывающих и интерпретирующих набор правил if – then
Фасадный объект для такой подсистемы можно назвать RuleEngineFacade
Фасадный объект для такой подсистемы можно назвать RuleEngineFacade
Слайд 75Пример обращения к объекту фасада
public class Sale
{ public void makeLineItem ( )
{
SalesLineItem
sli = new SalesLineItem (spec, quant);
// обращение к фасадному объекту
if (RuleEngineFacade.getInstance( ).isInvalid(sli, this))
return;
lineItems.add(sli);
}
// другие методы
}
// обращение к фасадному объекту
if (RuleEngineFacade.getInstance( ).isInvalid(sli, this))
return;
lineItems.add(sli);
}
// другие методы
}
