06 марта 2017, 00:50
Феерично про "ООП".
Автор тупик (заявляю).
Так путать понятия и примеры приводить — это просто феерия.
Всё к этому: smart-lab.ru/blog/384435.php
Поскольку у данного персонажа в ЧС, приведу то, что коротко хотел комментарием оставить:
Так путать понятия и примеры приводить — это просто феерия.
Всё к этому: smart-lab.ru/blog/384435.php
Поскольку у данного персонажа в ЧС, приведу то, что коротко хотел комментарием оставить:
хрень про ООП написана. Не путайте людей! ООП ничего общего с вашим примером не имеет.ООП как раз изначально вычленит из списка ВООБЩЕ не относящееся к предмету! Уже далее на основе предварительных взаимозависимостей/взаимосвязей начнет вычислять конкретные связи, коих минимум 3 вида.И так далее… ХРЕНОТЕНЬ полная написана с употреблением «ООП».(Твёрдость количества можете выразить? ну-ну)
Сергей Хорошавин, дивиденды по фос агро
12:46
Артур Раз-Два, США с НАТО уже добрались до России, с 22-го года ловко и больно избивают российский кулак своими рожами, аж зуб повыпадали.
12:46
Сергей Елисеев, если к февралю по 2, то к марту владельцы облигаций будут доплачивать только чтобы кто-нибудь забрал?
Prostak, на перелой перелойский
Новатэк растёт сегодня. Думаю, это на закрытии шортов. Шорты надо закрыть именно сегодня, а не 30 декабря. Иначе они останутся на все праздники и на следующий год (Т+2).
Leha Krivcovski, а что в поддержке
говорят? Тоже самое?
12:33
Акционеры Диасофта одобрили дивиденды за 9 мес 2024г в размере 45 руб/акция (ДД 1,1%), отсечка - 8 января ПАО "Диасофт"Решения общих собраний участников (акционеров)
Формулировки решени...
Витя, бабушке Баяновой вот об этом и нужно было говорить, и главное — рассказать, как сама заявительница бывшего мужа называла целью, а Баянова её пристыдила, но та ей нахамила.
12:30
Китайские автомобили теряют 50% первоначальной стоимости спустя год Китайские автомобили теряют 50% первоначальной стоимости спустя год эксплуатации, выяснили Известия. При этом японские автомобили че...
В Магните можно не только оставлять деньги, но и получать, заработал на его акциях!
Магнит занимает ведущие позиции на российском рынке розничной торговли, имеет широкую сеть магазинов и фоку...
А так проще прямо в экселе или ворде ))))
И что? я сейчас буду всех подстрекать и чушь писать для примера?
Но тут автор покушается учить тому, что такое ООП!
При том на невразумительном и кривом примере!
к слову, немногие могут вместо «хелло ворлд» запрогить обычную прогу вычисления параболы.
Это ужас!
«квадратичная функция», «дискриминант» и прочее — шок вызывает. Зато он ПРОГРАММИСТ!
(банальная автозамена кучи рабсилы живой на бездушный силициум).
(на микросхемах нет +1 и -1, там и 0,5 участвует в принятии решения… чисто по вольтажу)
wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
Конечно, далеко не все языки, которые сейчас принято относить к ООП это все имеют, но, идеи таковы.
Главное, что отличает, безусловно, то, что это способ рассуждать о программах в терминах реального мира, предметной области, а не «погонять функцию функцией».
Объект инкапсулирует поведение, объекты порождаются на пользовательском уровне, а не на уровне языка, объекты не являются пассивными сущностями, как, например, просто структуры данных(в процедурных и функциональных языках).
Вообще, ООП — это не столько о программировании в смысле написания кода, сколько о проектировании и построении абстракций.
А далее по накатанной.
Подмена понятий и прочее!
По-русски: ПУСТОБРЁХ!
Нашел новую тему для привлечения внимания.
Завтра в LYH/KYH начнется что-то — он будет тут как тут… Бакс рванет на 80 — он опять будет тут.
А на унылости выискал то, что звучит круто.
Не учел только, что обосрался полностью!
Но ему невдосуг.
Высрал в очередной раз пост на главную… и горд.
Я на любое множество чего-угодно могу так же отвественно заявить: я ВСЁ ЭТО МОГУ ПРОИЗНЕСТИ ЗВУКАМИ!
Это есть то, что он хотел донести своим КРИВЕЙШИМ примером про ООП?
Насрать в головы всем, особенно начинающим?
А вот про это и забыл:
Представьте себе такой пример. У вас есть некий Account, с интерфейсом withdraw и deposit, ну, это классика:) Представьте теперь, что есть два потока, которые меняют состояние аккаунта. Пусть они меняют его также, примерно, как, скажем происходит инкремент на низком уровне работы с памятью. Пусть текущий баланс 10 баксов. Процесс1 считывает из памяти текущий баланс. после этого процесс2 тоже считывает его же. Пусть процесс1 хочет положить на счет 10 баксов. Он прибавляет к считанному значению 10, и записывает то что у него получилось обратно в аккаунт. В это время, процесс 2 прибавляет к считанному значению, скажем, 20 баксов, и записывает результат в аккаунт. Итого, у нас было 10 баксов, мы положили 30 баксов, в итоге наш баланс увеличился на 20 баксов:) Это не совсем то что мы хотели сказать:) Это можно решить блокировками, которые порождают другие проблемы, и мы приходим к уродливой архитектуре, когда решение одной проблемы порождает кучу других(например дедлоки, голодание etc)
Теперь представьте, что аккаунт сам себя модифицирует, а внешние объекты только посылают ему сообщения с «командами» на модификацию. В том случае, проблем просто не возникает.
Вот это, на пальцах, только лишь одна из множества проблем, которые решает ООП-подход.
Теперь, например, представляем, что нам нужен не один аккаунт, а много, и часть поведения обобщено, а часть(eg какой то дисконт или процентная ставка) — индивидуальны. Сюда прибавляется масштабируемость и легкая поддержка и модификация приложения, плюс синтаксическая абстракция(вы пишете код в такой манере, как это на самом деле происходит в реальности, манипулируя объектами). А в динамических языках, в духе смоллтока, Вы можете манипулировать даже метаобъектами(классами/суперклассами/типами) прямо в рантайме. И это все только вершина айсберга.
Как то так:)
вообще, подпрограмма != функция. Функция в математическом смысле — это отображение, а не подпрограмма. Это, кстати говоря, приводит к еще бОльшей путанице.
И да, математику к программированию лишний раз притягивать за уши не стоит без нужды:) Математика — это «что» а программирование — это «как». Это две разных вселенных:)
Но если применять концепции, то большие проекты имеют упорядоченную архитектуру, что ведет к упрощению разработки. А от сюда и все вытекающее, меньше ошибок и тд.
А фактически с того времени мало, что придумали.
Если хочешь создать, что то реально работающее — нарисуй блок-схему.
Образно, наверное ничего нового. Но многое кроется в деталях и мелочах.
Современное программирование тянется к тому, чтобы облегчить труд программисту, в первую очередь скорее всего тянет к тому, чтобы программист меньше создавал кода, обращался к уже написанному. В следствие этого, якобы, программист делает меньше ошибок, много ложится на плечи компилятора и тд. ООП конечно далеко уже не современно, в смысле создано давно, но направленно на то, чтобы сложное писать проще и не задумываться о мелочах, ну такие как, например области видимости, выделение памяти, ее утечка и тд.
Ведь согласитесь, писать на шарпе и писать на си — это большая разница. И в целом ряде задач очень существенная.
Что получается нового? Новое кроется в мелочах за спиной программиста, с целями уменьшения ошибок в разработке кода.
Высоко эффективный код я всегда сяду писать на низком уровне. Но масштабные задачи, обслуживающие трейдинг (логирование, мониторинг, БД и тд) я никогда не сяду писать с низкого уровня — это рассадник багов, которые придется устранять гораздо дольше. Модульное программирование, которое вы приводите в пример, это ниже уровнем чем ООП.
В программирование существует понятие — атомарная операция — это операция над переменными, в процессе которых, никакой другой поток программы не может вмешаться в это процесс.
Ну например. У меня есть байт:В одном потоке я делаюПо архитектуре процессора, это операция будет считаться атомарная, так как пишется байт в память, другой поток в этот байт не залезет. Это очень важно в многопоточном программировании.
Еще со времен 486 процессоров, интел научился делать простейшие операции атомарно (сложение, вычитание, инкремент и тд) через спец ассемблерные инструкции (проц просто лочит память).
Разработчики на Си быстро оборачивали эти ассемблерные вставки в процедуры и работали. Потом в Cи 11 стандарта уже появились встроенные функции в стандартные библиотеки, уже не надо было ничего придумывать, а в Cи++ 11 стандарта появились классы, реализующие тоже самое.
Казалось бы, зачем эти классы, если можно и дальше использовать либо ассемблерные вставки или встроенные функции.
Дело в том, что когда разработчик пишет очень много параллельного кода, внимание притупляется, и нечайно он может не применить атомарные функции, и вместо готовой функции
он нечайно может написать
Что сразу же нарушит атомарность работы с памятью И это может привести к багам, которые в большом коде очень сложно найти.
Конечно, можно к названиям переменным прибавлять некий префикс, ну напримерчтобы не притуплялось внимание. Но это может не помочь.
Класс в данном случаен сильно спасает. Мы можем обернуть эту переменную в класс, закинуть ее в private видимость и работать с ней через методы класса, полностью исключая возможные ошибки кода.
Да, на этом мы теряем наносекунды, но приобретаем стабильность кода.
Вышеизложенные примеры с ошибками кода привожу из примера опытных программистов, создающих большое приложение.
Но мы говорим (то есть я) не про упрощение кода, а упрощение разработки. А процесс разработки, это не только кодонаписание и последующее кодочтение, а так же написание корректного кода без плавающих ошибок (ну и много других этапов).
И ведь в трейдинге это очень важно. Ведь любая скрытая ошибка кода, особенно на скоростных алго, может привести к серьезным потерям.
Например удобна возможность в игре перебрать по циклу сразу все «живые» объекты и переместить их (метод move). И притом в реальности вместо метода move будут применяться разные подпрограммы, в зависимости от конкретного объекта.
зы. Не понять отчего автор сего топика с таким упоением что то кому то пытается доказать…
такие штуки, как перегрузка операторов, виртуальные методы, полиморфизм.
что такое класс, технически? указатель на структуру, и таблицу виртуальных функций.
т.е. да, можно реализовать и с помощью отдельно существующей структуры, функций, указателей на функции и таблицы.
но зачем.
класс, безусловно решает задачи замыкания сложностей предметной области.
и кроме того позволяет внедрить целый ряд новых шаблонов программирования, из тех стареньких что я помню, например самый простой — «фасад», а сейчас часто используется шаблон "строитель".
я очень люблю классы. их на самом деле придумали уже достаточно давно, это скажем так, далеко не передний край. вообще программирование сейчас очень быстро двигается, хотя этого и не очень заметно. стандарты C++, Java — очень часто обновляются, народ чего-то генерит со страшной силой.
соблазн остаться со старыми знаниями есть.
но мне нравится статья на тему https://habrahabr.ru/company/infopulse/blog/275951/
типа, как ну, скажите, зачем мне мясорубка, если я итак пожарю мясо на сковороде, и убейте, но я не понимаю, что такое котлета.
упорядоченный массив любых «объектов», структур, если хотите.
который может делать вставку, поиск, удаление, сортировку, отдавать объект по индексу.
при этом, позволяет указывать, в какую сторону делать сортировку. позволяет задавать функцию, которая будет сравнивать объекты (структуры) и говорить, какая «больше», какая меньше.
это наверное всё можно сделать функциями, но будет будет жутковато выглядеть и немного громоздко и беспорядочно.
вот из таких «классов» состоит STL — библиотека стандартных шаблонов.
с учётом того что ООП очевидно создавался для людей, как и функциональные языки, то очевидно что это во многом вкусовщина.
для меня лично ООП стал поворотной точкой, я действительно считаю что он позволяет лучше управлять кодом и структурировать его в голове.
последние три месяца изучаю ядро линукс/андроид, вот там всё чистый C, никакого ООП. и надо сказать, конечно всё понятно, ну, почти, вот только очень и очень разбросано/размазано и тп.
в своё время мне запомнилась беседа со специалистом по UI, он мне открыл новость, что все менюшки в окошках не просто так разбиты по 7 элементов на одном уровне максимум. а потому что людям так легче их держать в голове. и наша память ассоциативна-иерархична.
в этом плане программа организованная в виде иерархии классов относительно легче ложится в голову, кмк, чем абстрактная библиотека функций. хотя у функций тоже можно играть с именами, организуя их в кучки.
чем библиотека функций лучше, чем простое использование регистров, стека и goto? ведь всё можно сделать регистрами, стеком и goto.
функции просто упрощают этот процесс. а классы — упрощают функции, эволюция.
можно быть кошечкой, собачкой, а можно намазать в голове тонкий слой неокортекса и поди ж ты, целая новая цивилизация.
так и с классами, вроде ничего нового, теже самые нейроны, что и в остальном мозгу, возвращаясь к аналогии с собаками, и ходить, лаять и носить палки можно и без такого развитого неокортекса. и даже разницу никто толком объяснить не может — как работает мозг человека, но то что разница есть и что она лучше — это очевидно.
т.е. где-то внутри, в классах, может быть и больше. но раз мы с вами тут говорим «подцепил библиотеку, вызвал...» — то что мешает в той же библиотеке реализовать классы, а дальше «подцепил и используй». откуда возьмётся больше кода?
ну так вы даёте разные условия. если не выносить функции в библиотеку, кода будет ровно столько же.
классы прекрасно живут в библиотеках, в тех же самых dll, что и обычные функции. разница в дополнительных конструкциях, поддерживаемых на уровне компилятора. конструкторы, деструкторы (инициализаторы/разрушители), переопределяемые функции (изменение функционала) и наследование (расширение функционала). внутри оно всё одинаковое. кто-то напишел больше, кто-то меньше. кто-то понятнее, кто-то не понятнее.
я вам больше скажу, есть много языков, которые изначально реализованы на ООП, например мой рабочий Java. и кроме того, я тут немного освежил свои знания, оказывается ООП уже больше 40 лет. А сам термин появился в 67 году, можно справлять юбилей. Так что это вообще никакая не новина, вполне себе крепкий, здоровый метод программирования.