CHAP8_1 (1018808), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

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

110. Никогда не допускайте открытого доступа к закрытым данным.

Все данные в определении класса должны быть закрытыми. Точка. Никаких исключений. Проблема здесь заключается в тесном сцеплении между классом и его пользователями, если они имеют прямой доступ к полям данных. Я приведу вам несколько примеров. Скажем, у вас есть класс string, который использует массив типа char для хранения своих данных. Спустя год к вам обращается заказчик из Пакистана, поэтому вам нужно перевести все свои строки на урду, что вынуждает перейти на Unicode. Если ваш строковый класс позволяет какой-либо доступ к локальному буферу char*, или сделав это поле открытым (public), или определив функцию, возвращающую char*, то вы в большой беде.

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

class string

{

public:

char *buf;

// ...

};

f()

{

string s;

// ...

printf("%s/n", s.buf );

}

Если вы попробуете изменить определение buf на wchar_t * для работы с Unicode (что предписывается ANSI С), то все функции, которые имели прямой доступ к полю buf, перестают работать. И вы будете должны их все переписывать.

Другие родственные проблемы проявляются во внутренней согласованности. Если строковый объект содержит поле length, то вы могли бы модифицировать буфер без модификации length, тем самым разрушив эту строку. Аналогично, деструктор строки мог бы предположить, что, так как конструктор разместил этот буфер посредством new, то будет безопаснее передать указатель на buf оператору delete. Однако если у вас прямой доступ, то вы могли бы сделать что-нибудь типа:

string s;

char array[128];

s.buf = array;

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

Простое закрытие при помощи модификатора private поля buf не помогает, если вы продолжаете обеспечивать доступ посредством функции. Листинг 7 показывает фрагмент простого определения строки, которое будет использоваться мной несколько раз в оставшейся части этой главы. (Упрощение, сделанное мной, свелось к помещению всего в один листинг; обычно определение класса и встроенные функции будут в заголовочном файле, а остальной код в файле .cpp).

Вы заметите, что я умышленно не реализовал следующую функцию в листинге 7:

string::operator const char*() { return buf; }

Если бы реализовал, то мог бы сделать следующее:

Листинг 7. Простой строковый класс.

1. class string

2. {

3. char *buf;

4. int length; // длина буфера (не строки);

6. public:

7. virtual

8. ~string( void );

9. string( const char *input_str = "" );

10. string( const string &r );

12. virtual const string &operator=( const string &r );

14. virtual int operator< ( const string &r ) const;

15. virtual int operator> ( const string &r ) const;

16. virtual int operator==( const string &r ) const;

18. virtual void print( ostream &output ) const;

19. // ...

20. };

21. //--------------------------------------------------------------------------------------------------------------------

22. inline string::string( const char *input_str /*= ""*/ )

23. {

24. length = strlen(input_str) + 1;

25. buf = new char[ length ];

26. strcpy( buf, input_str );

27. }

28. //--------------------------------------------------------------------------------------------------------------------

29. inline string::string( const string &r )

30. {

31. length = r.length;

32. buf = new char[ length ];

33. strcpy( buf, r.buf );

34. }

35. //--------------------------------------------------------------------------------------------------------------------

36. /* виртуальный */ ~string::string( void )

37. {

38. delete buf;

39. }

40. //--------------------------------------------------------------------------------------------------------------------

41. /* виртуальный */ const string &string::operator=( const string &r )

42. {

43. if( this != &r )

44. {

45. if( length != r.length )

46. {

47. free( buf );

48. length = r.length;

49. buf = new char[ length ];

50. }

51. strcpy( buf, r.buf );

52. }

53. return *this;

54. }

56. //--------------------------------------------------------------------------------------------------------------------

57. /* виртуальный */ int string::operator< ( const string &r ) const

58. {

59. return strcmp(buf, r.buf) < 0;

60. }

61. //--------------------------------------------------------------------------------------------------------------------

62. /* виртуальный */ int string::operator> ( const string &r ) const

63. {

64. return strcmp(buf, r.buf) > 0;

65. }

66. //--------------------------------------------------------------------------------------------------------------------

67. /* виртуальный */ int string::operator==( const string &r ) const

68. {

69. return strcmp(buf, r.buf) == 0;

70. }

71. //--------------------------------------------------------------------------------------------------------------------

72. /* виртуальный */ void string::print( ostream &output ) const

73. {

74. cout << buf;

75. }

76. //--------------------------------------------------------------------------------------------------------------------

77. inline ostream &operator<<( ostream &output, const string &s )

78. {

79. // Эта функция не является функцией-членом класса string,

80. // но не должна быть дружественной, потому что мной тут

81. // реализован метод вывода строкой своего значения.

83. s.print(output);

84. return output;

85. }

void f( void )

{

string s;

// ...

printf("%s/n", (const char*)s );

}

но я не cмогу реализовать функцию operator char*(), которая бы работала со строкой Unicode, использующей для символа 16-бит. Я должен бы был написать функцию operator wchar_t*(), тем самым модифицировав код в функции f():

printf("%s/n", (const wchar_t*)s );

Тем не менее, одним из главных случаев, которых я стараюсь избежать при помощи объектно-ориентированного подхода, является необходимость модификации пользователя объекта при изменении внутреннего определения этого объекта, поэтому преобразование в char* неприемлемо.

Также есть проблемы со стороны внутренней согласованности. Имея указатель на buf, возвращенный функцией operator const char*(), вы все же можете модифицировать строку при помощи указателя и испортить поле length, хотя для этого вам придется немного постараться:

string s;

// ...

char *p = (char *)(const char *)s;

gets( p );

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

const char *g( void )

{

string s;

// ...

return (const char *)s;

}

Операция приведения вызывает функцию operator const char*(), возвращающую buf. Тем не менее, деструктор класса string передает этот буфер оператору delete, когда строка покидает область действия. Следовательно, функция g() возвращает указатель на освобожденную память. В отличие от предыдущего примера, при этой второй проблеме нет закрученного оператора приведения в два этапа, намекающего нам, что что-то не так.

Реализация в листинге 7 исправляет это, заменив преобразование char* на обработчиков сообщений типа метода самовывода (print()). Я бы вывел строку при помощи:

string s;

s.print( cout )

или:

cout << s;

а не используя printf(). При этом совсем нет открытого доступа к внутреннему буферу. Функции окружения могут меньше беспокоиться о том, как хранятся символы, до тех пор, пока строковый объект правильно отвечает на сообщение о самовыводе. Вы можете менять свойства представления строки как хотите, не влияя на отправителя сообщения print(). Например, строковый объект мог бы содержать два буфера - один для строк Unicode и другой для строк char* - и обеспечивать перевод одной строки в другую. Вы могли бы даже добавить для перевода на французский язык сообщение translate_to_French() и получить многоязыкую строку. Такая степень изоляции и является целью объектно-ориентированного программирования, но вы ее не добьетесь, если не будете непреклонно следовать этим правилам. Здесь нет места ковбоям от программирования.

110.1. Не пользуйтесь функциями типа get/set (чтения и присваивания значений).

Это правило в действительности то же, что и предыдущее "все данные должны быть закрытыми". Я выделил его, потому что есть такая распространенная ошибка среди начинающих программистов на С++. Нет разницы между:

struct xxx

{

int x;

};

и:

class xxx {

private:

int x;

public

void setx ( int ix ){ x = ix; }

int getx ( void ) { return x; }

}

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

Сообщение реализует свойство. Открытая (public) функция реализует обработчик сообщения. Поля данных - лишние во внешнем мире; вы добавляете их лишь для того, чтобы иметь возможность реализовать свойство. Доступ к ним должен быть невозможен.

Заметьте, что вы будете изредка видеть обработчик сообщений, который ничего не делает, кроме возврата содержимого поля или помещает в поле значение, переданное в виде аргумента. Этот обработчик тем не менее не является функцией типа get/set. Вопрос в том, как возникает такая ситуация. Нет абсолютно ничего плохого в том, если вы начинаете с ряда сообщений и затем решаете, что самым простым способом реализации сообщения является помещение специального поля в определение класса. Другими словами, этот обработчик сообщений не является усложненным способом доступа к полю; скорее, это поле является простым способом реализовать сообщение. Хотя вы попали в то же место, вы попали туда совершенно другим путем.

Конечно, эта организация означает, что С++ не может быть эффективно использован в гибридной среде С/С++, потому что интерфейс между двумя половинами программы уничтожает инкапсуляцию, которой вы так сильно старались добиться. В известном смысле жаль, что С++ создан на основе С, потому что это просто подстрекает нас к ошибкам.

Закончу этот раздел более реальным примером. Как то раз я видел интерфейс, в котором объект "календарь" позволял пользователю интерактивно выбирать дату, щелкая мышью на каком-либо из дней, показанных на изображении календаря. "Календарь" затем экспортирует эту дату в другие части программы, помещая ее в объект "дата", который возвращается из сообщения get_date(). Проблема здесь в том, что проектирование выполнено выполнено наизнанку. Программист мыслил структурными категориями, а не объектно-ориентированными.

При выполнении должным образом единственным видимым в других частях программы объектом был бы объект "дата". "Дата" использовала бы объект "календарь" для реализации сообщения инициализируй_себя (которое могло бы быть конструктором), но "календарь" бы содержался внутри "даты". Определение класса "календарь" можно было бы даже вложить в определение класса "дата". Объект "дата" также мог бы поддерживать другие инициализирующие сообщения, такие как инициализируй_себя_от_редактируемого_ввода или инициализируй_себя_из_строки, но во всех случаях объект "дата" отвечает за нужное для инициализации взаимодействие с пользовательским интерфейсом. Остальная часть программы просто бы непосредственно использовала "дату"; никто, кроме "даты", даже бы не знал о существовании объекта "календарь". То есть вы бы объявили "дату" и приказали ей себя инициализировать. Затем вы можете передавать объект "дата" всюду, куда необходимо. Конечно, "дата" должна также уметь себя вывести, переслать в файл или из файла, сравнить себя с другими датами и так далее.

111. Откажитесь от выражений языка С, когда программируете на С++.

Характеристики

Список файлов книги