Понятие об объектно-ориентированном программировании. Понятие класса и его структура

Введение

Объектно-ориентированное программирование (далее ООП) впервые было реализовано в Smalltalk-80 и приобрело популярность во второй половине 80-х вместе с такими языками, как С++, Objectiv C, Object Pascal и Turbo Pascal, CLOS (объектно-ориентированное расширение Lisp'a), Eiffel, Ada (в её последних воплощениях) и недавно – в Java.
Как показала практика, традиционные методы процедурного программирования не способны справиться ни с нарастающей сложностью программ и их разработки, ни с необходимостью повышения их надежности. Во второй половине 80-х годов возникла настоятельная потребность в новой методологии программирования, которая была бы способна решить весь этот комплекс проблем. Ею стало объектно-ориентированное программирование. В настоящее время ООП используется во многих языках прикладного программирования.
Данная работа состоит из двух разделов:
– в первой части рассмотрено понятие об ООП, описаны основные идеи и принципы;
– во второй части описано понятие класса и его структуры, приведены примеры структуры класса, как создается класс и где он применяется.
Актуальность данной работы заключается в том, что ООП является основой индустрии информационных технологий, также объектно-ориентированные языки программирования позволяют использовать преимущества ООП на этапах проектирования, конструирования, реализации, тестирования и сопровождения.
1 Понятие об объектно-ориентированном программировании. Основные принципы и идеи ООП
Увеличение размеров программ приводило к необходимости привлечения большего числа программистов, что, в свою очередь, потребовало дополнительных ресурсов для организации их согласованной работы. В процессе разработки приложений заказчик зачастую изменял функциональные требования, что еще более усложняло процесс создания программного обеспечения.
Но не менее важными оказались качественные изменения, связанные со смещением акцента использования компьютеров. В эпоху «больших машин» основными потребителями программного обеспечения были такие крупные заказчики, как большие производственные предприятия, финансовые компании, государственные учреждения. Стоимость таких вычислительных устройств для небольших предприятий и организаций была слишком высока.
Позже появились персональные компьютеры, которые имели гораздо меньшую стоимость и были значительно компактнее. Это позволило широко использовать их в малом и среднем бизнесе. Основными задачами в этой области являются обработка данных и манипулирование ими, поэтому вычислительные и расчетно-алгоритмические задачи с появлением персональных компьютеров отошли на второй план (1).
Основополагающей идеей ООП является объединение данных и действий, производимых над этими данными, в единое целое, которое называется объектом.
Функции объекта, называемые методами или функциями-членами, обычно предназначены для доступа к данным объекта. Если необходимо считать какие-либо данные объекта, нужно вызвать соответствующий метод, который выполнит считывание и возвратит требуемое значение. Прямой доступ к данным невозможен. Данные сокрыты от внешнего воздействия, что защищает их от случайного изменения.
Если необходимо изменить данные объекта, то, очевидно, это действие также будет возложено на методы объекта. Никакие другие функции не могут изменять данные класса. Такой подход облегчает написание, отладку и использование программы.
Типичная программа на языке С++ состоит из совокупности объектов, взаимодействующих между собой посредством вызова методов друг друга. Структура программы на С++ приведена на рисунке 1.1.
Рисунок 1.1 – Объектно-ориентированный подход
ООП никак не связано с процессом выполнения программы, а является лишь способом ее организации. Когда задача решается с помощью объектно-ориентированного метода, то вместо проблемы разбиения задачи на функции, возникает проблема разбиения задачи на ее объекты. Мышление в терминах объектов оказывается гораздо более простым и наглядным, чем в терминах функций, поскольку программные объекты схожи с объектами реального мира (2).
Основное преимущество ООП заключается в том, что и данные, и операции (код), используемые для манипулирования ими, инкапсулируются в одном объекте. Объекты – это строительные блоки ООП. Та или иная программа, которая задействует объектно-ориентированную технологию, по сути является набором объектов.
При объектно-ориентированном проектировании атрибуты и поведения размещаются в рамках одного объекта, в то время как при процедурном или структурном проектировании атрибуты и поведения обычно разделяются (3).
Под атрибутом понимается описание поименованного элемента заданного типа, для которого указана область значений. Какие именно типы можно использовать, определяется конкретным языком моделирования. При создании экземпляра класса его значение из указанного диапазона должно быть конкретизировано. Исключение составляют атрибуты, общие для всего класса в целом, их значения остаются постоянными для любого экземпляра класса и присваиваются им при инициализации самого класса. Описание атрибутом подчиняется определенным синтаксическим правилам и размещается в секции описания атрибутов.
Обязательным элементом описания атрибута является только его имя. Имя должно быть уникальным внутри класса и может иметь различные области видимости: публичная, защищенная, приватная, пакетная видимость. В качестве значения видимости по умолчанию выбирается приватная видимость, делающая переменные класса невидимыми извне. В общем случае имя атрибута представляется составным именем, указывающим класс, в котором он объявляется, или «путь» к этому атрибуту в общем «пространстве» имен модели, что учитывает вложенность описаний. Любой атрибут может иметь конкретное предопределенное значение, которое он получит в момент создания экземпляра класса.
Поведение отражает динамические свойства классов и подразделяется на взаимодействие, смену состояний и деятельность. Соответственно поведение может быть представлено тремя способами: в виде диаграмм последовательности и коммуникации, диаграмм состояний и диаграмм деятельности.
Взаимодействие, представляемое диаграммами последовательности и коммуникации, – это обмен сообщений между компонентами модели. Диаграммы последовательности и коммуникации описывают участников взаимодействия (источники передачи и получателей сообщений), последовательности обмена сообщениями между ними, линии жизни участников (экземпляры классов могут создаваться и уничтожаться в любой момент модельного времени), а также накладывают временные ограничения на время передачи и приема сообщений.
Назначение диаграмм последовательности и коммуникации – указать участников и возможные сценарии обмена сообщениями между ними. Такие диаграммы нужны разработчику на самом раннем этапе проектирования функциональной схемы, а в дальнейшем могут служить только для проверки правильности разработанных алгоритмов посылки и обработки полученных сообщений.
Смена состояний является важным признаком проявления динамики. Под состоянием UML понимаются условия или ситуация в жизненном цикле объекта, во время которой он удовлетворяет некоторому условию, выполняет собственную деятельность или ожидает какого-либо события.
Деятельность в UML трактуется как управление всей системой

. Управление в динамической системе может осуществляться непрерывно и дискретно. С точки зрения современных сложных динамических систем, это достаточно простые виды управления. На управление можно смотреть и шире. В этом смысле деятельность связана с алгоритмами управления, или с анализирующими и поддерживающими характеристики системы в заданных границах, или с оптимизирующими ее поведение в соответствии с заданными критериями, или приводящими систему к выбранной цели. В последнем случае управление выражается в предписании, какие действия необходимо выполнить для достижения заданной цели. Как описать процессы управления, являются ли эти процессы последовательными или параллельными, в какой последовательности их следует выполнять. Именно это и указывается на диаграммах деятельности.
И деятельность, как разновидность глобального поведения всей системы, и смена состояний могут быть представлены одним и тем же графическим способом – диаграммой состояний. Такая диаграмма по существу является «дискретной», т.е. классической картой состояния, отражающей, что и в какой последовательности следует выполнять для реализации управления, с указанием того, какие процессы можно выполнять параллельно (4).
После составления технического задания начинается этап проектирования, или дизайна, будущей системы. Объектно-ориентированный подход к проектированию основан на представлении предметной области задачи в виде множества моделей для независимой от языка разработки программной системы на основе ее прагматики.
Последний термин нуждается в пояснении. Прагматика определяется целью разработки программной системы, например, обслуживание клиентов банка, управление работой аэропорта, обслуживание чемпионата мира по футболу и т.п. В формулировке цели участвуют предметы и понятия реального мира, имеющие отношение к создаваемой системе (рисунок 1.2). При объектно-ориентированном подходе эти предметы и понятия заменяются моделями, т.е. определенными формальными конструкциями.
Рисунок 1.2 – Семантика (смысл программы с точки зрения выполняющего ее компьютера) и прагматика (смысл программы с точки зрения ее пользователей)
Простота модели по отношению к реальному предмету позволяет сделать ее формальной. Благодаря такому характеру моделей при разработке можно четко выделить все зависимости и операции над ними в создаваемой программной системе. Это упрощает как разработку и изучение (анализ) моделей, так и их реализацию на компьютере.
Объектно-ориентированный подход обладает такими преимуществами, как:
– уменьшение сложности программного обеспечения;
– повышение надежности программного обеспечения;
– обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов;
– обеспечение возможности повторного использования отдельных компонентов программного обеспечения.
Но одной из самых значительных проблем проектирования является сложность. Чем больше и сложнее программная система, тем важнее разбить ее на небольшие, четко очерченные части. Чтобы справиться со сложностью, необходимо абстрагироваться от деталей. В этом смысле классы представляют собой весьма удобный инструмент.
Классы позволяют проводить конструирование из полезных компонентов, обладающих простыми инструментами, что позволяет абстрагироваться от деталей реализации.
Данные и операции над ними образуют определенную сущность, и они не разносятся по всей программе, как нередко бывает в случае процедурного программирования, а описываются вместе. Локализация кода и данных улучшает наглядность и удобство сопровождения программного обеспечения (1).
ООП основано на «трех китах» – трех важнейших принципах, придающих объектам новые свойства. Этими принципами являются инкапсуляция, наследование и полиморфизм.
Инкапсуляция есть объединение в единое целое данных и алгоритмов обработки этих данных. В рамках ООП данные называются полями объекта, а алгоритмы – объектными методами.
Инкапсуляция позволяет в максимальной степени изолировать объект от внешнего окружения. Она существенно повышает надежность разрабатываемых программ, т.к. локализованные в объекте алгоритмы обмениваются с программой сравнительно небольшими объемами данных, причем количество и тип этих данных обычно тщательно контролируются. В результате замена или модификация алгоритмов и данных, инкапсулированных в объект, как правило, не влечет за собой плохо прослеживаемых последствий для программы в целом. Другим немаловажным следствием инкапсуляции является легкость обмена объектами, переноса их из одной программы в другую.
Наследование есть свойство объектов порождать своих потомков. Объект-потомок автоматически наследует от родителя все поля и методы, может дополнять объекты новыми полями и заменять (перекрывать) методы родителя или дополнять их.
Принцип наследования решает проблему модификации свойств объекта и придает ООП в целом исключительную гибкость. При работе с объектами программист обычно подбирает объект, наиболее близкий по своим свойствам для решения конкретной задачи, и создает одного или нескольких потомков от него, которые «умеют» делать то, что не реализовано в родителе.
Последовательное проведение в жизнь принципа «наследуй и изменяй» хорошо согласуется с поэтапным подходом к разработке крупных программных проектов и во многом стимулирует такой подход.
Полиморфизм – это свойство родственных объектов решать схожие по смыслу проблемы разными способами. В рамках ООП поведенческие свойства объекта определяются набором входящих в него методов. Изменяя алгоритм того или иного метода в потомках объекта, программист может придавать этим потомкам отсутствующие у родителя специфические свойства. Для изменения метода необходимо перекрыть его в потомке, т.е. объявить в потомке одноименный метод и реализовать в нем нужные действия. В результате в объекте-родителе и объекте-потомке будут действовать два одноименных метода, имеющие разную алгоритмическую основу и, следовательно, придающие объектам разные свойства (5).
Инкапсуляция позволяет привнести свойство модульности, что облегчает распараллеливание выполнения задачи между несколькими исполнителями и обновление версий отдельных компонентов.
ООП дает возможность создавать расширяемые системы. Это одно из основных достоинств ООП, и именно оно отличает данный подход от традиционных методов программирования. Расширяемость означает, что существующую систему можно заставить работать с новыми компонентами, причем без внесения в нее каких-либо изменений. Компоненты могут быть добавлены на этапе исполнения программы.
Полиморфизм оказывается полезным преимущественно в следующих ситуациях.
Программы могут работать, не различая вида объектов, что существенно упрощает код. Новые виды могут быть добавлены в любой момент.
На этапе исполнения один объект может быть заменен другим, что позволяет легко, без изменения кода, адаптировать алгоритм в зависимости от того, какой используется объект.
Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов.
Независимые от приложения части предметной области могут быть реализованы в виде набора универсальных классов, или каркаса (framework), и в дальнейшем расширены за счет добавления частей, специфичных для конкретного приложения.
Часто многоразового использования программного обеспечения не удается добиться из-за того, что существующие компоненты уже не отвечают новым требованиям