Феерично про "ООП".

А. Г., ООП это просто сам принцип построения программы. Недостаток ООП в том, что его везде пихают, где надо и не надо, но оно на самом деле дает выигрыш не во всех задачах.

Лузер, ну это все «ложиться» и в вышеуказанную мной парадигму: «программа-подпрограмма-библиотека»

Лузер,  в части «машинного обучения» я имел ввиду не мощности компов, а алгоритмическую сторону вопроса.

Лузер, ну так у ложного применения алгоритма к бОльшему массиву данных ничего, кроме ложной подгонки не получишь. И возвращаемся к исходной точке: работоспособности алгоритма для решения априорной задачи. А мощность компа к решению этой задачи имеет очень отдаленное очень отдаленное отношение.

А. Г., Тут конечно, надо заметить, что ООП — понятие не особо однозначное, но корни идут из определения Алана Кея:

1. EverythingIsAnObject.

 

2. Objects communicate by sending and receiving messages (in terms of objects).

 

3. Objects have their own memory (in terms of objects).

 

4. Every object is an instance of a class (which must be an object).

 

5. The class holds the shared behavior for its instances (in the form of objects in a program list)

 

6. To eval a program list, control is passed to the first object and the remainder is treated as its message.

wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Конечно, далеко не все языки, которые сейчас принято относить к ООП это все имеют, но, идеи таковы.

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

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

Вообще, ООП — это не столько о программировании в смысле написания кода, сколько о проектировании и построении абстракций.

Лузер, Я, честно говоря, даже отдаленно не понял, что хотел сказать автор того поста, поэтому, я тут, пожалуй, с Вами соглашусь

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

sortarray sortarray, ну так и логика «программа-подпрограмма-библиотека» не о написании кода, а о построении сложных проектов с возможностью использования однажды написанных кодов в разных проектах. И известна с 80-х, как минимум. Зачем «огород городить»? Что нового с этой точки зрения? Не понимаю.

А. Г., я заранее прошу прощения, если ответ покажется путанным, нетрезв:) Помогал другу с переездом и выпили в итоге:)

Представьте себе такой пример. У вас есть некий Account, с интерфейсом withdraw и deposit, ну, это классика:) Представьте теперь, что есть два потока, которые меняют состояние аккаунта. Пусть они меняют его также, примерно, как, скажем происходит инкремент на низком уровне работы с памятью. Пусть текущий баланс 10 баксов. Процесс1 считывает из памяти текущий баланс. после этого процесс2 тоже считывает его же. Пусть процесс1 хочет положить на счет 10 баксов. Он прибавляет к считанному значению 10, и записывает то что у него получилось обратно в аккаунт. В это время, процесс 2 прибавляет к считанному значению, скажем, 20 баксов, и записывает результат в аккаунт. Итого, у нас было 10 баксов, мы положили 30 баксов, в итоге наш баланс увеличился на 20 баксов:) Это не совсем то что мы хотели сказать:) Это можно решить блокировками, которые порождают другие проблемы, и мы приходим к уродливой архитектуре, когда решение одной проблемы порождает кучу других(например дедлоки, голодание etc)

Теперь представьте, что аккаунт сам себя модифицирует, а внешние объекты только посылают ему сообщения с «командами» на модификацию. В том случае, проблем просто не возникает.

Вот это, на пальцах, только лишь одна из множества проблем, которые решает ООП-подход.

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

Как то так:)

sortarray sortarray, ну то, что Вы описали — это задача многозадачности, которая была решена еще на 3-й винде для С++ безо всяких «классов» и прочих новомодных синтаксических обозначений. А задача динамического распределение памяти решалась на С++ и под старым MS-DOS. Я понимаю, что графические библиотеки с тех пор сделали огромный шаг вперед, но опять же — это библиотеки. И для математика импликация «подрограмма=функция» гораздо понятнее, чем всякие «классы», «подклассы». Чем упростили то для алгоритмистов (не кодеров)?

А. Г., дело не в том, что решено, а что нет, а в том как это решено, изящно, красиво, элегантно, просто, или уродливо и шизофренично.

И для математика импликация «подрограмма=функция» гораздо понятнее, чем всякие «классы», «подклассы

вообще, подпрограмма != функция. Функция в математическом смысле — это отображение, а не подпрограмма. Это, кстати говоря, приводит к еще бОльшей путанице.

И да, математику к программированию лишний раз притягивать за уши не стоит без нужды:) Математика — это «что» а программирование — это «как». Это две разных вселенных:)

sortarray sortarray, эта «возня» с ООП напоминает мне моду на «нечеткую логику», которую выдавали за новую науку. Скуки ради я с легкостью переформулировал пару примеров из книги по «нечеткой логике» в терминах вероятностного пространства и получилось, что это частные задачи теории вероятностей, правда лежащие за рамками вузовского курса теории независимых одинаково распределенных случайных величин, которую читают в ВУЗах в рамках курса под названием «теория вероятностей»

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

Андрей К, создавать блок-схемы алгоритмов с взаимосвязями лично меня учили полгода ДО изучения любого из языков программирования. Это начало 80-х годов прошлого века. Что нового? Вот в чем вопрос.

А. Г.,+++ 
А фактически с того времени мало, что придумали.
Если хочешь создать, что то реально работающее — нарисуй блок-схему.

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

Высоко эффективный код я всегда сяду писать на низком уровне. Но масштабные задачи, обслуживающие трейдинг (логирование, мониторинг, БД и тд) я никогда не сяду писать с низкого уровня — это рассадник багов, которые придется устранять гораздо дольше. Модульное программирование, которое вы приводите в пример, это ниже уровнем чем ООП.

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

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

А. Г., 5 минут. Я приведу вам хороший пример.

А. Г., разберем такой случай. 

В программирование существует понятие — атомарная операция — это операция над переменными, в процессе которых, никакой другой поток программы не может вмешаться в это процесс.

Ну например. У меня есть байт:

char n;

В одном потоке я делаю

n = 1;

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

Еще со времен 486 процессоров, интел научился делать простейшие операции атомарно (сложение, вычитание, инкремент и тд) через спец ассемблерные инструкции (проц просто лочит память).

Разработчики на Си быстро оборачивали эти ассемблерные вставки в процедуры и работали. Потом в Cи 11 стандарта уже появились встроенные функции в стандартные библиотеки, уже не надо было ничего придумывать, а в Cи++ 11 стандарта появились классы, реализующие тоже самое.

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

__sync_fetch_and_add (&n, 5);

он нечайно может написать

n = n +5;

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

atomic_n 

чтобы не притуплялось внимание. Но это может не помочь.

Класс в данном случаен сильно спасает. Мы можем обернуть эту переменную в класс, закинуть ее в private видимость и работать с ней через методы класса, полностью исключая возможные ошибки кода.

Да, на этом мы теряем наносекунды, но приобретаем стабильность кода.

Вышеизложенные примеры с ошибками кода привожу из примера опытных программистов, создающих большое приложение.

Андрей К, и это называется «упрощением кода»? :)

Класс в данном случаен сильно спасает. Мы можем обернуть эту переменную в класс, закинуть ее в private видимость и работать с ней через методы класса, полностью исключая возможные ошибки кода.

А. Г., Александр, про упрощение кода я ни разу не говорил в нашей дискуссии. 

А. Г., в данном случае скорее на любителя. Немного поразмыслив, я не смог однозначно для себя ответить, упростится ли код для меня или нет. Возможно и нет.

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

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

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

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

MixStyleTrader, в С++ и С# лично я увидел только усложнение синтаксиса по сравнению с обычным использованием библиотек.

А. Г., может быть не всегда удачная реализация библиотек.

Например удобна возможность в игре перебрать по циклу сразу все «живые» объекты и переместить их (метод move). И притом в реальности вместо метода move будут применяться разные подпрограммы, в зависимости от конкретного объекта.

А. Г., знаете, люди которые пишут софтины под микроконтроллеры, тоже не понимают чем же хорош подход ООП и главное как его применять, но им и не надо. Так же и тут, те кто не знает зачем и не сталкивается с задачами которые ему нужно решать именно через ооп, врдяли примет то что такой подход может быть более удобным. А любой софт можно и в машинных кодах описать :).

зы. Не понять отчего автор сего топика с таким упоением что то кому то пытается доказать…

А. Г., странно что вам тут никто не рассказал про STL, например. 
такие штуки, как перегрузка операторов, виртуальные методы, полиморфизм.
что такое класс, технически? указатель на структуру, и таблицу виртуальных функций. 
т.е. да, можно реализовать и с помощью отдельно существующей структуры, функций, указателей на функции и таблицы.
но зачем.

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

я очень люблю классы. их на самом деле придумали уже достаточно давно, это скажем так, далеко не передний край. вообще программирование сейчас очень быстро двигается, хотя этого и не очень заметно. стандарты C++, Java — очень часто обновляются, народ чего-то генерит со страшной силой.
соблазн остаться со старыми знаниями есть.
но мне нравится статья на тему https://habrahabr.ru/company/infopulse/blog/275951/

ПBМ, сколько новых для меня непонятных определений (кроме понятия «класс») :). Убейте не понимаю, что значит с точки зрения алгоритмиста «виртуальная функция». Пойтиме, Вы разговариваете с человеком, который научился только хорошо создавать блок-схемы алгоритмов и реализовывать их в коде на С++ или С#. Более ничего я не знаю. И хочу понять, чем мне может помочь ООП при реализации какой-нибудь блок-схемы. В какой блок-схеме приниципиален тот же «полиморфизм», а «виртуальные функции» лучше обычных библиотек?

А. Г., вы просто самим вопросом сужаете возможность ответить.
типа, как ну, скажите, зачем мне мясорубка, если я итак пожарю мясо на сковороде, и убейте, но я не понимаю, что такое котлета.

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

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

вот из таких «классов» состоит STL — библиотека стандартных шаблонов.

ПBМ, и опять не понял, чем это лучше созданной для этой цели библиотеки функций.

А. Г., я как-то не заметил что мы перескочили из «что нового» в «чем это лучше».
с учётом того что ООП очевидно создавался для людей, как и функциональные языки, то очевидно что это во многом вкусовщина.
для меня лично ООП стал поворотной точкой, я действительно считаю что он позволяет лучше управлять кодом и структурировать его в голове.
последние три месяца изучаю ядро линукс/андроид, вот там всё чистый C, никакого ООП. и надо сказать, конечно всё понятно, ну, почти, вот только очень и очень разбросано/размазано и тп.

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

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

ПBМ, вот я и не понимаю, чем классы упрощают. Подцепил библиотеку, вызвал функцию одной строчкой кода, получил результат и используй в дальнейшем коде. Разве работа с классом проще? Кода больше, методы обмена тоже надо учитывать и прописывать в коде. Куча дополнительной работы с непонятными преимуществами для алгоритмиста. А Ваш пример некорректен: я изначально спрашивал в чем преимущество ООП для разработчика алгоритма по сравнению с модульным программированием по принципу «программа-подпрограмма-библиотека»?

А. Г., про кучу дополнительной работы и кода больше можете показать пример? я не согласен, что кода — больше.

т.е. где-то внутри, в классах, может быть и больше. но раз мы с вами тут говорим «подцепил библиотеку, вызвал...» — то что мешает в той же библиотеке реализовать классы, а дальше «подцепил и используй». откуда возьмётся больше кода?

ПBМ, извините, но отвечу вопросом на вопрос:, зачем в библиотеке классы? И какая разница для алгоритмиста, использующего функцию из библиотеки, как она там прописана? А в такой постановке простого вызова функции из библиотеки конечно кода не больше. Больше его если используется подпрограмма или класс, написанный кодером в рамках одного кода.

А. Г., как зачем? ровно с той же целью, что и функции. я же давал пример — STL — это библиотека, в том числе там находятся классы.

ну так вы даёте разные условия. если не выносить функции в библиотеку, кода будет ровно столько же. 
классы прекрасно живут в библиотеках, в тех же самых dll, что и обычные функции. разница в дополнительных конструкциях, поддерживаемых на уровне компилятора. конструкторы, деструкторы (инициализаторы/разрушители), переопределяемые функции (изменение функционала) и наследование (расширение функционала). внутри оно всё одинаковое. кто-то напишел больше, кто-то меньше. кто-то понятнее, кто-то не понятнее.

я вам больше скажу, есть много языков, которые изначально реализованы на ООП, например мой рабочий Java. и кроме того, я тут немного освежил свои знания, оказывается ООП уже больше 40 лет. А сам термин появился в 67 году, можно справлять юбилей. Так что это вообще никакая не новина, вполне себе крепкий, здоровый метод программирования.

А. Г., ну и правильно. Про виртуальные функции лучше не знать =)) про них любят задавать вопросы на собеседованиях в банках. Они изрядно притормаживают в сравнении.

А. Г., синтаксис и пунктуация :)

Богатов Владислав, заслужил балабол. Лузер прав.