Каким образом обрабатываются объекты в ООП?

Question

[Александр Мартынов]

Понимаю всю красоту ООП. Но камень линейного (функционального, спасибо за поправку) программирования не дает легко соскочить.
Сколько книжек я посмотрел уже по С++, но так и не получил понимания, если я создаю несколько объектов кем и как они управляются.
Поясню суть задачи: имеется ряд данных, из которого при последовательной обработке по определенным правилам выделяется признак для создания объекта, все начальные данные объекта извлекаются из потока, затем объект развивается по нескольким возможным сценариям и в итоге погибает. Однако во время жизни скажем первого объекта могут образоваться еще несколько и они развиваются по тем же правилам и умирают, возможно раньше первого.
Так вот в линейном программировании я должен создать лист "объектов" и цикл по обработке каждого "объекта". Как дело обстоит в ООП, мне нужно также программировать список и работу объектов или достаточно сформировать какое-то событие, действие ну НЕ ПОНИМАЮ ЧТО, чтобы объекты обработали новую порцию данных?
Может кто-то на пальцах пояснить простоту ООП или книгу подскажите не про свойства ООП, а про то как оно работает.

Comments

[acwartz]

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

[Александр Мартынов]

acwartz, Все замечательно, только Вы мне опять виртуально сказали, что сделать но не КАК.
Понимаете, объект родился на скажем десятой порции данных, на 11 он получил какое-то новое свойство, на 12 порции рождается еще один объект, который может быть и получит новое свойство а может и погибнет на 13 порции, при этом первый объект продолжает развиваться. Возможно процесс рождения - модификации - смерти будет отображаться на графике данных, но скорее всего будут тупо генерироваться команды на определенных этапах развития объектов...
Но суть вопроса, после new object как ему передается новая порция данных, чтобы совершился следующий шаг и что вообще должно произойти чтобы этот шаг совершился.
Может быть надо создать фабрику объектов, которая обнаруживает ситуацию лопнувшего яйца и записывает его в свой список, а при новой порции данных не только смотрит не вылупился ли еще какой объект но и вызывает метод обработки данных всех объектов в списке... а зачем тогда ООП, написал структуру с семафором состояния, динамический массив и десяток функций, что работают в соответствии с семафором только это методами линейного программирования, каждое исправление - бег по всему коду... НУ МЫСЛЮ Я ЛИНЕЙНО, потому как не нашел простого описания цикла жизни объекта.

[Александр +]

Александр Мартынов,

вы тащите линейное программирование в ООП, так нельзя.

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

кто-то же всем рулит, пускай это будет менеджер объектов который выделяет память под новые и собственно киляет тех кто попросит об этом. В крестах память управляемая.
Менеджер является event-emitter'ом, т.е. реализует механизм подписок на такие события:
- начало работы > не дает заслать новую порцию данных пока предыдущая не будет сьедена.
- создание объекта - менеджер создает объект и переводит в необходимость обработки.
- смерть объекта - менеджер удаляет объект из памяти или делает его недоступным для обработки.
- мутация - параметр: свойства, менеджер создает объект с указанными новыми свойствами.
- рабочий начал работу
- рабочий начал работу над объектом - параметры: объект
- рабочий обработал объект (параметры: что обработал, какой вердикт и т.д.)
- рабочий закончил работу совсем
- конец работы (порция данных обработана)

Кто занимается работой? Это может быть сам менеджер, а может некий рабочий поток или несколько потоков управляемый опять же менеджером (уже другим, тут уже привет совершенной иной задаче на управление очередями), которые так же является
event-emitter'ом, имеет список запросов которые слушает:
- обработай меня - собственно получив объект рабочий делает некую математику и дергает событие менеджера что бы тот создал нового мутанта, создал копию, кильнул этот объект, и поставил это все в очередь на обработку.
и сам подписан на менеджера дабы уведомлять его о ходе работы.

И собственно сам объект обработки:
- имеет веса которые обсчитываются рабочим и он принимает некоторые решение над этим объектом.
- имеет функцию клонирования с передачей списка свойства родственнику (соотв. выполняет вызов события "мутация").

ничего не решает, просто существует.

Когда завершается шаг? Когда рабочий на очередной итерации по подписчикам, увидит что счетчик ссылок на обработку = 0, уведомит менеджера об этом а тот вызовет событие "работа завершена".

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

Answer 1

[Hemul GM]

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

МояМашина.ПовернутьНалево, а не ПовернутьМашинуНалево(МояМашина).

Классы могут наследоваться. Мы можем иметь список объектов, например список транспорта (например, список будет состоять из объектов велосипедов, самолётов, легковых машин). Сами объекты могут иметь собственные методы, например,

МойВелосипед.ПодтянутьСпицы; МойСамолёт.Приземлиться;

которых нет у других, но могут иметь общие методы, например тот же поворот. И мы можем дать команду всему списку ПовернутьНалево.

цикл для i от 0 до 100 делать СписокТранспорта[i].ПовернутьНалево.

В списке транспорта, как я уже сказал и самолёты и вертолёты, но все они выполнят команду, т.к. все они будут наследоваться от класса Транспорт, который имеет метод ПовернутьНалево.

Comments

[Александр Мартынов]

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

[Hemul GM]

Александр Мартынов, это уже зависит от вашей архитектуры. Цикл может выполняться в отдельном потоке, а каждая команда может быть тоже выполнена в отдельном потоке.
Например, вот так это могло бы выглядеть на Delphi:

TThread.CreateAnonymousThread(
  procedure
  begin
    for var i := 0 to Pred(Items.Count) do
      TThread.CreateAnonymousThread(
        procedure
        begin
          Items[i].TurnLeft;
        end).Start;
  end).Start;

[Александр Мартынов]

Hemul GM, Спасибо еще раз, я работал с Дельфи, Билдером, но решал задачи на уровне функций с использованием граф.интерфейса. Сейчас встала задача и не одна, когда нужно обработать несколько однородных, а в другом варианте разнородных объектов, раньше я делал это на уровне структур, но когда объекта 2 или 3 это не проблема, а вот описать множество объектов и все возможные варианты их свойств и действий ... Надо осваивать ООП. Одна из задач на MQL - индикатор на форекс, при этом терминал работает строго в однопоточном режиме, но думаю если поместить все связанное с объектами в ДЛЛ а оттуда получать только состояния объектов, то получится ускорить за счет многопоточности.

Answer 2

[Adamos]

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

Comments

[Александр Мартынов]

Понимаете, у вас так красиво все звучит на терминах, но я обрабатываю порцию данных в виде потока чисел: упрощенно одно число - одна порция.
Теперь попробую рассказать, что я понял из вашего описания:
парсер - это базовая функция обработки потока, которая находит последовательность чисел - условие для создания объекта;
член - вектор созданных объектов - это массив (список) объектов, ну или ссылок на них если точнее;
имеющих общий интерфейс обхода - это я не совсем понимаю, но по сути это список переменных принимаемых функцией обработки данных в объекте;
метод обхода вектора - по сути цикл, который вызывает функцию обработки данных в объектах из списка, этот цикл вызывается парсером при получении нового числа.
График я имел ввиду графическое отображение потока данных и знаков соответствующих свойствам объектов "живых" и оставивших свои следы мертвых...
я не зря говорил о 3 сценариях, а объектов получается 4 вида:
0 - новый он может переродиться в любой из 3 или умереть;
1,2,3 -выполняет свою последовательность трансформации текущего состояния до гибели.
но у них у всех в принципе одинаковый набор данных (уровни сигнала, причем они определяются еще на стадии нового объекта) и методов: сравнение уровней - изменение состояния и его отображение на графике, а в моменты перехода из состояния в состояние могут формироваться команды они тоже идентичные.
Если я правильно понимаю, это должно как-то не сложно реализовываться.
Подскажите правильно ли я Вас понял, и насколько понятна теперь Вам суть задачи.

[Adamos]

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

[Александр Мартынов]

Adamos, Хорошо, обработка потока ведется с целью обнаружения ситуации когда нужно создать объект, так вот команду на создание объекта выдает парсер, я правильно понимаю, потому что первичная обработка потока вся к этому и сводится,
он же будет родителем для всех объектов?

[Adamos]

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

[Александр Мартынов]

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

[Adamos]

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

[Александр Мартынов]

Adamos, ну вот и возникает потребность не только вниз передавать, но и вверх, чтобы парсер знал, что объект "умер" и его можно освободить...

[Adamos]

Александр Мартынов, скорее всего, достаточно будет флага "мертв, не беспокоить". Если, конечно, у вас не тысячи объектов. Да и если решите все-таки удалять - это опять-таки делается таким флагом и циклом с проверкой снаружи.

[Александр Мартынов]

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

[Adamos]

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

[Александр Мартынов]

Adamos, Вообще для первой задачи это MQL4 - некое подобие С++. А вообще, интересная идея, надо прикинуть! Держать в памяти десяток экземпляров с запасом и по необходимости их использовать, методы то у всех одинаковые места много не потребуют...
Вопрос только встанет в 2 списках: один активных объектов, второй свободных...
Ладно, спасибо, я похоже итак Вас утомил.

[Adamos]

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

Answer 3

[Денис Загаевский]

Никем и никак они не управляются. Конкретно в С++ ты можешь рассматривать объекты как структуры, с привязанными к ним функциями, имеющими неявный аргумент this.

Answer 4

[Mercury13]

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

В ООП точно так же, как в процедурном, и делай; дополнительный вопрос — как быть, если в одном списке могут быть объекты разных типов. Например, можно делать std::vector<std::unique_ptr<SomeBase>>.

Answer 5

[Александр Мартынов]

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