О некоторых вопросах методологии объектно-ориентированного программирования

Размещено на http://www.allbest.ru/

О некоторых вопросах методологии объектно-ориентированного программирования

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

Объектно-ориентированная методология применима к широкому спектру объектных и объектно-ориентированных языков и не ограничена каким-либо одним языком программирования. Наряду с анализом и проектированием, несомненно важны особенности конкретного языка программирования. Как отметил Страуструп, язык программирования служит трем целям:

это инструмент проектирования;

это средство человеческого восприятия;

это средство управления компьютером [1].

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

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

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

Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, сохраняемость. Эти принципы не новы, но в объектной модели они впервые применены в совокупности.

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

Понятие «объект» впервые было использовано более 20 лет назад при конструировании компьютеров с descriptor-based и capability-based архитектурами [2]. В этих работах делались попытки отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программной абстракции и низким уровнем ЭВМ. Были созданы более качественные средства, обеспечивающие:

лучшее выявление ошибок;

большую эффективность реализации программ;

сокращение набора инструкций;

упрощение компиляции;

снижение объема требуемой памяти.

Объектно-ориентированное программирование (ООР) - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования. В данном определении можно выделить три части:

OOP использует в качестве базовых элементов объекты, а не алгоритмы;

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

классы организованы иерархически.

Программа будет объектно-ориентированной только при соблюдении всех трех указанных требований. Программирование, не основанное на иерархических отношениях, не относится к OOP, а называется программированием на основе абстрактных типов данных.

Страуструп определил так: «если термин объектно-ориентированный язык вообще что-либо означает, то он должен означать язык, имеющий средства хорошей поддержки объектно-ориентированного стиля программирования... Обеспечение такого стиля в свою очередь означает, что в языке удобно пользоваться этим стилем. Если написание программ в стиле OOP требует специальных усилий или оно невозможно совсем, то этот язык не отвечает требованиям OOP» [1]. В соответствии с этим не все языки программирования являются объектно-ориентированными. Теоретически возможна имитация объектно-ориентированного программирования на обычных языках, таких, как Pascal или Ассемблер, но это крайне затруднительно.

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

С точки зрения восприятия человеком объектом может быть [3]:

осязаемый и видимый предмет;

нечто, воспринимаемое мышлением;

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

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

Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств.

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

Предположим, что на языке C++ нам нужно создать регистрационные записи о сотрудниках. Можно сделать это следующим образом:

struct PersonnelRecord {

char name[100];

int socialSecurityNumber; char department[10];

float salary;

};

Каждый компонент в приведенной структуре обозначает конкретное свойство абстракции регистрационной записи. Описание определяет не объект, а класс, поскольку оно не вводит какой-либо конкретный экземпляр. Это описание определяет структуру в C++, семантика которой соответствует классу, у которого все поля открыты. Таким образом, структуры - это неинкапсулированные абстракции. Для того чтобы создать объекты данного класса, необходимо написать следующее:

PersonnelRecord deb, dave, karen, jim, torn, denise, kaitlyn, krista, elyse;

В данном случае объявлено девять различных объектов, каждый из которых занимает определенный участок в памяти. Хотя свойства этих объектов являются общими (их состояние представляется единообразно), в памяти объекты не пересекаются и занимают каждый свое место. На практике принято ограничивать доступ к состоянию объекта, а не делать его общедоступным, как в предыдущем определении класса. С учетом сказанного, изменим данное определение следующим образом:

class PersonnelRecord { public:

char* employeeName() const;

int employeeSocialSecurityNumber() const; char* employeeDepartment() const;

protected:

char name[100];

int socialSecurityNumber; char department[10];

float salary;

};

Новое определение несколько сложнее предыдущего, но по ряду соображений предпочтительнее. Предложенное определение класса PersonnelRecord - это не лучший пример. Здесь только показана семантика состояния класса. Иметь в классе функцию, которая возвращает значение char*, часто опасно, так как это нарушает парадигму защиты памяти. Если метод отводит себе память, за которую получивший к ней доступ клиент не отвечает, результатом будет замусоривание памяти. В системах предпочтительнее использовать параметризованный класс строк переменной длины, который можно найти в базовой библиотеке классов. Классы - это больше чем структуры из C++. В частности, в новом определении реализация класса скрыта от других объектов. Если реализация класса будет в дальнейшем изменена, код придется перекомпилировать, но семантически клиенты не будут зависеть от этих изменении (то есть их код сохранится). Кроме того, решается также проблема занимаемой объектом памяти за счет явного определения операций, которые разрешены клиентам над объектами данного класса. У всех клиентов этой системы есть право узнать имя, код социальной защиты и место работы сотрудника. Но только особым клиентам (а именно, подклассам данного класса) разрешено устанавливать значения указанных параметров. Только этим специальным клиентам разрешен доступ к сведениям о заработной плате. Достоинством данного определения является возможность его повторного использования.

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

Литература

Страуструп Б. Язык программирования С++, специальное издание / Перевод с англ. - М.; СПб.: Издательство БИНОМ, 2001. - 1099 с.

Кристиан Нейгел, Билл Ивьен, С#4 и платформа. NET для профессионалов. - Москва, Санкт- Петербург, Киев: Диалектика, 2011. - 1435 с.

Карли Уотсон, КVisual C# 2010. Полный курс. - Москва: Вильямс, 2010. - 985 с.

Размещено на Allbest.ru