Понятие класса и объекта. Что может быть объектом. Атрибут и операции

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

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

ИМЯ_КЛАССА

имя_атрибута 1: тип_1 = значение_по_умолчанию_1   имя_атрибута 2: тип_2 = значение_по_умолчанию_2   . . . . . . . . . . . . . . .

имя_операции_1 (список_аргументов_1): тип_результата   сигнатура_операции_2   сигнатура_операции_3   . . . . . . . . . . . . . . . .

Рис. 3.3. Полное представление объекта в OMT

Рис. 2.5. Возможные классы для системы AMT (банковское обслуживание)

 

 

 

 

 

2.3.Зависимости между классами, объектами

 

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

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

Рис. 3.6. Зависимости между классами

 

   Зависимости между классами являются двусторонними: все классы в зависимости равноправны. Это так даже в тех случаях, когда имя зависимости как бы вносит направление в эту зависимость. Так, в первом примере на рисунке 3.6 имя зависимости «имеет столицу» предполагает, что зависимость направлена от класса страна к классу город (двусторонность зависимости вроде бы пропала); но следует иметь в виду, что эта зависимость двусторонняя в том смысле, что одновременно с ней существует и обратная зависимость является столицей. Точно таким же образом, во втором примере на рисунке 3.6 можно рассматривать пару зависимостей владеет-принадлежит. Подобных недоразумений можно избежать, если идентифицировать зависимости не по именам, а по наименованиям ролей классов, составляющих зависимость.

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

   Дальнейшие примеры зависимостей между классами приведены на рисунке 3.7. Первый пример показывает зависимость между клиентом банка и его счетами. Клиент банка может иметь одновременно несколько счетов в этом банке, либо вовсе не иметь счета (когда он впервые становится клиентом банка). Таким образом, нужно изобразить зависимость между клиентом и несколькими счетами, что и сделано на рисунке 3.7. Второй пример показывает зависимость между пересекающимися кривыми (в частности, прямыми) линиями. Можно рассматривать 2, 3, и более таких линий, причем они могут иметь несколько точек пересечения. Наконец, третий пример показывает необязательную (optional) зависимость: компьютер может иметь, а может и не иметь мышь.

   Зависимостям между классами соответствуют зависимости между объектами этих классов. На рисунке 3.8 показаны зависимости между объектами для первого примера рисунка 2.6; на рисунке 3.9 показаны зависимости между объектами для примеров, изображенных на рисунке 3.7.

Рис. 3.7. Дальнейшие примеры зависимостей. Обозначения

Рис. 3.8. Зависимости между объектами

   Отметим, что при изображении зависимостей между объектами мы, как правило, знаем количество объектов и не нуждаемся в таких обозначениях как "несколько", "два и более", "не обязательно".

   При проектировании системы удобнее оперировать не объектами, а классами.

Рис. 3.9. Более сложные зависимости между объектами

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Заключение

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

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

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

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

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

   Третий этап заключается в объектной декомпозиции как выделении подтипов или подобъектов и их составляющих для каждого из типов объектов.

   Четвертый этап представляет собой композиционную иерархизацию объектов как выделение родовидовых и композиционных отношений над объектами.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список литературы:

 

1. М. Уэйт, С. Прата, Д. Мартин Язык  Си: Пер с англ.-М.: Мир, 2007.-463 с.,ил.

 

2. Уинер Р. Язык Турбо Си: Пер  с англ.-М.: Мир, 2010.-384 с., ил.

 

3. Берри Р., Микинз Б. Язык Си: введение для программистов: Пер. с англ.-М.:Финансы и статистика, 2007.-с.,ил.

 

4. TURBO C++. Borland International. Inc. 2010.