Введение в объектно-ориентированный дизайн с Java - страница 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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