Лекция
Привет, мой друг, тебе интересно узнать все про объектная модель, тогда с вдохновением прочти до конца. Для того чтобы лучше понимать что такое объектная модель, инкапсуляция, наследование, полиморфизм , абстрагирование, абстракция, модульность, иерархия, типизация , настоятельно рекомендую прочитать все из категории Объектно-ориентированное программирование ООП.
Объектно-ориентированный подход принципиально отличаются от традиционных подходов структурного проектирования: здесь нужно по-другому представлять себе процесс декомпозиции, а архитектура получающегося программного продукта в значительной степени выходит за рамки представлений, традиционных для структурного программирования. Это связанно с тем, что программы, созданные, при помощи традиционных подходов оперируют в основном глаголами (функциями). Мы пытаемся запрограммировать задачу как последовательность функций и алгоритмов, проведя, для этого, так называемую алгоритмическую декомпозирую. При объектном подходе проводится объектная декомпозиция, и программа представляется уже как набор взаимодействующих друг с другом объектов.
Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются: абстрагирование , инкапсуляция , модульность , иерархичность, типизация , параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности. Первые четыре принципа являются обязательными в том смысле, что без них модель не будет считаться объектной. Последние три дополнительными. Рассмотрим подробно все принципы.
Абстрагирование выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя. Фраза “с точки зрения наблюдателя” важна, так как разные люди могут иметь совершенно разные взгляды на вещь или проблему.
Абстрагирование - это выделение таких существенных характеристик объектов, которые отличают его от всех других объектов и которые четко определяют особенности данного объекта с точки зрения дальнейшего рассмотрения и анализа.
Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. Абельсон и Суссман назвали такое разделение смысла и реализации барьером абстракции, который основывается на принципе минимизации связей, когда интерфейс объекта содержит только существенные аспекты поведения и ничего больше. Существует еще один дополнительный принцип, называемый принципом наименьшего удивления, согласно которому абстракция должна охватывать все поведение объекта, но не больше и не меньше, и не привносить сюрпризов или побочных эффектов, лежащих вне ее сферы применимости.
Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования. Существует 4 вида абстракций (перечислены по мере уменьшения полезности).
Центральным понятием абстрагирования является понятие абстракции.
Абстракция фокусируется на существенных с точки зрения наблюдателя характеристиках объекта.
Центральной идеей абстракции является понятие инварианта. Инвариант - это некоторое логическое условие, значение которого (истина или ложь) должно сохраняться. Для каждой операции объекта можно задать предусловия (инварианты предполагаемые операцией) и постусловия (инварианты, которым удовлетворяет операция). Изменение инварианта нарушает контракт, связанный с абстракцией. В частности, если нарушено предусловие, то клиент не соблюдает свои обязательства и сервер не может выполнить свою задачу правильно. Если же нарушено постусловие, то свои обязательства нарушил сервер, и клиент не может более ему доверять. В случае нарушения какого-либо условия возбуждается исключительная ситуация. Как мы увидим далее, некоторые языки имеют средства для работы с исключительными ситуациями: объекты могут возбуждать исключения, чтобы запретить дальнейшую обработку и предупредить о проблеме другие объекты, которые в свою очередь могут принять на себя перехват исключения и справиться с проблемой.
Заметим, что понятия операция, метод и функция-член происходят от различных традиций программирования (Ada, Smalltalk и C++ соответственно). Фактически они обозначают одно и то же и в дальнейшем будут взаимозаменяемы.
Все абстракции обладают как статическими, так и динамическими свойствами. Например, файл как объект требует определенного объема памяти на конкретном устройстве, имеет имя и содержание. Эти атрибуты являются статическими свойствами. Конкретные же значения каждого из перечисленных свойств динамичны и изменяются в процессе использования объекта: файл можно увеличить или уменьшить, изменить его имя и содержимое. В процедурном стиле программирования действия, изменяющие динамические характеристики объектов, составляют суть программы. Любые события связаны с вызовом подпрограмм и с выполнением операторов. Стиль программирования, ориентированный на правила, характеризуется тем, что под влиянием определенных условий активизируются определенные правила, которые в свою очередь вызывают другие правила, и т.д. Объектно-ориентированный стиль программирования связан с воздействием на объекты (в терминах Smalltalk с передачей объектам сообщений). Так, операция над объектом порождает некоторую реакцию этого объекта. Операции, которые можно выполнить по отношению к данному объекту, и реакция объекта на внешние воздействия определяют поведение этого объекта
Контрактная модель программирования
Очень важным для абстрагирования понятием является понятие контрактной модели программирования. Введем несколько определений.
Клиентом называется любой объект, использующий ресурсы другого объекта (называемого сервером). Мы будем характеризовать поведение объекта услугами, которые он оказывает другим объектам, и операциями, которые он выполняет над другими объектами. Такой подход концентрирует внимание на внешних проявлениях объекта и приводит к идее, которую Мейер назвал контрактной моделью программирования: внешнее проявление объекта рассматривается с точки зрения его контракта с другими объектами, в соответствии с этим должно быть выполнено и его внутреннее устройство (часто во взаимодействии с другими объектами). Контракт фиксирует все обязательства, которые объект-сервер имеет перед объектом-клиентом. Другими словами, этот контракт определяет ответственность объекта - то поведение, за которое он отвечает.
Каждая операция, предусмотренная этим контрактом, однозначно определяется ее формальными параметрами и типом возвращаемого значения. Полный набор операций, которые клиент может осуществлять над другим объектом, вместе с правильным порядком, в котором эти операции вызываются, называется протоколом. Протокол отражает все возможные способы, которыми объект может действовать или подвергаться воздействию, полностью определяя тем самым внешнее.
Центральной идеей в контрактной модели программирования является понятие инварианта. Инвариант - это некоторое логическое условие, значение которого (истина или ложь) должно сохраняться. Для каждой операции объекта можно задать предусловия (инварианты предполагаемые операцией) и постусловия (инварианты, которым удовлетворяет операция). Изменение инварианта нарушает контракт, связанный с абстракцией. В частности, если нарушено предусловие, то клиент не соблюдает свои обязательства и сервер не может выполнить свою задачу правильно. Если же нарушено постусловие, то свои обязательства нарушил сервер, и клиент не может более ему доверять. В случае нарушения какого-либо условия возбуждается исключительная ситуация. Многие языки программирования имеют средства для работы с исключительными ситуациями: объекты могут возбуждать исключения, чтобы запретить дальнейшую обработку и предупредить о проблеме другие объекты, которые в свою очередь могут принять на себя перехват исключения и справиться с проблемой.
Инкапсуляция - это процесс отделения друг от друга элементов абстракции, определяющих ее устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации.
Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством. Чаще всего инкапсуляция выполняется посредством скрытия информации, то есть маскировкой всех внутренних деталей, не влияющих на внешнее поведение объекта. Обычно скрываются и внутренняя структура объекта и реализация его методов. Необходима инкапсуляция для того, что бы та модель которую мы выражаем средствами языков моделирования и программирования была адекватной.
Инкапсуляция определяет явные барьеры между различными абстракциями, скрывает внутреннее устройство объекта и не позволяет объектам-пользователям различить (и использовать) особенности его внутреннего устройства.
Рассмотрим пример растения. У растения существует такой атрибут как размер. Что может повлиять на размер? На размер могут повлиять количество солнечного света, количество воды, количество навоза наконец. Вы воздействуете на размер меняя количество того или другого из перечисленных параметров. Если Вы будете поливать цветок он будет расти. При этом, Вы не можете в реальном мире одним усилием мысли заставить цветок вырасти на два метра. Это нереально, так как только сам цветок представляет себе механизмы по которым меняется его размер. И было бы естественно, что бы и в программной модели цветка не было возможности менять размер цветка явно. Поэтому, мы спрячем атрибут – размер цветка в реализации, а в интерфейсе модели выставим в метод «ВоздействоватьНаРост» с такими параметрами как количество света, воды и навоза.
Скрытие информации - понятие относительное: то, что спрятано на одном уровне абстракции, обнаруживается на другом уровне. Забраться внутрь объектов можно; правда, обычно требуется, чтобы разработчик класса-сервера об этом специально позаботился, а разработчики классов-клиентов не поленились в этом разобраться. Инкапсуляция не спасает от глупости; она, как отметил Страуструп, "защищает от ошибок, но не от жульничества" Разумеется, язык программирования тут вообще ни при чем; разве что операционная система может ограничить доступ к файлам, в которых описаны реализации классов. На практике же иногда просто необходимо ознакомиться с реализацией класса, чтобы понять его назначение, особенно, если нет внешней документации.
Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
Например, если вы читаете данные из файла, то, очевидно, в классе, реализующем файловый поток, будет присутствовать метод похожий на следующий: byte[] readBytes( int n );
Предположим теперь, что вам необходимо считывать те же данные из сокета. Об этом говорит сайт https://intellect.icu . В классе, реализующем сокет, также будет присутствовать метод readBytes. Достаточно заменить в вашей системе объект одного класса на объект другого класса, и результат будет достигнут.
При этом логика системы может быть реализована независимо от того, будут ли данные прочитаны из файла или получены по сети. Таким образом, мы абстрагируемся от конкретной специализации получения данных и работаем на уровне интерфейса. Единственное требование при этом – чтобы каждый используемый объект имел метод readBytes.
Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов .
Существует несколько разновидностей полиморфизма. Две принципиально различных из них были описаны Кристофером Стрэчи[en] в 1967 году: это параметрический полиморфизм[⇨] и ad-hoc-полиморфизм[⇨], причем первая является истинной формой, а вторая — мнимой ; прочие формы являются их подвидами или сочетаниями. Параметрический полиморфизм подразумевает исполнение одного и того же кода для всех допустимых типов аргументов, тогда как ad-hoc-полиморфизм подразумевает исполнение потенциально разного кода для каждого типа или подтипа аргумента. Бьерн Страуструп определил полиморфизм как «один интерфейс — много реализаций» , но это определение покрывает лишь ad-hoc-полиморфизм.
Полиморфизм (многоформенность) является следствием идеи наследования. В общих словах, полиморфность класса — это свойство базового класса использовать функции производных классов, даже если на момент определения еще неизвестно, какой именно класс будет включать его в качестве базового и, тем самым, становиться от него производным.
Рассмотрим свойство полиморфности классов на основе следующего примера:
Используем следующие следующие команды:
$a->Call(); // выводит "Test from A" $b->Test(); // выводит "Test from B" $b->Call(); // Внимание! Выводит "Test from B"!
Обратите внимание на последнюю строчку: вопреки ожиданиям, вызывается не функция Test() из класса A, а функция из класса B! Складывается впечатление, что Test() из B просто переопределила функцию Test() из A. Так оно на самом деле и есть. Функция, переопределяемая в производном классе, называется виртуальной.
Механизм виртуальных функций позволяет, например, "подсовывать" функциям, ожидающим объект одного класса, объект другого, производного, класса. Еще один классический пример — класс, воплощающий собой свойства геометрической фигуры, и несколько производных от него классов — квадрат, круг, треугольник и т.д.
Базовый класс имеет виртуальную функцию Draw(), которая заставляет объект нарисовать самого себя. Все производные классы-фигуры, разумеется, переопределяют эту функцию (ведь каждую фигуру нужно рисовать по-особому). Также у нас есть массив фигур, причем мы не знаем, каких именно. Зато, используя полиморфизм, мы можем, не задумываясь, перебрать все элементы массива и вызвать для каждого из них метод Draw() — фигура сама "решит", какого она типа и как ее рисовать.
А вот еще один практический пример, показывающий свойство класса - полиморфизм:
В рассмотренном примере функция base_funct() класса Base была перезаписана одноименной функцией класса Derivative.
Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.
Модульность - это свойство системы, связанное с возможностью декомпозиции на ряд тесно связанных частей (модулей). Модульность опирается на дискретное программирование объектов, которые можно модернизировать или заменять, не воздействуя на другие объекты и систему в целом.
По мнению Майерса "Разделение программы на модули до некоторой степени позволяет уменьшить ее сложность... Однако гораздо важнее тот факт, что внутри модульной программы создаются множества хорошо определенных и документированных интерфейсов. Эти интерфейсы неоценимы для исчерпывающего понимания программы в целом". В некоторых языках программирования, например в Smalltalk, модулей нет, и классы составляют единственную физическую основу декомпозиции. В других языках, включая Object Pascal, C++, Java модуль - это самостоятельная языковая конструкция. В этих языках классы и объекты составляют логическую структуру системы, они помещаются в модули, образующие физическую структуру системы. Это свойство становится особенно полезным, когда система состоит из многих сотен классов.
В большинстве языков, поддерживающих принцип модульности как самостоятельную концепцию, интерфейс модуля отделен от его реализации. Таким образом, модульность и инкапсуляция ходят рука об руку. В разных языках программирования модульность поддерживается по-разному. Например, в C++ модулями являются раздельно компилируемые файлы. Для C/C++ традиционным является помещение интерфейсной части модулей в отдельные файлы с расширением .h (так называемые файлы-заголовки). Реализация, то есть текст модуля, хранится в файлах с расширением .с (в программах на C++ часто используются расширения ср и .срр). Связь между файлами объявляется директивой макропроцессора #include. Такой подход строится исключительно на соглашении и не является строгим требованием самого языка. В языке Object Pascal принцип модульности формализован несколько строже. В этом языке определен особый синтаксис для интерфейсной части и реализации модуля (unit). В Java существуют так называемые package. Каждый package содержит себе несколько классов сгруппированных по некоторому логическому признаку.
Модульность, кроме облегчения поиска нужного описания, позволяет значительно ускорить процесс сборки проекта (естественно, для компиляторов поддерживающих раздельную компиляцию). Рассмотрим пример.
Естественно, все это накладывает очень жесткие ограничение на устойчивость интерфейсов, но задача формирования устойчивых интерфейсов задача проектирования вообще.
Абстракция - вещь полезная, но всегда, кроме самых простых ситуаций, число абстракций в системе намного превышает наши умственные возможности. Инкапсуляция позволяет в какой-то степени устранить это препятствие, убрав из поля зрения внутреннее содержание абстракций. Модульность также упрощает задачу, объединяя логически связанные абстракции в группы. Но этого оказывается недостаточно.
Существование иерархий – это ранжирование, упорядочивание по некоторым правилам объектов системы.
Значительное упрощение в понимании сложных задач достигается за счет образования из абстракций иерархической структуры. Определим иерархию следующим образом:
Иерархия - это упорядочение абстракций, расположение их по уровням.
Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of").
Важным элементом объектно-ориентированных систем и основным видом иерархии "is-a" является упоминавшаяся выше концепция наследования. наследование означает такое отношение между классами (отношение родитель/потомок), когда один класс заимствует структурную или функциональную часть одного или нескольких других классов (соответственно, одиночное и множественное наследование). Иными словами, наследование создает такую иерархию абстракций, в которой подклассы наследуют строение от одного или нескольких суперклассов. Часто подкласс достраивает или переписывает компоненты вышестоящего класса.
Семантически, наследование описывает отношение типа "is-a". Например, медведь есть млекопитающее, дом есть недвижимость и "быстрая сортировка" есть сортирующий алгоритм. Таким образом, наследование порождает иерархию "обобщение-специализация", в которой подкласс представляет собой специализированный частный случай своего суперкласса. "Лакмусовая бумажка" наследования - обратная проверка; так, если B не есть A, то B не стоит производить от A. Помимо одиночного наследования, примеры которого мы только что привели, существует еще один вариант наследования – множественное. В этом случае, некоторый класс допускает одновременно два обощения, например, яблоко можно рассматривать как фрукт и как цветок. То же самое можно сказать и о вишне. Еще один пример: рация является одновременно и приемником, и передатчиком.
Множественное наследование - вещь нехитрая, но оно осложняет реализацию языков программирования. Есть две проблемы - конфликты имен между различными суперклассами и повторное наследование. Первая проблема возникает тогда, когда в двух или большем числе суперклассов определено поле или операция с одинаковым именем. В C++ этот вид конфликта должен быть явно разрешен вручную, а в Smalltalk берется то, которое встречается первым. Вторая проблемы это повторное наследование. Повторное наследование, это когда класс наследует двум классам, а они порознь наследуют одному и тому же четвертому. Получается ромбическая структура наследования и надо решить, должен ли самый нижний класс получить одну или две отдельные копии самого верхнего класса? В некоторых языках повторное наследование запрещено, в других конфликт решается "волевым порядком", а в C++ это оставляется на усмотрение программиста.
Множественным наследованием часто злоупотребляют. Например, сладкая вата - это частный случай сладости, но никак не ваты. Применяйте ту же "лакмусовую бумажку": если B не есть A, то ему не стоит наследовать от A. Часто плохо сформированные структуры множественного наследования могут быть сведены к единственному суперклассу плюс агрегация других классов подклассом.
Если иерархия "is а" определяет отношение "обобщение/специализация", то отношение "part of" (часть-целое) вводит иерархию агрегации. Например человек-рука, огород-растение.
Агрегация есть во всех языках, использующих структуры или записи, состоящие из разнотипных данных. Но в объектно-ориентированном программировании она обретает новую мощь: агрегация позволяет физически сгруппировать логически связанные структуры, а наследование с легкостью копирует эти общие группы в различные абстракции.
Типизация - описание в тексте системы типов всех объектов, с которыми она работает на этапе выполнения;
Понятие типа взято из теории абстрактных типов данных. Дойч определяет тип, как "точную характеристику свойств, включая структуру и поведение, относящуюся к некоторой совокупности объектов". Для наших целей достаточно считать, что термины тип и класс взаимозаменяемы. (На самом деле тип и класс не вполне одно и то же; в некоторых языках их различают. Например, ранние версии языка Trellis/Owl разрешали объекту иметь и класс, и тип. Даже в Smalltalk объекты классов SmallInteger, LargeNegativeInteger, LargePositiveInteger относятся к одному типу Integer, хотя и к разным классам . Большинству смертных различать типы и классы просто противно и бесполезно. Достаточно сказать, что класс реализует понятие типа).
Типизация - это способ защититься от использования объектов одного класса вместо другого (сильная типизация), или по крайней мере управлять таким использованием (слабая типизация).
Типизация заставляет нас выражать наши абстракции так, чтобы язык программирования, используемый в реализации, поддерживал соблюдение принятых проектных решений. Идея согласования типов занимает в понятии типизации центральное место. Например, возьмем физические единицы измерения. Деля расстояние на время, мы ожидаем получить скорость, а не вес. В умножении температуры на силу смысла нет, а в умножении расстояния на силу - есть. Наконец всех Вас еще в первом классе учили тому, что нельзя складывать яблоки и белок. Все это примеры сильной типизации, когда прикладная область накладывает правила и ограничения на использование и сочетание абстракций. Со слабой типизацией все несколько сложнее.
Слабая типизация очень тесно связана с понятием полиморфизма.
Полиморфизм - положение теории типов, согласно которому имена (например, переменных) могут обозначать объекты разных (но имеющих общего родителя) классов. Любой объект, обозначаемый полиморфным именем, может по-своему реагировать на некий общий набор операций.
Рассмотрим пример. Пускай у нас есть графический редактор. Окно редактора представляет собой некий контейнер, в котором находятся графические объекты. Все графические объекты (треугольник, прямоугольник, круг…) являются подклассами класса GraphicObject. Все это можно представить диаграммой классов (рис. 1.8)
Рисунок 1.8 Иерархия классов графического редактора
Как видно из диаграммы, окно графического редактора (класс Window) содержит (агрегирует) в себе графические объекты. Все, что класс Window знает о классах GraphicObject, так это только то, что графический объект умеет себя перерисовывать (для этого необходимо вызвать метод paint()). Класс Window не знает о существовании классов Circle, Rectangle и Triangle. (Такой подход позволяет добавлять в редактор новые виды графических объектов не изменяя реализацию класса Window. Далее, при рассмотрении паттернов проектирования, мы рассмотрим подобные приемы более подробно). Так вот, когда вам необходимо перерисовать окно редактора, Вы вызываете метод Window::repaint(). Его реализация может выгладить примерно, так:
Таким образом, объект класса Window, просто вызывает метод paint() для каждого агрегируемого объекта не заботят то , как именно этот метод будет работать. Этот пример полиморфизма демонстрирует так же суть слабой типизации. Действительно, реальные объекты, находящиеся в векторе objects – это указатели на объекты классов Circle, Rectangle и Triangle. Описаны же они как указатели на объекты класса GraphicObjects (см. первую часть определения полиморфизма). Кроме того, объекты из objects по разному реагируют на одноименную операцию repaint() (круг, квадрат и треугольник для своего отображения действительно выполняют разные действия) (см. вторую часть определения полиморфизма и определения слабой типизации (об управлении использования объектов одного типа, вместо объектов другого типа)).
Параллелизм - свойство объектов находиться в активном, либо пассивном состоянии. Для многопроцессорных архитектур объект может представлять собой отдельный канал управления (абстракцию процесса), что упрощает решение вопросов параллелизма (тупики, блокировки и т.п.). Для однопроцессорных архитектур реализуется в минимальном виде. Пример – многооконный интерфейс Windows.
Есть задачи, в которых автоматические системы должны обрабатывать много событий одновременно. В других случаях потребность в вычислительной мощности превышает ресурсы одного процессора. В каждой из таких ситуаций естественно использовать несколько компьютеров для решения задачи или задействовать многозадачность на многопроцессорном компьютере. Процесс (поток управления) - это фундаментальная единица действия в системе. Каждая программа имеет по крайней мере один поток управления, параллельная система имеет много таких потоков: век одних недолог, а другие живут в течении всего сеанса работы системы. Реальная параллельность достигается только на многопроцессорных системах, а системы с одним процессором имитируют параллельность за счет алгоритмов разделения времени.
Кроме этого "аппаратного" различия, мы будем различать "тяжелую" и "легкую" параллельность по потребности в ресурсах. "Тяжелые" процессы управляются операционной системой независимо от других, и под них выделяется отдельное защищенное адресное пространство. "Легкие" сосуществуют в одном адресном пространстве. "Тяжелые" процессы общаются друг с другом через операционную систему, что обычно медленно и накладно. Связь "легких" процессов осуществляется гораздо проще, часто они используют одни и те же данные.
Многие современные операционные системы предусматривают прямую поддержку параллелизма, и это обстоятельство очень благоприятно сказывается на возможности обеспечения параллелизма в объектно-ориентированных системах. Например, системы UNIX предусматривают системный вызов fork, который порождает новый процесс. Современные Системы Windows - многопоточные; кроме того они обеспечивают программные интерфейсы для создания процессов и манипулирования с ними (см. CreateProcess).
Вообще говоря, возможности проектирования параллельности в объектно-ориентированных языках не сильно отличаются от любых других, - на нижних уровнях абстракции параллелизм и OOP развиваются совершенно независимо. С OOP или без, все традиционные проблемы параллельного программирования сохраняются. Действительно, создавать большие программы и так непросто, а если они еще и параллельные, то надо думать о возможном простое одного из потоков, неполучении данных, взаимной блокировке и т.д.
К счастью, на верхних уровнях OOP упрощает параллельное программирование для так как объектная модель неявно разбивает программу на (1) распределенные единицы и (2) сообщающиеся субъекты.
В то время, как объектно-ориентированное программирование основано на абстракции, инкапсуляции и наследовании, параллелизм главное внимание уделяет абстрагированию и синхронизации процессов. Объект есть понятие, на котором эти две точки зрения сходятся: каждый объект (полученный из абстракции реального мира) может представлять собой отдельный поток управления (абстракцию процесса). Такой объект называется активным. Для систем, построенных на основе OOD, мир может быть представлен, как совокупность взаимодействующих объектов, часть из которых является активной и выступает в роли независимых вычислительных центров. На этой основе дадим следующее определение параллелизма: Параллелизм - это свойство, отличающее активные объекты от пассивных.
Хотелось бы отметить, что большинство современных языков программирования в той или иной степени поддерживают параллелизм. Из распространенных языков, наиболее полная поддержка параллелизма присутствует в Java и C#. В С++ параллелизма как такового нет, но он достигается путем использования соответствующих библиотек.
Сохраняемость или устойчивость (persistence) - свойство объектов сохранять свое состояние и принадлежность к определенному классу.
Любой программный объект существует в памяти и живет во времени. Можно. предположить, что есть непрерывное множество продолжительности существования объектов: существуют объекты, которые присутствуют лишь во время вычисления выражения, но есть и такие, как базы данных, которые существуют независимо от программы. Этот спектр сохраняемости объектов охватывает:
Традиционно, первыми тремя уровнями занимаются языки программирования, а последними - базы данных. Этот конфликт культур приводит к неожиданным решениям: программисты разрабатывают специальные схемы для сохранения объектов в период между запусками программы, а конструкторы баз данных переиначивают свою технологию под короткоживущие объекты.
Унификация принципов параллелизма для объектов позволила создать параллельные языки программирования. Аналогичным образом, введение сохраняемости, как нормальной составной части объектного подхода приводит нас к объектно-ориентированным базам данных (OODB, object-oriented databases). На практике подобные базы данных строятся на основе проверенных временем моделей - последовательных, индексированных, иерархических, сетевых или реляционных, но программист может ввести абстракцию объектно-ориентированного интерфейса, через который запросы к базе данных и другие операции выполняются в терминах объектов, время жизни которых превосходит время жизни отдельной программы.
Языки программирования, как правило, не поддерживают понятия сохраняемости; примечательным исключением является Smalltalk, в котором есть протоколы для сохранения объектов на диске и загрузки с диска. Однако, записывать объекты в неструктурированные файлы - это все-таки наивный подход, пригодный только для небольших систем. Как правило, сохраняемость достигается применением (немногочисленных) коммерческих OODB. Другой вариант - создать объектно-ориентированную оболочку для реляционных СУБД; это лучше, в частности, для тех, кто уже вложил средства в реляционную систему.
Сохраняемость - это не только проблема сохранения данных. В OODB имеет смысл сохранять и классы, так, чтобы программы могли правильно интерпретировать данные. Это создает большие трудности по мере увеличения объема данных, особенно, если класс объекта вдруг потребовалось изменить.
В заключение определим сохраняемость следующим образом:
Сохраняемость - способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.
Как уже говорилось выше, объектная модель принципиально отличается от моделей, которые связаны с более традиционными методами структурного анализа, проектирования и программирования. Это не означает, что объектная модель требует отказа от всех ранее найденных и испытанных временем методов и приемов. Скорее, она вносит некоторые новые элементы, которые добавляются к предшествующему опыту.
Объектный подход обеспечивает ряд существенных удобств, которые другими моделями не предусматривались. Наиболее важно, что объектный подход позволяет создавать системы, которые удовлетворяют пяти признакам хорошо структурированных сложных систем. Согласно нашему опыту, есть еще пять преимуществ, которые дает объектная модель.
Я хотел бы услышать твое мнение про объектная модель Надеюсь, что теперь ты понял что такое объектная модель, инкапсуляция, наследование, полиморфизм , абстрагирование, абстракция, модульность, иерархия, типизация и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Объектно-ориентированное программирование ООП
Комментарии
Оставить комментарий
Объектно-ориентированное программирование ООП
Термины: Объектно-ориентированное программирование ООП