Кирютенко Ю.А., Савельев В.А. Объектно-ориентированное программирование. Язык Smalltalk

Подождите немного. Документ загружается.

230 Глава 15. Особенности создания кода

getSideA или как-нибудь еще. Точно так же метод, который устанавливает

значение этой переменной, следует назвать sideA:, а не setSideA:.

Старайтесь создавать описательные имена методов, а не повелитель-

ные. Например, лучше использовать имя area (площадь), а не computeArea

(вычислитьПлощадь). В первом случае имя метода связывается с видом

возвращаемого методом значения (объекта). Это очень важно, например,

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

те следующие два выражения:

aTriangle area asSquareMetres.

aTriangle computeArea convertToSquareMetres.

Может быть, различия между ними кажутся достаточно тонкими, но

программистам на языке Смолток (и большинству непрограммистов) пер-

вое выражение намного понятнее, чем второе. Если вы хотите использовать

слова подобные compute и convert, лучше используйте причастие прошед-

шего времени: computedArea (вычисленнаяПлощадь), convertedToSquare-

Metres (преобразованноеВКвадратныеМетры).

При наименовании метода, который имеет несколько параметров, ст а-

райтесь создавать имя, которое передает и цель, и, если возможно, тип

каждого параметра. Например:

PaintBox drawLineFrom: x

to: y

usingPen: aPen

inColour: #red.

Обратите внимание, что в этом случае мы отказались от правила о со-

здании описательного имени метода и использовали drawLineFrom:to:using-

Pen:inColour: вместо имени lineFrom:to:usingPen:inColour:. Здесь мы боль-

ше заинтересованы в побочном эффекте, а не в возвращаемом значении.

И, наконец, при выборе имени метода думайте о той работе, которую

выполняет метод, а не о том способе, которым работа выполняется. Дру-

гими словами, называйте метод до, а не после его реализации. Поступая

так, вы избежите демонстрации способа реализации, который со временем

вполне может измениться, а цели, ради, которых создавался метод, оста-

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

метода, можно это сделать с помощью понятного суффикса (или приставки)

к основному имени (например, determinantRec).

Теперь обратимся к именам классов. Как и прежде, основная цель при

выборе имени должна состоять в сообщении цели существования данного

класса. Однако можно постараться сообщить и нечто об иерархии классов,

если вы считаете это до статочно важным. Например, OrderedCollection —

подкласс класса Collection. Вы могли бы продолжить иерархию, создавая

15.3. Доступ к переменным экземпляра 231

подкласс с именем, скажем, OptimizedOrderedCollection. Обязательное сле-

дование такому соглашению о наименовании не всегда необходимо или

желательно — все это вопрос вашего стиля и здравого смысла. Например,

класс Set — тоже подкласс класса Collection, но в данном случае слово

«Set» связывается с целью создания класса, и вряд ли здесь стоит еще что-

то изобретать.

Категории классов и протоколов существуют не во всех реализациях

языка. Но там, где они существуют, они вводятся только для того, чтобы

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

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

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

Имена категорий, используемые в иерархии классов в системе Visual-

Works, подобные accessing, updating, displaying и private, идеально впи-

сываются в предложенный стиль. Поддерживая высказанные соглашения

о наименованиях, используйте их. Однако мало только использовать такие

имена, надо еще использовать их правильно. Не помещайте, например, в

протокол accessing методов, отличных от методов, обеспечивающих до-

ступ к переменным экземпляра. Если метод частный и предназначен для

использования только разработчиками, помещайте его в категорию private.

Хорошее правило, которому стоит следовать, состоит в том, чтобы исполь-

зовать в качестве имени протокола причастие настоящего времени — слово,

которое заканчивается на «-ing». Например, calculating (методы для вычис-

лений) или printing (методы для печати).

15.3. Доступ к переменным экземпляра

Давайте посмотрим внимательно на то, как стоит обращаться к пере-

менным экземпляра. Если класс определяет или наследует переменную эк-

земпляра, то в методах, определенных в данном классе, к каждой такой

переменной можно обращаться просто по имени. Этот прием применяется

и для назначения значения переменной, и при использовании ее значения

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

имеет переменные экземпляра с именами area, width и height, допустимо

следующее выражение: area := width ∗ height.

Как правило, программист определяет еще и методы доступа, с помо-

щью которых любые другие объекты, в том числе и сам объект, могли

бы обращаться к переменным. Многие программисты рекомендуют, чтобы

объект даже к собственным переменным обращался не по имени, а сообще-

нием, посланным самому себе. Тогда приведенное выше выражение стало

бы таким: self area: self width ∗ self height.

232 Глава 15. Особенности создания кода

Если методы area:, width и height определены корректно, это выраже-

ние эквивалентно первому. Ради чего стоит так поступать? Ответ состоит в

следующем: избегая прямого доступа к переменным, мы тем самым потен-

циально увеличиваем гибкость и, как результат, расширяем возможности

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

ально представляют собой характеристики (или свойства) объекта. Точнее,

это такие свойства, значения которых хранятся в объекте и, как правило,

не вычисляются. Однако впоследствии может возникнуть ситуация, в ко-

торой значение свойства должно стать вычисляемым. Если предположить,

что к этой переменной экземпляра всегда обращались только посредством

метода, задача замены метода доступа на новый становится очень простой.

Достаточно только оставить то же самое имя метода, но изменить способ

вычисления значения переменной. Если же к переменной обращались по

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

новый метод, но и отследить каждую прямую ссылку на переменную и

заменить ее на сообщение, вызывающее новый метод.

Надеемся, преимущество методов доступа к переменным экземпляра

через сообщения не вызывает сомнений. Есть ли у него недостатки? Есть.

Наиболее очевидный — эффективность. Доступ к собственным перемен-

ным через сообщение обязательно медленнее, чем прямая ссылка на них.

Сообщение доступа ищет ту же самую ссылку на переменную, но теперь

еще тратится время на передачу сообщения. Доступ к переменным через

сообщения может оказаться еще и менее понятен пользователю (хотя это

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

па даже для «частных» переменных, то есть для таких переменных, об-

ращение к которым не предполагается извне экземпляров данного класса

(независимо от того, были ли они определены или унаследованы), может

выглядеть несколько неудобной. Но помните, что в системе Смолток ре-

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

сможет определить собственный метод до ступа или воспользоваться мето-

дом instVarAt:, определенным в классе Object.

Общей рекомендации о том, как программировать доступ к перемен-

ным, дать нельзя. Программист сам должен решить, что для него важнее:

эффективность при отсутствии гибкости или, наоборот, максимальная гиб-

кость с некоторой потерей эффективности. Необходим поиск компромисса:

на какие переменные стоит ссылаться непосредственно (и скрыть от поль-

зователя) , а для каких использовать методы доступа. Не забывайте, что в

случае многократного обращения к некоторой переменной нужное значе-

ние можно сохранить во временной переменной, а не использовать каждый

раз сообщение.

15.4. О структурировании методов 233

Перечисленные выше правила в равной степени применимы к перемен-

ным класса, глобальным переменным и константам. Если есть некоторая

фундаментальная константа, важная для создаваемого класса, стоит по-

местить такую константу в метод и всегда пользоваться только им, а не

вставлять такую константу непосредственно в методы. Например, число

π (отношение длины окружности к ее диамет ру) вычисляется с помощью

выражения Float pi, возвращающего число 3.14159265.

15.4. О структурировании методов

Одна из основных задач, которую приходится решать при создании ме-

тодов, состоит в необходимости написания небольших по объему методов.

Метод, содержащий более десяти строк кода, уже надо рассматривать как

большой. Надо стараться разбить текст длинного метода на два-три неболь-

ших. Наряду с использованием временных переменных для хранения ре-

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

чтения и понимания, изменения и повторного использования. Надо старать-

ся делать вспомогательные методы настолько универсальными, насколько

это возможно, а затем «составлять» из них функциональность, требуемую

в основном методе.

Старайтесь при записи метода надлежащим образом форматировать код,

отражая его логику. Продуманный формат текста метода делает код проще

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

скобки, если считаете, что это делает код более понятным.

Как мы знаем, методы автоматически возвращают получателя сообще-

ния (self), если в теле метода явно не предусмотрено ничего другого. Одна-

ко если возвращение методом объекта self — важная черта метода, можно

указать это явно, используя в качестве последнего выражения конструкцию

^ self. Это же полезно сделать и тогда, когда в процессе выполнения метода

достигается точка, в которой надо прекратить вычисления, и совершенно не

важно возвращаемое значение. Возвращение объектом значения self позво-

ляет посылать объектам цепочки сообщений. Не стоит возвращать особый

объект, скажем, nil, поскольку такой особый объект следующего посланного

сообщения почти наверняка не поймет.

Когда вы хотите использовать условное выражение (ifTrue:, ifFalse:,

и т.д.), подумайте о том, нельзя ли получить тот же самый эффект, струк-

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

результат поиска метода по иерархии (то есть постарайте сь использовать

полиморфизм). Особенно полезно поступать именно так, если перед при-

нятием решения «что делать?» приходится проверять, какому классу при-

234 Глава 15. Особенности создания кода

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

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

положение, можно проверить, поймет ли конкретный объект конкретное

сообщение, используя метод respondsTo:, определенный в классе Object.

Но доводить дело до этого не стоит.

15.5. Использование комментариев

Как и другие языки программирования, язык Смолток дает возможность

размещать в коде комментарии. Тщательно составленные комментарии зна-

чительно расширяют возможно сти пользователей в понимании кода (как,

впрочем, и возможности авторов кода через несколько недель, месяцев или

лет). Однако верно и обратное. Наличие непродуманных и неряшливых

комментариев хуже, чем отсутствие комментариев вообще.

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

ри текста методов (а некоторые и в классах). Комментарии могут встраи-

ваться в код метода, используя пару двойных кавычек (". . . "). Хорошим сти-

лем считается размещение комментария непосредственно в начале каждого

метода. Такой комментарий должен описывать назначение метода, парамет-

ры, которые он принимает (хотя это должно быть очевидно, если тщательно

подобраны имена метода и его параметров), какое значение возвращает ме-

тод и нечто специальное, если это нужно. При желании можно включить

сюда информацию об авторе и времени создания метода.

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

метода, поместить в него пример использования данного метода. Тогда лю-

бой человек, изучающий код, сможет с помощью мыши выбрать текст при-

мера и выполнить его, чтобы увидеть, как он работает.

Дополнительные комментарии внутри метода должны сообщать о том,

что и почему происходит, а не как это происходит. "Происходит увеличе-

ние индекса" — бесполезный комментарий для выражения index := index

+ inc. Фраза "Переход к следующему служащему" намного более инфор-

мативна, если объект имеет дело со служащими. Приложив минимальные

усилия, сам код на языке Смолток можно сделать понятным для читателя,

что сделает ненужным слишком объемный и тривиальный комментарий.

Если позволяет реализация, можно поместить комментарий и в каждый

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

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

пытаясь выяснить, что же делают классы системы, вы поймете, как будут

благодарны вам за подобные комментарии пользователи ваших классов!

15.6. На что еще стоит обратить внимание 235

15.6. На что еще стоит обратить внимание

Обратимся к правилам кодирования, основанным на здравом смысле.

Это означает, что приводимые далее советы, вообще говоря, полезны, но

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

кое-что другое и совсем не так.

1. Если мы имеем дело с логическими истиной и ложью, то надо поль-

зоваться только false и true, а не 0 и 1, или nil с некоторым объектом,

отличным от nil.

2. Если нужна переменная, которая принимает фиксированное число зна-

чений, постарайтесь закодировать такое значение, используя число или си-

стемное имя, а не строку (имена более эффективны, так как они уникальны

и могут сравниваться с помощью сообщения ==). Например, чтобы опи-

сать размер некоторого объекта, стоит использовать имена #large, #medium

и #small, а не числа, скажем, 3, 2 и 1. Посмотрите на следующие три вы-

ражения:

MyObject size = 3 ifTrue: [ . . . ].

MyObject size == #large ifTrue: [ . . . ].

MyObject isLarge ifTrue: [ . . . ].

Насколько проще понять то, что делает второе выражение, по сравне-

нию с тем, что делает первое. Третье выражение еще проще, в нем пред-

полагается, что написан метод с именем isLarge, который содержит в себе

выражение типа size == #large и возвращает true или false.

3. Один из наиболее полезных строительных блоков — словари. Мы уже ви-

дели, как они используются в качестве простой структуры данных, храня-

щей пары, организованные как «имя» и «значение». Словари могут содер-

жать любые объекты, что существенно расширяет возможности их приме-

нения. Например, словарь может использоваться как своеобразная управля-

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

варь позволяет сконструировать, если нужно, своего рода «оператор case».

Первое из приведенных ниже выражений показывает словарь, инициали-

зированный подобным образом (инициализация должна произойти только

один раз), а второе выражение показывает один из способов, которым такой

словарь можно было бы использовать:

MyDict at: #Small put: [ "do a small thing" ];

at: #Medium put: [ "do a medium thing" ];

at: #Large put: [ "do a large thing" ].

(MyDict at: case) value.

236 Глава 15. Особенности создания кода

4. Иногда бывает нужен только один объект с определенной структурой и

поведением. Например, нужен объект, работа которого состоит в управле-

нии некоторым уникальным ресурсом — файловой системой или таблицей

поиска. При таких обстоятельствах соблазнительно сделать такой объект

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

и написать методы класса, которые будут выполнять всю работу, особенно

если объект нуждается в ярком, уникальном, хорошо понимаемом имени.

Однако такой способ создания подобного объекта — не самый лучший.

Намного лучше — создать класс, и создать его единственный экземпляр, ко-

торый и будет реально работать. Основная причина такого решения состоит

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

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

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

функциональные возможности экземпляров, а не неподобающие ему функ-

циональные возможности классов. Не забывайте, что наследование только

нужных функциональных возможностей — один из тех принципов, которо-

му надо неукоснительно следовать при проектировании классов.

В подобной ситуации один из практических способов решения со стоит

в том, чтобы создать класс и определить в нем переменную класса с име-

нем Default (ЗначениеПоУмолчанию). Затем создать метод класса с именем

initialize, который инициализирует эту переменную так, чтобы она содер-

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

остается создать метод класса с именем default, который будет возвращать

значение переменной Default. После этого, когда в какой-то части кода надо

использовать этот объект, достаточно вычислить выражение MyClassName

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

такого класса, не возникнет никаких проблем.

5. Стоит обратить внимание на отношение к коду, расположенному в иерар-

хии классов. Предоставление любой системой Смолток почти полного ис-

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

очень мощное средство, и подобно всем таким средствам, к нему следует

относиться с осторожностью. Абсолютно не верен постулат, что нельзя из-

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

циональные возможности, это нужно делать. Такой вид изменений делает

среду разработки более мощной, чем она есть.

Совсем другое дело, если планируются изменения в наиболее фунда-

ментальных классах, типа классов Object или Behavior. В этом случае надо

быть чрезвычайно осмотрительным. На этом пути есть две опасности. Во-

первых, можно разрушить систему, и, во-вторых, можно произвести в ней

изменения, несовместимые с изменениями, проведенными кем-то еще.

15.6. На что еще стоит обратить внимание 237

Прежде чем предпринимать подобное, подумайте, нельзя ли достичь

того же эффекта без изменения системных классов; как предполагаемые

изменения будут взаимодействовать с уже произведенными; как измене-

ния отразятся на фундаментальном поведении системы. Если, принимая

все это во внимание, вы отважитесь на изменения, предпримите все меры

предосторожности. Начните работу с создания подкласса, и только после

проверки перенесите изменения в системный класс.

6. В классе Object есть два мощных метода — perform: и become:, к кото-

рым надо относиться особенно внимательно. Изучая класс Object, мы уже

рассматривали, как можно использовать метод perform:. Но помните: все

последствия его применения очень трудно отследить.

Метод become: меняет значение объекта, получившего такое сообще-

ние. В основном он используется в операциях изменения размеров набо-

ров, переустанавливая каждую ссылку со старой версии набора на новую.

Однако эта операция имеет в разных реализациях разную семантику. На-

пример, в Smalltalk-80 выражение x become: y вызывает все ссылки на x и

y и обменивает их, а в Smalltalk Express не изменяет ссылок на объект y.

Если надо устранить все ссылки на объект x, выражение x become: nil

прекрасно сработает в Smalltalk Express, а в VisualWorks еще вызовет каж-

дую ссылку на nil и переставит ее на x. Это равносильно катастрофе! Если

все же надо устранить все ссылки на объект x, безопаснее выполнить выра-

жение x become: String new. Так что перед использованием таких методов

стоит тщательно продумать все возможные последствия.

7. Как и во всех других языках программирования, эффективность напи-

санного на языке Смолток кода варьируется достаточно широко. Говоря об

«эффективности», мы предполагаем, что выбран правильный (наилучший)

алгоритм

, который выполняется быстро и/или использует меньший объем

памяти.

Есть несколько правил, которые, если их придерживаться, позволяют

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

универсальны и относятся не только к языку Смолток.

Надо избегать некоторых операций, особенно тех, которые всегда яв-

ляются неэффективными, независимо от того, какой язык программирова-

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

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

(Lazy evaluation) — таково имя методики, которая откладывает вычисление

Все вроде бы просто и понятно. Но задайте себе вопрос: «Стоит ли пожерт-

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

эффективности?»

238 Глава 15. Особенности создания кода

некоторого значения до тех пор, пока оно фактически не потребуется. Од-

нако если некоторое значение уже вычислили, не стоит выбрасывать его,

если оно может снова потребоваться. Например, надо избегать многократ-

ного вычисления одного и того же значения внутри цикла, перемещая такие

вычисления за цикл.

Есть некоторые операции, которые, как хорошо известно, являются в

языке Смолток неэффективными. Класс Dictionary медленнее, чем класс

IdentityDictionary, поскольку использует сообщение = вместо более быст-

рого сообщения ==. То же справедливо и для классов Set и IdentitySet.

Механизм зависимости является более медленным способом связи меж-

ду объектами, чем прямые ссылки. Таким образом, если быстродействие

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

преимуществами механизма зависимости.

Распределение памяти всегда происходит медленно, так что не следу-

ет создавать по несколько раз большие объекты и тут же их отбрасывать.

Помните, что метод perform: может оказаться относительно медленным, а

метод become: крайне расточительным в отношении ре сурсов.

Если возникают сомнения в эффективности созданного кода, стоит про-

вести его полное исследование с помощью инструментов тестирования,

хронометрирования и профилирования (их имеет каждая реализация). Они

помогут выявить «узкие места». Если таких инструментов нет, то не за-

бывайте, что время выполнения почти любого метода можно определить с

помощью выражения Time millisecondsToRun: aBlock.

ЧАСТЬ IV

ПОСТРОЕНИЕ ПРИЛОЖЕНИЙ

Не для того я живу, чтобы есть,

а ем для того, чтобы жить.

Квинтилиан Марк Фабий

ГЛАВА 16

ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ

Среди рассмотренных нами классов системы Smalltalk Express еще не

было классов, обеспечивающих построение интерфейса пользователя и со-

ставляющих одну из самых многочисленных и сложных частей иерархии

классов. С сожалением надо отметить, что эти классы, как и классы, свя-

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

приложения с интерфейсом пользователя не переносимы между ними. Та-

кое положение сложилось в ходе развития смолтоковских систем. В 70–80-е

годы, еще до широкого распространения доступных графических операци-

онных систем, в первой смолтоковской системе — системе Smalltalk-80 — в

основе классов, обеспечивающих построение интерфейса пользователя, ле-

жала триада «Модель — Вид — Контроллер» («Model — View — Controller»,

сокращенно MVC) [5], [13]. Позже в системе Smalltalk/V for DOS подход к

построению интерфейса был несколько изменен, и, во избежание путани-

цы, соответствующая триада была переименована в «Модель — Панель —

Диспетчер» («Model — Pane — Dispatcher» — MPD). И хотя вид и панель,

контроллер и диспетчер — почти синонимы, набор классов пользователь-

ского интерфейса в этих средах различается.

Когда на персональных компьютерах получили распространение окон-

ные операционные системы, разработчики смолтоковских систем должны

были найти способы приспособиться к ним. Каждая среда по строения ин-

терфейса должна определить структуру окна просмотра, соответствующую

операционной системе, и добиться его полного взаимодействия с отобра-