Глава 5

3Амена констрvкций на языке с

Между языками программирования С и Java много общего, однако в Java отсут­ствует несколько конструкций языка с. В большинстве случаев совершенно очевидно, почему та или иная конструкция языка С опущена и как без нее обойтись. В этой главе предлагается замена для ряда конструкций языка С, альтернатива которым не столь очевидна.

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

Даже если вы решите пропустить эту главу, все же прочтите статью 21, в которой обсуждается шаблон перечисления, который заменяет конструкцию еnиm из языка С. Во время написания этой книги данный шаблон был мало известен, однако он имеет ряд преимуществ перед другими, широко используемыми сегодня методами.

3Аменяйте структуру классом

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

92

encapsulate) свои данные в объекте, доступ к которому осуществляется только через его методы. Тем самым у разработчика появляется возможность менять внутреннее представление объекта (статья 12).

После первого знакомства с языком Java некоторые программисты, ранее пользо­вавшиеся языком С, приходят к заключению, что в некоторых случаях класс слишком тяжеловесен, чтобы заменить структуру, однако это не так. Вырожденный класс, состоящий исключительно из полей данных, примерно равнозначен структуре из языка С:

// Вырожденные классы, подобные этому,

// не должны быть открытыми!

class Point {

public float х;

public float у;

}

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

// Класс с инкапсулированной структурой

class Point {

private float х;

private float у;

public Point(float х, float у) {

this. х = х;

this.y = у;

}

public float getX() { return х; }

public float getY() { return у; }

public void setX(float х) { this.x = х; }

public void setY(float у) { this.y = у; }

}

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

93

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

Несколько классов в библиотеках для платформы Java нарушают совет, касающий­ся запрещения непосредственного доступа к полям открытого класса. В частности, это классы Point и Dimension из пакета java.awt. Не следует подражать этим классам, лучше рассматривать их как предупреждение. В статье 37 показано, как раскрытие внутреннего содержания класса Dimension привело к серьезным проблемам с произ­водительностью, которые нельзя было разрешить, не затрагивая клиентов.