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

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

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

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

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

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

Расширение типа (type extension) и происходящий из него полиморфизм переменных становятся нужными в большей степени в следующих ситуациях.

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

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

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

Отметим недостатки ООП

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

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

Многоразовое применение потребует от программиста познакомиться с крупными библиотеками классов. А это может оказаться труднее, чем даже изучение нового языка программирования. Библиотека классов фактически представляет собой виртуальный язык, который может включать в себя сотни типов и тысячи операций. В языке Smalltalk, к примеру, до того, как перейти к практическому программированию, нужно изучить значительную часть его библиотеки классов. А это тоже требует времени.

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

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

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

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

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

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

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

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

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

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

Неэффективность на этапе исполнения. В языках типа Smalltalk сообщения интерпретируются во время исполнения программы путем осуществления поиска их в одной или нескольких таблицах и за счет выбора подходящего метода. Безусловно, это медленный процесс. И в том числе при использовании наилучших методов оптимизации Smalltalk-программы в 10-ть раз медленнее оптимизированных C-программ.

В гибридных языках типа Oberon-2, Object Pascal и C++ посылка сообщения приводит только к вызову через указатель процедурной переменной. На отдельных машинах сообщения выполняются лишь на 10% медленнее, чем обычные процедурные вызовы. И так как сообщения попадаются в программе значительно реже других операций, их воздействие на время исполнения влияния почти никак не проявляет.

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

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

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

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

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

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

Oberon выбрал 3-ий подход освобождения от избыточной универсальности.

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

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

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

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

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

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