Реализация с помощью объектно-ориентированных технологий

Теперь рассмотрим случай использования объектно-ориентированных технологий. Перед нами стоит сначала все та же задача: разработать подсистему графического вывода изображений, состоящих из прямоугольников и треугольников. Какова будет структура нашей системы? Рассмотрение начнем с реализации собственно примитивов. Теперь вместо структур, содержащих их описания (атрибуты), у нас будут классы, которые помимо собственно атрибутов (длина, высота и т. п.) будут содержать и некоторые методы (рис. 4, а). Хотя в реальных системах будет множество различных методов (включая возможность сохранения / восстановления, дублирования и т. п.), нас будут интересовать только методы, выводящие эти примитивы на экран монитора. Сразу можно заметить, что и прямоугольники, и треугольники: 1) являются геометрическими фигурами и 2) оба они будут обладать способностью отображать себя на экране. Следовательно, целесообразно ввести базовый класс геометрических фигур, в котором будет объявлен метод «Отобразить», являющийся общим для обоих примитивов. Так как не существует геометрической фигуры вообще, а существуют лишь конкретные прямоугольники, треугольники и т. д., то и класс геометрических фигур будет абстрактным, т. е., от него не может быть непосредственно порождено объектов. Этот класс нужен для того, чтобы стать основой для классов-потомков, являющихся классами конкретных фигур. От этого класса они унаследуют атрибуты (например название фигуры)* и методы. Другим назначением класса фигур будет предоставление единого интерфейса для классов-потомков. В самом деле, метод «Отобразить», который в базовом классе лишь объявлен и является виртуальным, посредством полиморфизма будет замещен в классах-потомках и будет иметь конкретную реализацию: для класса прямоугольников - выводить на экран прямоугольник, для класса треугольников - треугольник. Но и тот, и другой методы будут иметь одно и тоже имя - «Отобразить», а выполняться будет совершенно по-разному.

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

Рис. 4. Вывод графики в случае использования

Объектно-ориентированных технологий

Итак, мы знаем, что объекты классов примитивов имеют одноименный метод «Отобразить», позволяющий отобразить каждый из них правильным образом: прямоугольники прямоугольниками, а треугольники - треугольниками. Теперь требуется ответить на вопрос, можно ли всех их хранить в одном массиве (или каком-либо другом контейнере, например в связанном списке). Оказывается, что можно. В самом деле, даже если мы используем язык со строгой типизацией, когда в том или ином массиве можно хранить объекты лишь определенного класса, нам можно не создавать два массива для прямоугольников и треугольников в отдельности. И прямоугольники, и треугольники являются потомками одного родительского класса - класса геометрических фигур. Следовательно, создав массив геометрических фигур, мы можем хранить в нем прямоугольники и треугольники, выполнив требуемые приведения типов (типы прямоугольников и треугольников приводятся к типу геометрических фигур), что обычно допускается в языках, поддерживающий парадигму ООП. Кроме того, мы можем хранить в таком массиве любые другие объекты, являющиеся экземплярами классов-потомков класса геометрических фигур, что, как мы вскоре увидим, открывает нам очень простой и безопасный путь расширения функциональности.

Итак, мы имеет классы двух примитивов, их родительский класс и массив объектов класса геометрических фигур. Теперь мы можем заполнить его объектами наших примитивов, предварительно осуществив соответствующее приведение типов. А так как все объекты наших классов имеют метод «Отобразить», который также имеется и у родительского класса, который предоставляет единый интерфейс, то посредством полиморфизма объекты, использующие функциональность этих классов, могут не беспокоиться по поводу того, к объекту какого класса они обращаются. Им надо просто вызвать соответствующий метод, после чего будет выполнено требуемое действие.

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

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: