Но я бы не советовал путать организационную locality, такую как она существует в тексте ОО-программ и реальную, физическую, ибо современные реализации ОО ЯВУ, компиляторы, операционные системы и форматы исполняемых модулей организованы так, что тела методов (код процессора) лежат в одном месте, vmt лежат во втором месте, и память для полей объектов выделяется из кучи или на стеке. Хотя в целом определенные выгоды от локальности (без предпринимаемых усилий) могут наблюдаться здесь и на физическом уровне. Хотя в большинстве случаев типичная, неконтролируемая ОО-реализация напротив, имеет худшие характеристики, если не предпринято иное (например пулирование объектов). Подчеркиваю, именно реализация, так как в самой объектной парадигме ничего такого нет, и если бы hardware было бы построено с учетом ОО, это можно было бы эффективно использовать.
Наконец, есть еще одна причина для возникновения и существования ООП. Каждый, кто мастерил системы, будь то летающие, ездящие или плавающие поделки, электронные конструкции или хотя бы конструктивы из Lego — мог заметить, протяженная в пространстве, развесистая, конструкция всегда имеет проблемы с устойчивостью и надежностью. Протяженные, разделенные на части конструкции хливки и ненадежны. И напротив, конгломераты, композиты, всё сконцентрированное, сгруппированное (не только в пространстве, но и во времени или даже в псевдопространствах каких-л. атрибутов и свойств) — обладает сравнительно большей надежностью и рядом замечательных свойств. Пример — шар. В целом это принцип локальности, вытекающий из физического близкодействия, или что то же самое, принципа минимизации действия, сохранения энергии или базовой т.н. «симметрии» мира.
В ООП наблюдается data и code locality, образующие один объект. Но эта локальность сугубо организационно-текстового характера, или говоря иначе, психологический, организационный аспект для инженера и программиста. Также, можно сказать что она образует «системообразующий» фактор, но это снова проявляется лишь на бумаге, т.е. при взаимодействии человек-машина. Системы подчиняющиеся какой-либо симметрии и локальности обладают меньшей системной энтропией, что и обуславливает их определенные преимущества.
Благодарю за хорошее замечание. Вообще говоря, я не ставил перед собой вопроса «что и как нужно изучать студенту». Хорошим анти-примером что сегодня можно «изучить» служит вся эта статья, весь этот материал с попыткой осмысления что же такое есть ООП. При всем моем уважении к автору, его понятия все еще ммм… далеки от идеала. Скорее, это некое первичное приближение, попытка осмысления сути.
Студенты студентам рознь.
В общеобразовательных российских заведениях студенты готовятся именно так, как вы считаете нужным — бессмысленно натаскиваются на зубрёжку формул и определений. Ведь именно это будут у них спрашивать на экзамене, верно? Так происходит подготовка людей общей специальности. И только в ограниченном числе ВУЗ'ов, на отдельно взятых кафедрах готовят ученых-исследователей, тех кто будет открывать новые законы, устанавливать новые закономерности и т.д. У подобных студентов в курс обязательно входит литература по истории предмета. Обычным студентам это не дают или дают очень ограниченно. Также, историю развития и взгляды основоположников всегда очень тщательно и скурпулезно изучают в старейших университетах мира — Кембридже, Оксфорде, это не говоря о том порой сами лекции там можно услышать из уст самих «основоположников».
Так что это каждому решать. Или получить бросовое, поверхностное образование для того чтобы влиться в армию работяг. Или изучать всё исторически — с неких первопричин и предпосылок. Я думал что последнее будет интересно, почему и поделился. Еще раз, благодарю за комментарий.
Аналогии задействованные автором и смешение их в кучу в таком виде — порочный путь. Как это ни прискорбно, следует признать — хорошего материала, проясняющего суть ООП всё же до сих пор нет. Причем, работа при написании такой статьи/книги будет весьма интересная — предстоит прояснять как бы в целом известные и даже до определенной степени представимые понятия, но в ином ключе, направляя мысль в другом направлении. Занятие это очень неблагодарное и его ценят лишь те люди, которые действительно хотят разобраться, до последней тонкости. Большинство, к сожалению, реагирует «мне это было известно», «это очевидно» а то и хуже — начинают спорить, отстаивая свою точку зрения лишь потому что она у них устоялась или была усвоена первой.
Первое, что тут надо сделать, отделить все смешанное в кучу, выделить смысловое ядро и все вращающиеся вокруг него посторонние сущности. Например композиция, агрегация, ассоциация — это, вообще говоря, уже вторичные понятия, к самому ООП отношения не имеющие, а относящиеся к конструированию объектных систем.
Статические члены, виртуальные методы, абстрактные классы, интерфейсы — это сугубо вспомогательные приемы, к сути ООП отношения не имеющие (в C++ интерфейсы вообще отсутствуют).
Дальнейшее может показаться кощунственным, но даже понятия класса и наследования не являются базовыми в ООП, будучи лишь вспомогательным. Это так потому что в некоторых языках устойчивых выделенных классов реально не существует — их можно в любой момент собрать прямо на лету, переустановить и модифицировать методы, в любой момент добавить новые, при этом новые объекты порождаются не инстанцированием класса, а методом клонирования существующих объектов.
Тогда что такое ООП? Согласно названию — это программирование на основе объектов. Звучит тривиально и тавтологически, но это так. Что такое «объекты» в самой своей сути, как они должны пониматься — было описано выше, объекты, как нам прояснили авторы первого объектно-ориентированного языка Simula, это самостоятельные, самодостаточные (закрытые) программы (общающиеся между собой — это важно!). Программа же, и это понятно, содержит код и (опционально) состояние, т.е. данные. Понимание этой мысли, насчет «самостоятельных программ» — отправная точка для понимания всего ООП, проектирования ОО-программ, популярности ООП как таковой, а также вытекающих отсюда как само собой разумеющееся, принципов information hiding и separation of concerns. Понятие «общения» объектов-программ между собой автоматически влечет понятия протокола и интерфейса.
Теперь о еще одной причине возникновения ООП.
Программирование порождает проблемы не только в вычислениях и в алгоритмах, но и при самой инженерии больших программных систем. Это тот момент, который трудно понять не только начинающим, но и просто большинству людей, так как многим не довелось работать в коллективах в которых программные системы создаются годами и десятилетиями. И это тот же момент, почему в конце 80х-начале 90х ООП подход был прохладно принят в нашем отечестве. Дело в том, что масштабы систем, за редким исключением были разные, наши люди работали либо в одиночку, либо малыми коллективами из 3х-5ти человек, где наиболее насущна потребность скорее все еще в отдельных подпрограммах (процедурах и функциях), нежели чем в отдельных, самостоятельных программах (т.е. объектах). Верно и обратное, достаточно легко представить себе коллектив из 3х-5ти человек, работающий над некоторым программным решением. (Типичная ситуация большинства фирм и НИИ как в 70е-90е, так и по сей день). Но вот когда дело доходит до коллективов хотя бы из 50-ти человек (не говоря уже о смене людей за годы разработки), вот тут-то дело и становится тухлым. Стоит лишь представить себе что вся эта огромная толпа народа постоянно копошится в гигантской куче переменных, процедур и функций, как становится понятно, что все это добром не кончится. :) Приходится или прикладывать изрядные усилия, или всё достаточно быстро превращается в невообразимое месиво. Это происходит чисто статистически, по законам развития систем.
Вот почему на определенном этапе возникла необходимость перехода на более крупные управляемые единицы, нежели чем отдельные процедуры и переменные. Наиболее адекватно было создавать, контролировать и обмениваться уже готовыми, протестированными и документированными программами. А выше упоминалось что это по своей сути и есть объекты, Simula для них и создавалась (ну или для современного понимания более адекватно будет называть их классами). Это один из факторов успеха ООП.
Конечно, можно возразить что многие очень крупные системы написаны без объектно-ориентированного подхода. Но если очень внимательно приглядеться, то то, как они написаны напоминает ООП-подход. К примеру, код крупных операционных систем написан небольшими, отдельно компилируемыми модулями, каждый со своими приватными переменными (в точности также как объект) и каждый со своим заголовочным файлом, содержащим «интерфейс» к этому модулю, что представляет собой аналог класса с объявленными в нем методами. Существует и своего рода «наследование», только не статически, в момент компиляции, а динамически, на уровне run-time библиотек. Если требуется унаследоваться, может быть написана новая динамически загружаемая библиотека-плагин, которая содержит новую функциональность, и которая, в свою очередь, делегирует к старым, уже написанным и подгружаемым библиотекам. Это не хак и не костыль, а самое настоящее наследование, имеющее своей сутью композицию, делегацию и перенесенное на уровень исполнения. Также на ум приходит Microsoft COM, своеобразный run-time аналог ООП.
Моя задача была привить правильное (с моей точки зрения) понимание что такое ООП в самой своей сути. Подчеркну, ООП — это метод организации программных текстов, или способ написания программ, состоящих в свою очередь из небольших изолированных, функционально самостоятельных и законченных программ. Эти программы называются «объекты» (сейчас с этим пониманием более ассоциируются классы, но как выше было замечено, классы далеко не всегда присущи ОО-системам). При этом важно обратить внимание на общение этих своеобразных «программ», откуда проистекает необходимость в определении протоколов общения, откуда, в свою очередь автоматически вытекает понятие интерфейса. Как видно, все связано, всё объяснимо, и когда мы сталкиваемся с некими абстракциями, типа data hiding — мы их воспринимаем уже не как «тайное знание», а как вполне очевидную и объяснимую вещь. Ну, если, конечно, достаточно глубоко задумываться над смыслом всех прозвучавших слов и если ознакомиться с упомянутым выше «Some features of the Simula 67 language».
В этом заключается на мой взгляд первичный, самый базовый корень ООП. И если не понимать суть ООП достаточно четко, то можно даже писать программы с классами, можно отщелкивать и вроде бы даже на каком-то уровне понимать отдельные концепты.
Но согласитесь, когда мы четко знаем «а почему это», «а зачем оно», «а как появилось», «а как к этому пришли» всё же становится гораздо легче. А как неоднократно уже говорилось, программист только тогда получает удовольствие и все делает быстро и без ошибок — когда он абсолютно четко понимает, что он делает. Там же где программист имеет некоторый туман и недопонимание, там жди беды — там будут и баги и вообще, это корень всех зол. Так что с новым годом, товарищи и давайте выпьем за полное понимание :)
У Dan Luu довольно спорный метод измерения latency. «Custom Haswell» или «MacBook» — это очень произвольные обобщения. На современных компьютерах latency очень сильно зависит от software и от режима его работы. Например, для компьютера под управлением windows следует a) Использовать DirectInput (причем устройство устройству, разумеется, рознь — скажем, джойстик на игровом порте будет иметь минимальный лаг). б) Использовать exclusive экранный вывод средствами DirectX — это даст минимальный latency даже под Windows. Разумеется, если загрузить машину даже не под реалтайм-операционкой, а всего-то под старым, добрым DOS, наваяв собственный exe/com — это даст минимальный Latency, но я хочу объяснить почему метод выбранный Dan Luu не очень хорош.
Первое, от чего зависит Latency вывода на экран, это частота кадровой развертки видеосигнала. При частоте кадров 60Hz имеем возможный latency от начала к концу кадра 1/60=16мс. При частоте кадров 120Hz он уменьшается до 8мс.
Внутренний буфер кадра ЖК-монитора запросто может дать еще задержку на кадр, что даст еще 1/60 = 16мс. Поэтому измерять задержку видео-камерой то еще занятие.
В случае windows источником задержки служит дополнительный буфер композиции у менеджера композиции десктопа (dwm.exe). Aero даст большую задержку, нежели чем его отсутствие — весь вывод через Aero принудительно буферизуется во избежание tearing.
DoubleBuffering или Page Flipping видеокарты даст 1/60 = 16мс.
И это только вывод. Если вся система так или иначе буферизует 3 кадра (скажем, 1 кадр монитор, 1 кадр page flipping видеокарты, 1 кадр Desktop Composite Manager), то одно только это уже дает 1/60*3=50мс.
Это далеко не единственный источник задержки в системе. Конечно, существуют переключения контекста операционной системы, прерывания, буферы драйверов, итд, итп — все это отдельный разговор. Моя задача была показать что способ измерения latency посредством съемки на камеру не очень подходящая метода для того чтобы делать далеко идущие выводы о latency обновления экрана современных устройств. Необходимо знать о внутренних буферах, о их необходимости, и о режимах работы в которых задержка минимальна.
Понять и объяснить что такое объектно-ориентированное программирование, лучше всего изучив историю возникновения предмета. В этом плане рекомендую классику — «some features of the simula 67 language». Когда читаете, следует обратить внимание на некоторые аспекты, остающиеся за кадром. Симула (что понятно даже исходя из названия) предназначалась для построения симуляторов некоторой предметной области. Для симуляции требовались небольшие самостоятельные взаимодействующие программки. Это и были self-containing program или как они иначе называются «объекты». Именно так. Объекты — вообще-то самостоятельные (замкнутые, самодостаточные, автономные, изолированные) программы. Это напрямую написано в документе «some features of the simula 67 language», почему я и говорю — начинать изучение чего-либо с первооснов самое благое дело.
Внутри компьютера такого устройства конечно не было (не так оно и сейчас — данные отдельно, а методы объектов как были старыми, добрыми процедурами, так и остались). Но для программиста организация программы выглядела как отдельные, активные блоки программ, «данные с кодом» или «активные данные», «данные с активностью» (data + activity). Несмотря на внешнее представление, всегда полезно помнить — ООП это лишь способ организации текста программы и не более того (хотя найдутся те кто будет протестовать, увы, это так). ООП можно «симулировать» в процедурных языках, создавая структуры (записи, пакеты, кортежи) данных и семантически связанные с ними функции. Полезно также заметить, что Страуструп, создавая C++ был занят в большом проекте симулятора, вот почему он обратил внимание на Simula и вот почему он столкнулся с объектно-ориентированной парадигмой вообще. Прикручивать объекты к Cи они решили после того как Garbage-collected симула их не устроила. Поэтому они стали прикручивать объекты к относительному быстрому системному Си. Первое расширение языка Си так сначала и называлось «Си с классами». Также полезно знать, как они это сделали — они не писали новый компилятор вообще. Они написали транслятор расширения языка в старый добрый Си, тексты которого компилировались исходно существующим компилятором cpre. И это само по себе говорит о многом о ООП. Грубо говоря, на входе заходил синтаксис в котором у структуры были приписаны функции, а на выходе выходил обычный текст си-программы, где были старые добрые структуры (с данными) и отдельно — функции для работы с ними. Отсюда мы видим — что ООП это вовсе несколько не то, что принято объяснять. ООП в исходном своем понимании, это прежде всего объекты, где объекты это полноценные изолированные программы. Эти программы также могут пониматься как «активные данные», получающие процессорное время отведенное в оригинале на симуляцию. И, соответственно, в исходной симуле внутренний «мир» состоял из таких вот самостоятельных программ-объектов, взаимодействующих и существующих параллельно. Так я рекомендую понимать ООП-программу и вам, потому что так оно без изменений сохранилось и сейчас. Такова самая-самая суть ООП, та самая, почему оно возникло.
В ООП наблюдается data и code locality, образующие один объект. Но эта локальность сугубо организационно-текстового характера, или говоря иначе, психологический, организационный аспект для инженера и программиста. Также, можно сказать что она образует «системообразующий» фактор, но это снова проявляется лишь на бумаге, т.е. при взаимодействии человек-машина. Системы подчиняющиеся какой-либо симметрии и локальности обладают меньшей системной энтропией, что и обуславливает их определенные преимущества.
Студенты студентам рознь.
В общеобразовательных российских заведениях студенты готовятся именно так, как вы считаете нужным — бессмысленно натаскиваются на зубрёжку формул и определений. Ведь именно это будут у них спрашивать на экзамене, верно? Так происходит подготовка людей общей специальности. И только в ограниченном числе ВУЗ'ов, на отдельно взятых кафедрах готовят ученых-исследователей, тех кто будет открывать новые законы, устанавливать новые закономерности и т.д. У подобных студентов в курс обязательно входит литература по истории предмета. Обычным студентам это не дают или дают очень ограниченно. Также, историю развития и взгляды основоположников всегда очень тщательно и скурпулезно изучают в старейших университетах мира — Кембридже, Оксфорде, это не говоря о том порой сами лекции там можно услышать из уст самих «основоположников».
Так что это каждому решать. Или получить бросовое, поверхностное образование для того чтобы влиться в армию работяг. Или изучать всё исторически — с неких первопричин и предпосылок. Я думал что последнее будет интересно, почему и поделился. Еще раз, благодарю за комментарий.
Первое, что тут надо сделать, отделить все смешанное в кучу, выделить смысловое ядро и все вращающиеся вокруг него посторонние сущности. Например композиция, агрегация, ассоциация — это, вообще говоря, уже вторичные понятия, к самому ООП отношения не имеющие, а относящиеся к конструированию объектных систем.
Статические члены, виртуальные методы, абстрактные классы, интерфейсы — это сугубо вспомогательные приемы, к сути ООП отношения не имеющие (в C++ интерфейсы вообще отсутствуют).
Дальнейшее может показаться кощунственным, но даже понятия класса и наследования не являются базовыми в ООП, будучи лишь вспомогательным. Это так потому что в некоторых языках устойчивых выделенных классов реально не существует — их можно в любой момент собрать прямо на лету, переустановить и модифицировать методы, в любой момент добавить новые, при этом новые объекты порождаются не инстанцированием класса, а методом клонирования существующих объектов.
Тогда что такое ООП? Согласно названию — это программирование на основе объектов. Звучит тривиально и тавтологически, но это так. Что такое «объекты» в самой своей сути, как они должны пониматься — было описано выше, объекты, как нам прояснили авторы первого объектно-ориентированного языка Simula, это самостоятельные, самодостаточные (закрытые) программы (общающиеся между собой — это важно!). Программа же, и это понятно, содержит код и (опционально) состояние, т.е. данные. Понимание этой мысли, насчет «самостоятельных программ» — отправная точка для понимания всего ООП, проектирования ОО-программ, популярности ООП как таковой, а также вытекающих отсюда как само собой разумеющееся, принципов information hiding и separation of concerns. Понятие «общения» объектов-программ между собой автоматически влечет понятия протокола и интерфейса.
Теперь о еще одной причине возникновения ООП.
Программирование порождает проблемы не только в вычислениях и в алгоритмах, но и при самой инженерии больших программных систем. Это тот момент, который трудно понять не только начинающим, но и просто большинству людей, так как многим не довелось работать в коллективах в которых программные системы создаются годами и десятилетиями. И это тот же момент, почему в конце 80х-начале 90х ООП подход был прохладно принят в нашем отечестве. Дело в том, что масштабы систем, за редким исключением были разные, наши люди работали либо в одиночку, либо малыми коллективами из 3х-5ти человек, где наиболее насущна потребность скорее все еще в отдельных подпрограммах (процедурах и функциях), нежели чем в отдельных, самостоятельных программах (т.е. объектах). Верно и обратное, достаточно легко представить себе коллектив из 3х-5ти человек, работающий над некоторым программным решением. (Типичная ситуация большинства фирм и НИИ как в 70е-90е, так и по сей день). Но вот когда дело доходит до коллективов хотя бы из 50-ти человек (не говоря уже о смене людей за годы разработки), вот тут-то дело и становится тухлым. Стоит лишь представить себе что вся эта огромная толпа народа постоянно копошится в гигантской куче переменных, процедур и функций, как становится понятно, что все это добром не кончится. :) Приходится или прикладывать изрядные усилия, или всё достаточно быстро превращается в невообразимое месиво. Это происходит чисто статистически, по законам развития систем.
Вот почему на определенном этапе возникла необходимость перехода на более крупные управляемые единицы, нежели чем отдельные процедуры и переменные. Наиболее адекватно было создавать, контролировать и обмениваться уже готовыми, протестированными и документированными программами. А выше упоминалось что это по своей сути и есть объекты, Simula для них и создавалась (ну или для современного понимания более адекватно будет называть их классами). Это один из факторов успеха ООП.
Конечно, можно возразить что многие очень крупные системы написаны без объектно-ориентированного подхода. Но если очень внимательно приглядеться, то то, как они написаны напоминает ООП-подход. К примеру, код крупных операционных систем написан небольшими, отдельно компилируемыми модулями, каждый со своими приватными переменными (в точности также как объект) и каждый со своим заголовочным файлом, содержащим «интерфейс» к этому модулю, что представляет собой аналог класса с объявленными в нем методами. Существует и своего рода «наследование», только не статически, в момент компиляции, а динамически, на уровне run-time библиотек. Если требуется унаследоваться, может быть написана новая динамически загружаемая библиотека-плагин, которая содержит новую функциональность, и которая, в свою очередь, делегирует к старым, уже написанным и подгружаемым библиотекам. Это не хак и не костыль, а самое настоящее наследование, имеющее своей сутью композицию, делегацию и перенесенное на уровень исполнения. Также на ум приходит Microsoft COM, своеобразный run-time аналог ООП.
Моя задача была привить правильное (с моей точки зрения) понимание что такое ООП в самой своей сути. Подчеркну, ООП — это метод организации программных текстов, или способ написания программ, состоящих в свою очередь из небольших изолированных, функционально самостоятельных и законченных программ. Эти программы называются «объекты» (сейчас с этим пониманием более ассоциируются классы, но как выше было замечено, классы далеко не всегда присущи ОО-системам). При этом важно обратить внимание на общение этих своеобразных «программ», откуда проистекает необходимость в определении протоколов общения, откуда, в свою очередь автоматически вытекает понятие интерфейса. Как видно, все связано, всё объяснимо, и когда мы сталкиваемся с некими абстракциями, типа data hiding — мы их воспринимаем уже не как «тайное знание», а как вполне очевидную и объяснимую вещь. Ну, если, конечно, достаточно глубоко задумываться над смыслом всех прозвучавших слов и если ознакомиться с упомянутым выше «Some features of the Simula 67 language».
В этом заключается на мой взгляд первичный, самый базовый корень ООП. И если не понимать суть ООП достаточно четко, то можно даже писать программы с классами, можно отщелкивать и вроде бы даже на каком-то уровне понимать отдельные концепты.
Но согласитесь, когда мы четко знаем «а почему это», «а зачем оно», «а как появилось», «а как к этому пришли» всё же становится гораздо легче. А как неоднократно уже говорилось, программист только тогда получает удовольствие и все делает быстро и без ошибок — когда он абсолютно четко понимает, что он делает. Там же где программист имеет некоторый туман и недопонимание, там жди беды — там будут и баги и вообще, это корень всех зол. Так что с новым годом, товарищи и давайте выпьем за полное понимание :)
И это только вывод. Если вся система так или иначе буферизует 3 кадра (скажем, 1 кадр монитор, 1 кадр page flipping видеокарты, 1 кадр Desktop Composite Manager), то одно только это уже дает 1/60*3=50мс.
Это далеко не единственный источник задержки в системе. Конечно, существуют переключения контекста операционной системы, прерывания, буферы драйверов, итд, итп — все это отдельный разговор. Моя задача была показать что способ измерения latency посредством съемки на камеру не очень подходящая метода для того чтобы делать далеко идущие выводы о latency обновления экрана современных устройств. Необходимо знать о внутренних буферах, о их необходимости, и о режимах работы в которых задержка минимальна.
Внутри компьютера такого устройства конечно не было (не так оно и сейчас — данные отдельно, а методы объектов как были старыми, добрыми процедурами, так и остались). Но для программиста организация программы выглядела как отдельные, активные блоки программ, «данные с кодом» или «активные данные», «данные с активностью» (data + activity). Несмотря на внешнее представление, всегда полезно помнить — ООП это лишь способ организации текста программы и не более того (хотя найдутся те кто будет протестовать, увы, это так). ООП можно «симулировать» в процедурных языках, создавая структуры (записи, пакеты, кортежи) данных и семантически связанные с ними функции. Полезно также заметить, что Страуструп, создавая C++ был занят в большом проекте симулятора, вот почему он обратил внимание на Simula и вот почему он столкнулся с объектно-ориентированной парадигмой вообще. Прикручивать объекты к Cи они решили после того как Garbage-collected симула их не устроила. Поэтому они стали прикручивать объекты к относительному быстрому системному Си. Первое расширение языка Си так сначала и называлось «Си с классами». Также полезно знать, как они это сделали — они не писали новый компилятор вообще. Они написали транслятор расширения языка в старый добрый Си, тексты которого компилировались исходно существующим компилятором cpre. И это само по себе говорит о многом о ООП. Грубо говоря, на входе заходил синтаксис в котором у структуры были приписаны функции, а на выходе выходил обычный текст си-программы, где были старые добрые структуры (с данными) и отдельно — функции для работы с ними. Отсюда мы видим — что ООП это вовсе несколько не то, что принято объяснять. ООП в исходном своем понимании, это прежде всего объекты, где объекты это полноценные изолированные программы. Эти программы также могут пониматься как «активные данные», получающие процессорное время отведенное в оригинале на симуляцию. И, соответственно, в исходной симуле внутренний «мир» состоял из таких вот самостоятельных программ-объектов, взаимодействующих и существующих параллельно. Так я рекомендую понимать ООП-программу и вам, потому что так оно без изменений сохранилось и сейчас. Такова самая-самая суть ООП, та самая, почему оно возникло.