Файл: Применения объектно-ориентированного подхода при проектировании информационной системы.pdf

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

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

6. Параллелизм

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

Каждая программа должна иметь один поток управления, но в параллельной системе существует возможность создавать множество потоков управления с разным приоритетом.

Выделяют следующие виды параллелизма:

1. «тяжеловесный» (heavyweight);
2. «легковесный» (lightweight).

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

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

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

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

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

Параллелизм – это свойство, отличающее активные объекты от пассивных.

В параллельных системах недостаточно определить методы объекта – необходимо также принять меры для сбережения семантики этих методов в присутствии нескольких потоков управления.

7. Персистентность

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

Персистентность объектов может проявляться в разных видах.

1. Промежуточные результаты вычисления выражений.
2. Локальные переменные в вызове процедур.
3. Собственные переменные, глобальные переменные и динамические данные.
4. Данные, сохраняющиеся между разными сеансами выполнения программы.
5. Данные, сохраняющиеся при переходе от одной версии программы к другой.
6. Данные, существующие после исчезновения программы.

Первые три вида персистентности характерны для традиционных языков программирования, а последние – для баз данных.

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

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

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

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

Как и у любого метода программирования, у ООП есть ряд преимуществ и недостатков.

IV. Достоинства и недостатки объектно-ориентированного подхода.

1. Достоинства ООП

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

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

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

Расширение типа и вытекающий из него полиморфизм переменных оказываются полезными преимущественно в следующих ситуациях.

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

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

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

2. Недостатки ООП

Объектно-ориентированное программирование требует знания четырех вещей.

• • Необходимо понимать базовые концепции, такие как классы, наследование и динамическое связывание. Для программистов, уже знакомых с понятием модуля и с абстрактными типами данных, это потребует минимальных усилий. Для тех же, кто никогда не использовал инкапсуляцию данных, это может означать изменения мировоззрения и может отнять на изучение значительное количество времени.
  • Многоразовое использование требует от программиста познакомиться с большими библиотеками классов. А это может оказаться сложнее, чем даже изучение нового языка программирования. Библиотека классов фактически представляет собой виртуальный язык, который может включать в себя сотни типов и тысячи операций.
  • Проектирование классов — задача куда более сложная, чем их использование. Проектирование класса, как и проектирование языка, требует большого опыта. Это итеративный процесс, где приходится учиться на своих же ошибках.
  • Очень трудно изучать классы, не имея возможности их «пощупать». Только с приобретением опыта можно уверенно себя почувствовать при работе с использованием ООП.

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

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

Часто можно слышать, что ООП является неэффективным. Как же дело обстоит в действительности? Нужно четко проводить грань между неэффективностью на этапе выполнения, неэффективностью в смысле распределения памяти и неэффективностью, связанной с излишней универсализацией.

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

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

Другой подход — дать возможность компоновщику удалять лишние методы.

Таким образом, нельзя утверждать, что ООП вообще неэффективно.

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