Интересное мнение про ООП - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Деструктивная какая то реакция на тему и деструктивное обсуждение. Расскажите мне приверженцу Процедурного программирования как избежать "спаггетизации" в ООП, как разбирать и имеет ли смысл использовать чужие "спаггети"?
Ведь что получается, ООП по большей части для читаемости и командного программирования, т.е. для больших проектов. Эксперт торгующий символом к графику которого он прикреплен с контролем максимального риска от баланса/средств по счёту ну никак не назовешь большим проектом - значит достаточно и выгоднее по памяти/скорости - процедурное программирование.
Вопросы:
- минусы/плюсы ООП(как императивное) из личного опыта
- минусы/плюсы ФП(как декларативное) из личного опыта.
И мнение о перспективах конечно интересно, особенно в направлении параллельных вычислений. Квантовую тему не вижу смысла затрагивать.
надо смотреть что откуда шло, по поводу спагетизации вообще не понял.
Хорошая черта любого кода - максимально короткие функции. Пусть лучше их будет больше
К примеру половина свойств ООП, это то, что мы бы хотели отделить для удобства использования - к примеру отделить ряд функций в группу и дать им свои переменные которые бы жили в их namespace).
Поскольку мы работаем с типо хранилищем "классом" то можно четко заранее предопределить все переменные задать им определенный тип....
удобно для создание внешних API. При работе можно работать с ссылкой на класс (8байт) - очень часто используется.
Пример: Всякие линкованные списки узлов и прочее.
// я тут расписал только особенности которые вижу, понятно что нет смысла писать про возможность и свойства защищённых методов и прочее.... это так сказать просто сахар
Свойства ФП это то что мы бы хотели бы сделать где то там, после чего-то, к примеру мы бы хотели прям на лету в функции сочинить новую функцию - разделив текущую, которая бы использовала часть текущих переменных с нашей функции. Чтобы её выполнение передать в другую функцию - получается мы просто передаем отложенную функцию, расчет который еще не происходил - прям в виде кусочка кода....
На самом деле это довольно удобно.
При этом остаётся свойство полного разворачивания кода т.к. по факту мы четко знаем какая функция у нас получена - что скорее всего будет быстрее при вычислении чем ООП. Можно организовывать довольно хитрые перебросы вычислений с одной функции внутрь другой - также функция полностью запоминает окружения вызванных переменных прошлой функции - что очень круто (хотя по факту это лишь сохранения объявленных переменных из внешней области видимости). ФП же можно задать адрес функции и сохранить её в массив подобно классу - хотя особо не пригождается.
Простота написания кода для отложенных действий, всяких асинхронных функций, параллельных расчетов
Поясню свои опасения исходя из цитируемой статьи и самого понятия детерминированности. Чем меня пугает "спаггетизация" (запутанность самого кода и задача поиска ошибок вычисления)? Так тем на что акцентировано внимание в статье - "мусорные" значения в переменных или недетерминированный возврат из функций.
Собираю/обучаю нейронные сети своей переменной(эволюционируют) структуры. И для них очень выходит критичным что откуда не возьмись полезет "мусор" в значениях.
Как в статье,- ты давишь на педальку тормоз, а педальке пофиг на тебя. Это при эксплуатации. А если у тебя изначально на момент сборки(автоматического подбора архитектуры) и обучения нейронной сети возможен "мусор" то вообще как она соберется/обучится?
Как максимально избежать "мусора"(недетерминированности) в ООП?
Поясню свои опасения исходя из цитируемой статьи и самого понятия детерминированности. Чем меня пугает "спаггетизация" (запутанность самого кода и задача поиска ошибок вычисления)? Так тем на что акцентировано внимание в статье - "мусорные" значения в переменных или недетерминированный возврат из функций.
Собираю/обучаю нейронные сети своей переменной(эволюционируют) структуры. И для них очень выходит критичным что откуда не возьмись полезет "мусор" в значениях.
Как в статье,- ты давишь на педальку тормоз, а педальке пофиг на тебя. Это при эксплуатации. А если у тебя изначально на момент сборки(автоматического подбора архитектуры) и обучения нейронной сети возможен "мусор" то вообще как она соберется/обучится?
Как максимально избежать "мусора"(недетерминированности) в ООП?
Там в статье в обще как то странно, человек явно забыл указать тип переменной const, вроде у него там js тогда хотя бы readonly. После чего пишет что мол у него ошибка когда объект который не должен менять размер (быть константой), почему-то не константа ..... и на основании этого делает выводы что в ООП велика вероятность ошибки )))
В общем ООП позволяет контролировать области переменных. ФП же задумана как передача переменных из функции, т.е. тип уже по умолчанию должен быть нами определён т.к. их скорее всего мало. А если что можно на ходу саму эту функцию расширить.
Т.е. в ООП изначального контроля больше
Вот так вот, всегда подозревал)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Не понятно, кто такие "статьи" пишет, пустословие, общие фразы, смысла минимум.
" Код в целом был запутанным и беспорядочным – то, что на сленге называется «спагетти» " - из-за плохих программистов в Toyota будем считать, что в ООП код запутанный.
" Встроенные фичи ООП только добавляют путаницы. " - ну и логика, возможность использования фичей добавляют путаницу в код, при постоянном увеличение количества фичей ООП(C#) будет уже невозможно написать простой код. Да уж.
"В большинстве объектно-ориентированных языков данные передаются по ссылке, то есть разные участки программы могут иметь дело с одной и той же структурой данных – и менять ее. Это превращает программу в один большой сгусток глобального состояния и противоречит первоначальной идее ООП " - А private, protected?
"... Если эта цитата вам не нравится, то это потому, что недетерминированность в целом никуда не годится." - ну да, непредсказуемые функции GetMicrosecondCount, MathRand, CoptBuffer, все сетевые функции и другие надо выкинуть, там ведь результат зависит от внешнего состояния. Ужас.
Ладно, хватит, тут всё ясно.
Вот так вот, всегда подозревал)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Там большая часть аргументов высосана из пальцев. Некоторые эксперименты "доказывающие" не состоятельность ООП вообще некорректны. В нормальных ООП языках sum(int a, int b) всегда будет чистой, даже если писать бред вроде а += b внутри. Опять-таки, если объект выделяется на кучи внутри метода, то он всегда защищен, т.к. ссылка на него есть только у метода его вызвавшего. Меняй его хоть до потери пульса. Есть ссылочные и значимые типы. Никто не мешает в ООП языках писать чистые функции без побочных эффектов. Стандартные математические функции например такие. Да, иногда без разделяемых ресурсов не обойтись, но для этого есть удобные потокобезопасные коллекции и много чего еще. В конце концов любой чистый ФП будет неизбежно взаимодействовать с IO, BD, сетевыми запросами и много еще чем, откуда и прорвутся демоны изменяемости.
Странная статья....
Количество обладает свойством переходить в качество.
Когда раций много, может возникнуть электромагнитная не совместимость и они перестанут работать.
Спагетти свойства кода это обычно от количества и не учета всех свойств обернутого при большом количестве использования в разных состояниях.
В функциях наличие обратных связей к тому же приведет. Гистерезис шутка еще та)
Понимание задач, и их правильная постановка ... ))))
// я тут расписал только особенности которые вижу, понятно что нет смысла писать про возможность и свойства защищённых методов и прочее.... это так сказать просто сахар
Свойства ФП это то что мы бы хотели бы сделать где то там, после чего-то, к примеру мы бы хотели прям на лету в функции сочинить новую функцию - разделив текущую, которая бы использовала часть текущих переменных с нашей функции. Чтобы её выполнение передать в другую функцию - получается мы просто передаем отложенную функцию, расчет который еще не происходил - прям в виде кусочка кода....
На самом деле это довольно удобно.
Ну а кто мешает делать тоже самое в ООП? Да даже в чисто процедурном языке? Передаете указатель на функцию другой функции и добиваетесь отложенного выполнения.
Асинхронщина это вообще чистый паттерн проектирования. Написать асинхронный код можно и на чистом Си. Просто сделать State-машину которая по частям выполняет задачу. Кстати я такое делал с индикаторами в MQL, которые долго считались. Что бы не тормозить чарт и выводить красивый статус-бар меняющий свой процент выполнения.
Ну а кто мешает делать тоже самое в ООП? Да даже в чисто процедурном языке? Передаете указатель на функцию другой функции и добиваетесь отложенного выполнения.
Асинхронщина это вообще чистый паттерн проектирования. Написать асинхронный код можно и на чистом Си. Просто сделать State-машину которая по частям выполняет задачу. Кстати я такое делал с индикаторами в MQL, которые долго считались. Что бы не тормозить чарт и выводить красивый статус-бар меняющий свой процент выполнения.
) можно и на ассемблере. Вопрос в том где проще.
И не надо меня ставить в ту или другую сторону.... я не приверженец чего то одного
Странная статья. ООП ничем от процедурного стиля в худшую сторону не отличается, т.к. в нём по умолчанию можно сделать всё в процедурном стиле, а наоборот нельзя без страшного раздувания кода, т.е. ООП это "надстройка над", а не принципиально другой стиль.
Если в статье действительно о функциональном, а не процедурном (что не так уж и очевидно, если придираться), то зачем сравнивать то, у чего совершенно различные области применения.
Топик стартер, вы сами то пишите и сейчас говорили о каком? функциональном или процедурном?
Ведь что получается, ООП по большей части для читаемости и командного программирования, т.е. для больших проектов.
Не умею ООП. Но примитивные вещи из него использую. Из недавнего, выкладывал очень простой код.
Начал его писать в ФП, когда еще не понимал, что мне в итоге нужно будет смотреть.
Закончил через примитивные элементы ООП. Возможно, потерял навыки ФП, но тут ООП показался гораздо проще и читабельнее.
Код очень простой и короткий (описание). Если его напишите на ФП, будет интересно сравнить.