Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Объекты в ООП – это объекты реального мира

Читайте также:
  1. II. Объекты тестирования
  2. Анализ структуры реального потока. Кривая отклика в зависимости от способа введения индикатора.
  3. Бухгалтерский учет, его объекты и основные задачи.
  4. В период инфляции спроса происходит: 1)повышение уровня цен на конечные товары2) уменьшение нормы безработицы3) расширение реального объема производства
  5. В соответствие с теорией предпочтения ликвидности увеличение реального денежного предложения
  6. В-7. Социальные группы как субъекты и объекты политики.
  7. Вещи как объекты гражданских прав
  8. Вещи как объекты гражданских прав и их классификация
  9. Вещи как объекты гражданских прав.
  10. Вещи как объекты гражданских прав. Правовое значение классификаций вещей.

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

Предположим что нам нужно разработать систему автоматизации банка. Эта система могла быть осуществлена следующим образом:

 

Схема взаимодействия объектов

В операции снятия денег через банкомат участвуют 3 объекта: «клиент Иванов», «банкомат на Тверской» и «счет № 66579801″, который открыт в данном банке для Иванова. Подойдя к банкомату и засунув свою карточку, объект «клиент Иванов» посылает банкомату сообщение «Начать работу». Получив такое сообщение, банкомат выводит на экран какую-нибудь информацию и запрашивает код доступа, т.е объект «банкомат на Тверской» посылает сообщение объекту «клиент Иванов» – «Сообщить идентификационный код». Если идентификация прошла успешно, «клиент Иванов» просит выдать ему 1000 рублей. Он посылает сообщение об этом банкомату, а тот в свою очередь объекту»счет № 66579801″. Приняв это сообщение объект «счет № 66579801″ проверяет есть ли у него 1000 рублей, и, если есть, пересылает разрешение на снятие денег, одновременно уменьшая свой баланс на соответствующую сумму. Банкомат передает деньги и на этом процедура заканчивается.

Объекты выполняют необходимые действия передавая друг другу сообщения.

Описание в виде объектов позволяет определить различные компоненты системы. Те же самые объекты – «счет № 66579801″ и «клиент Иванов» – будут учавствовать в другой операции при которой клиент приходит в отделение банка для снятие или зачисления денег на свой счет.

Приведенная ситуация является ярким примером сущности понятия «объект в ООП «. Сложно дать четкое определение этому понятию, приведу цитату этого определения Ивара Якобсона:

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

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

· абстракция понятия: объект – это модель какого-то понятия предметной области;

· абстракция действия: объект объединяет набор операций для выполнения какой-либо функции;

· абстракция виртуальной машины: объект объединяет операции, которые используются другими, более высокими уровнями абстракции;

· случайная абстракция: объект объединяет не связанные между собой операции.

10. Наследование

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

Классы содержат данные и методы. В ООП методы и данные одного класса могут передаваться другим классам, т.е. объекты могут наследовать свойства друг друга. Класс наследует свойства другого класса, обладает теми же возможностями, что и класс, от которого он порожден. Этот принцип называется наследованием (inheritance). Порожденный класс называется потомком (descendant), а тот, от кого он порожден - предком (ancestor). Благодаря новым свойствам, которыми дополняется потомок, порожденный класс может обладать большими возможностями, чем его предок.

Механизм наследования обеспечивает возможность многократного применения программного кода. Таким образом, классы могут быть представлены в виде иерархии. Библиотека VLC (Visual Component Library) в Delphi как раз и является такой иерархической системой классов.

Наследование - механизм, позволяющий объектам класса наследовать характеристики (данные и методы) более простых и общих типов (классов); - средство получения новых классов из существующих.

 

11. Инкапсуляция

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

Инкапсуляция (encapsulation) - объединение данных с функциями, предназначенными для манипулирования этими данными (т.е. поведением) в новом типе - КЛАССЕ.

Пример.
Представьте, что Вам надо написать программу, которая выполняла бы дует духового и струнного инструментов. Для этого определите классы Духовой инструмент и Струнный инструмент. Для класса Духовой инструмент определите, что имеется мундштук и что в него надо дуть, чтоб получить звук. Для класса Струнный инструмент определите, что по струнам надо ударять, чтоб получить звук. Оба класса уже способны "играть музыку", и что это свойство было унаследовано от предка. Они унаследовали метод PlayMusic, который был объявлен и реализован как метод класса Музыкальный инструмент.

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

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

 

12. Полиморфизм

Полиморфизм – это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

Полиморфизм - многоформенность в Си++; механизм, позволяющий использовать одинаковые имена для сходных по смыслу действий и методов, относящихся к различным объектам (типам и классам).
Это означает, что один и то же метод выполняется по разному для различных объектов.
Например, метод класса Музыкальных инструментов - PlayMusicForAnOrchestra - может быть определен как общим метод, который может использоваться с любой категорией инструментов. Этот метод написан таким образом, что не важно, какой именно инструмент получает задание играть, однако для классов, описывающих конкретные инструменты, данный метод должен быть переопределен (override), что даст возможность определить конкретные действия, учитывая особенности конкретного инструмента.

13. Паттерны проектирования

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

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

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

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

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

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

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

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

Некоторые паттерны часто используются совместно. Например, компоновщик применяется с литератором или посетителем. Некоторые пaттepны представляют собой альтернативные решения так, прототип нередко можно использовать вместо абстрактной фабрики. Применение различных пaттеpнoв может привести к одному и тому же проектному решению, хотя изначально их назначение отличается. Например, защищающий заместитель может быть реализован точно так же, как декоратор.

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

14. Порождающие паттерны

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

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

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

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

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

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

 

15. Структурные паттерны

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

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

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

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

 

16. Паттерны поведения

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

В паттернах поведения уровня класса используется наследование - чтобы распределить поведение между разными классами. Из них более простым и широко распространенным является шаблонный метод, который представляет собой абстрактное определение алгоритма. Алгоритм здесь определяется пошагово. На каждом шаге вызывается либо примитивная, либо абстрактная операция. Алгоритм «обрастает мясом» за счет подклассов, где реализованы его абстрактные операции. Другой паттерн поведения уровня класса - интерпретатор, который представляет грамматику языка в виде иерархии классов и реализует интерпретатор как последовательность операций над экземплярами этих классов.

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

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

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

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




Дата добавления: 2015-05-05; просмотров: 51 | Поможем написать вашу работу | Нарушение авторских прав

<== предыдущая лекция | следующая лекция ==>
Безопасность МРТ исследований| ЦЕЛИ И ЗАДАЧИ КУРСОВОЙ РАБОТЫ.

lektsii.net - Лекции.Нет - 2014-2024 год. (0.014 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав