Skip to content

ООП Лекция 02. Основные понятия ООП.

Vladislav Mansurov edited this page Apr 20, 2022 · 8 revisions

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

Совместное использование записей (Хоар):

Один крутой мужик, Чарльз Хоар, в 1966 провёл лекции по совместному использованию записей, выделив, таким образом, базовые понятия ООП:

  1. Если в программе меняется данное, то в структурном подходе мы вынуждены выявить все места, где оно используется и внести изменения в написанный код. Вот прикиньте, какой это объем работы? В ООП мы выносим действие над данным! Это не связка с другими данными! Эта идея называется инкапсуляцией. **Инкапсуляция** - объединение данных и действий над данными. Работа с данными идет только через действие. Пример: работа со структурой File в Qt и других программах. Поля разные, а функции одинаковые.

image

  1. Изменение кода - понижение надежности. Для модификации программных сущностей использовать при возможности надстройку над существующими сущностями. Это наследование - надстройка над тем, что существует (возможность сокрытия/добавления полей/функций). Хоар не выделял это как требование, оно утвердилось позже. Безразличие к тому, что представляет функционал - полиморфизм. Полиморфизм — это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

image

Формирование понятия: данные + действия. Возможность изменения как самих данных, так и надстройки без изменения самих данных.

  1. Перенос взаимодействия из физического мира в программу. Синхронное (accessорное) взаимодействие или асинхронное (событийное) взаимодействие. Синхронное взаимодействие - вызов метода (если объект), функции. Асинхронное взаимодействие - событие произошло, изменение объекта или его состояния произойдут со временем, на уровне ЯП реализовать невозможно. Поддержка должна быть на другом уровне. (Реализация на callback вызове)

Сначала начали реализовывать операционные оболочки. Сейчас это поддерживается на уровне ОС.

Преимущества ООП

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

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

  • Невозможность совмещения этапов проектирования, кодирования, тестирования (что в структурном возможно). Сначала нужно построить начальную модель, потом рекурсивный дизайн, то есть эту модель мы можем развивать.
  • В структурном подходе(СП) порог вхождении очень низкий, то есть вы сразу может начать писать программу используя СП. А что касается ООП порог вхождения выше и это проблема, требуется более высокая классификация программиста.
  • Программист и проектировщик, и кодировщик. Другие требования к квалификации.
  • Размер кода резко возрастает - резко увеличивается время выполнения, объем необходимой памяти увеличивается. Гораздо больше времени тратится на проектирование. В структурном подходе лавинный вызов метода.
  • В СП легко контролировать ресурсы и правила черного ящика(если какая-то функция не может выполниться она не должна захватывать ресурс, при возвращении ресурса ответственность переходит на вызывающую программу). Что касается ООП - задача разбивается на куски, например, если проблема с утечкой памяти, ее определили и выявили место где ошибка, то не всегда можно избавиться от утечки памяти. Раньше в ООП программах были с утечками, сейчас более менее нормально. В принципе с С11 есть механизмы борьбы с проблемами памятью - висящие указатели.
  • Возникновение "мертвого кода"(использую Qt Design не все используется, какие-то классы, члены, методы, характеристики) при модификации. Это занимает место, висит в памяти. Борьба с мертвым кодом - компилируется только тот код, который вызывается.

Примечание: Проблема "мертвого кода" не решается на уровне языка, а решается на уровне среды разработке, на уровне ОС, но в современных она решена! - Решение простое соединить 2 этапа: выполнение и компиляцию, то есть вам что-то понадобилось, вы что-то вызвали, значит это что это можно откомпилировать, а то что не вызывается зачем оно нужно компилировать - КОМПИЛЯЦИЯ НА ЛЕТУ(на лекции ответите уже удивите Тассова). Самое интересное такой подход дает нам колоссальный плюс, например, у вас в программе произошла ошибка надо ее исправлять, как быть, надо остановить программу, исправить ошибку, потом опять запустить. Начальная инициализация программы может занимать много времени - инициализация баз данных, загрузка всех хэше, установка внешних связей, может проходить часами. А вот этот подход нам преимущество исправлять ошибки, не останавливая программу. МОЩНО!!! только в современных языка, С++ использует раздельную компиляцию.

Понятия ООП и объекта:

Три слона, на которых держится наша плоская планета:

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

Понятие объекта

Объект - реализация абстрактного понятия, обладающего:

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

Модель Мура - жизненный цикл объекта??.

На основе возможных состояний будем строить модель состояний - модель Мура

Модель, состоящая по Муру, состоит из:

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

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

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

Категории объектов:

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

Отношения между объектами:

Объекты вступают в отношения...

Выделяют два типа:

  1. Отношение использования (старшинства) - каждый объект включается в такие отношения. Любой объект может играть (выступать в качестве) 3 ролей:
    • Воздействие - объект только воздействует на другие объекты, но сами воздействия не подтверждаются - Активные объекты.
    • Исполнение - объект подвержен воздействию другого объекта, но сам ни на кого не влияет. Пассивные объекты.
    • Посредничество - объект может и воздействовать и исполнять.

Примечание: Посредники будут преобладать - создаются для активных объектов

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

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

Классы

Класс - абстракция множества предметов, которые обладают одними и теми же характеристиками и подчиняются и согласовываются одними и теми же правилами и линиями поведения.

Отношения между классами

  • Наследование.
  • Использование (один использует другой класс).
  • Наполнение или включения (один класс содержит другой).
  • *Метаклассы (используются для создания других классов) - морально устарели, в современных нет такого, встретить можно в старых языках Smalltalk.

Примечание: еще не говорил об отношения между объектами МЕТАОБЪЕКТЫ - поддерживает язык только ЛИСП

  • Домен - отдельный реальный гипотетический(абстрактный) мир, который наполнен отчетливым набором объектов, которые ведут себя в соответствии с определенными доменом правилами и линиями поведения. Домен - связанное единое целое. Программа разбивается на домены в процессе создания. Класс определяется в одном домене. Активный домен - единое целое. Наличие класса в одном домене не требует наличия классов в другом.

Примечание: мы с вами любую задачу будем разбивать на такие домены - миры. Будем использовать в лабораторных - то есть какой либо класс вы определяете только в одном домене, причем наличие этого класс требуют наличие других классов в этом же домене, но не требуют наличие класса в других доменах. Будем разбивать на домены, будет интерфейсный домен и домен само-задач. Вот 1 лабораторная работа сама задача используется структурный подход(четкая эротическая структура - домен задач), а домен интерфейс, к сожалению, мы вынуждены будите использовать подход компонентный (у вас будет форма вы будите эту форму наполнять какими компонентами, задавать свойства, обрабатывать события) - может быть Qt design или что-то другое.

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

Например, Вуз Бауманский можно считать доменом, населенный объектами. У нас свой мир, свои законы и отношения между объектами.

Clone this wiki locally