Программирование. Принципы и практика использования C++ Исправленное издание - Бьёрн Страуструп

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

 

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

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

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

 

 Мы решили использовать небольшие классы, содержащие несколько операций. Например, мы создали классы Open_polyline, Closed_polyline, Polygon, Rectangle, Marked_polyline, Marks и Mark вместо отдельного класса (который можно было бы назвать Polyline). В этих классах предусмотрено множество аргументов и операций, позволяющих задавать вид ломаной и даже изменять ее. Доводя эту идею до предела, можно было бы создать отдельные классы для каждой фигуры в качестве составных частей единого класса Shape. Мы считаем, что использование небольших классов наиболее точно и удобно моделирует нашу область графических приложений. Отдельный класс, содержащий “все”, завалил бы пользователя данными и возможностями, затруднив понимание, усложнив отладку и снизив производительность.

14.1.2. Операции

 

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

 

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

Line ln(Point(100,200),Point(300,400));

Mark m(Point(100,200),'x'); // отображает отдельную точку

                            // в виде буквы "x"

Circle c(Point(200,200),250);

Все функции, работающие с точками, используют класс Point. Это очевидно, но многие библиотеки смешивают стили. Например, представим себе функцию, рисующую линию. Мы можем использовать два стиля.

void draw_line(Point p1,Point p2); // от p1 до p2 (наш стиль)

void draw_line(int x1,int y1,int x2,int y2); // от (x1,y1)

                                             // до (x2,y2)

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

draw_rectangle(Point(100,200),300,400); // наш стиль

draw_rectangle (100,200,300,400);       // альтернатива

При первом вызове функция рисует прямоугольник по заданной точке, ширине и высоте. Это легко угадать. А что можно сказать о втором вызове? Имеется в виду прямоугольник, определенный точками (100,200) и (300,400)? Или прямоугольник, определенный точкой (100,200), шириной 300 и высотой 400? А может быть, программист имел в виду нечто совершенно другое (хотя и разумное)? Последовательно используя класс Point, мы можем избежать таких недоразумений.

Иногда, когда функция требует ширину и высоту, они передаются ей именно в таком порядке (как, например, координату x всегда указывают до координаты y). Последовательное соблюдение таких условностей удивительно облегчает работу с программой и позволяет избежать ошибок во время ее выполнения.

Логически идентичные операции называются одинаково. Например, каждая функция, которая добавляет точки, линии и так далее к любой фигуре, называется add(), а любая функция, рисующая линии, называется draw_lines(). Такое единообразие позволяет нам помнить (или вспомнить по некоторым признакам), что делает функция, и облегчает разработку новых классов (по аналогии). Иногда это позволяет даже написать код, работающий с разными типами, поскольку операции над этими типами имеют общий шаблон.

Такие коды называют обобщенными (generic); подробно мы рассмотрим их в главах 19–21. 

14.1.3. Именование

 Логически разные операции имеют разные имена. И опять-таки, несмотря на то, что это очевидно, существуют вопросы: почему мы связываем объект класса Shape с объектом класса Window, но добавляем объект класса Line к объекту класса Shape? В обоих случаях мы “помещаем нечто во что-то”, так почему бы не назвать такие операции одинаково? Нет. За этой схожестью кроется фундаментальная разница. Рассмотрим пример.

Open_polyline opl;

opl.add(Point(100,100));

opl.add(Point(150,200));

opl.add(Point(250,250));

Здесь мы копируем три точки в объект opl. Фигуре opl безразлично, что будет с нашими точками после вызова функции add(); она хранит свои собственные копии этих точек. На самом деле мы редко храним копии точек, а просто передаем их фигуре. С другой стороны, посмотрим на следующую инструкцию:

win.attach(opl);

Здесь мы создаем связь между окном win и нашей фигурой opl; объект win не создает копию объекта opl, а вместо этого хранит ссылку на него. Итак, мы должны обеспечить корректность объекта opl, поскольку объект win использует его. Иначе говоря, когда окно win использует фигуру opl, оно должно находиться в ее области видимости. Мы можем обновить объект opl, и в следующий раз объект win будет рисовать фигуру opl с изменениями. Разницу между функциями attach() и add() можно изобразить графически.

Функция add() использует механизм передачи параметров по значению (копии), а функция attach() — механизм передачи параметров по ссылке (использует общий объект). Мы могли бы решить копировать графические объекты в объекты класса Window. Однако это была бы совсем другая модель программирования, которая определяется выбором