Тимур Машнин - Введение в объектно-ориентированный дизайн с Java

Вы обнаружите объекты управления при попытке деления большого объекта и обнаружите, что было бы полезно иметь объект, который управляет другими объектами.

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

Для программного обеспечения существуют два типа требований.

Это функциональные требования, которые описывают, что система или приложение должны делать.

Например, мультимедийное приложение имеет функциональное требование о возможности загрузки полноразмерного фильма.

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

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

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

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

И для решения важны как функциональные, так и нефункциональные требования.

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

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

Кроме того, реализация может потребовать изменения в будущем.

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

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

Кроме того, некоторые качества могут быть проверены с помощью обратной связью конечных пользователей.

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

В частности, существует общий компромисс между производительностью и ремонтопригодностью.

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

Другим компромиссом является безопасность и производительность.

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

При планировании какого-либо выступления часто используются карточки заметок.

Карточки заметок помогают вам двигаться логически из одной точки разговора в другую.

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

Вы определяете компоненты, соединения и обязанности по некоторым требованиям при формировании концептуального дизайна. Здесь вы формируете свои первоначальные мысли о том, как вы можете удовлетворить требования.

В техническом дизайне эти компоненты и соединения дополнительно уточняются, чтобы придать им технические детали. Это упрощает их реализацию.

Хотя идентификация компонентов, их обязанностей и связей является хорошим первым шагом в разработке программного обеспечения, мы пока не продемонстрировали способ их представления.

И такой метод есть – это использование карточек CRC, где CRC обозначает класс, ответственность, сотрудничество.

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

Рассмотрим, например, банкомат.

Вы вставляете свою банковскую карточку в банкомат, и банкомат просит вас ввести PIN-код, удостоверяющий личность для доступа.

После этого вы можете выбрать положить или снять деньги, или проверить свои остатки.

Этот сценарий определяет основные требования к системе.

Это неполный набор требований, но это хороший старт.

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

Следующим шагом будет разработка банкомата.

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

И карты CRC используются для записи, упорядочивания и улучшения компонентов в дизайне.

Карта CRC состоит из трех разделов.

В верхней части карты есть имя класса.

Слева – обязанности класса, а справа – список коллабораторов.

Коллабораторы – это другие классы, с которыми класс взаимодействует, чтобы выполнять свои обязанности.

Чтобы отслеживать каждый компонент и его обязанности с помощью CRC-карты, вы помещаете имя компонента в раздел имени класса и обязанности в разделе обязанностей.

До сих пор это довольно просто.

Но как насчет связей?

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

И карты CRC сами по себе небольшие, поэтому вы не можете много писать в них.

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

Теперь, когда мы узнали о CRC-картах, давайте использовать их для разработки нашей банковской системы.

Начнем с базового пользовательского компонента.

В этом примере нашим основным пользователем будет клиент банка.

Мы размещаем клиентов банка в разделе имени класса.

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

Перечислим их в разделе ответственности CRC-карты.

И мы поместим банкомат в разделе Коллабораторы.

Тоже самое мы можем сделать для банкомата.

И с нашими картами CRC мы можем объединить вместе компоненты для совместной работы.

Например, положите карту клиента CRC слева и карточку CRC банкомата справа.

Когда карты CRC организованы, вы можете имитировать прототип системы.

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