Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
если вопрос к моему примеру - то как минимум, Вы скрываете реализацию ( скрываете даже от себя) - т.е. пишете только логику вычислений, это удобно, это читаемо, это позволяет избежать логических ошибок
ЗЫ: применительно к трейдингу - писал и еще провожу эксперименты с сетками ордеров, где логика выставления ордеров у меня и пишется как A + B - C , где A, B, и C - это ордера с заранее заданными параметрами, очень удобно использовать для генетических алгоритмов - интересная тема
Обертки это хорошее и логичное решение. Когда к месту. И думаю, обертки это инновация в процедурном языке. Именно в смысле новизны и полезности.
применительно к трейдингу - писал и еще провожу эксперименты с сетками ордеров, где логика выставления ордеров у меня и пишется как A + B - C , где A, B, и C - это ордера с заранее заданными параметрами, очень удобно использовать для генетических алгоритмов - интересная тема
A, B, и C с заранее заданными параметрами - как фенотип для генетических алгоритмов?
инкапсуляция дает свободу имен. И если эту проблему решить логикой имен. Это конечно же затратно. то пайтон можно написать на функциях. но это будет не рыночное решение. НО это ВОЗМОЖНО.
в питоне любая ф-я, как и переменная, это объект )
кстати пример сплошного ООП - это питон. Там, скорее, никто не знает что существует что-то кроме ООП
там есть замыкания и можно вообще без ооп писать, в старом по крайней мере, кому что нравится
в питоне любая ф-я, как и переменная, это объект )
ссылками все можно решить. лишь бы имена не пересекались. Функция это конечно объект, но ее результат изнутри един, и только в глобальном и публичном варианте внутрь можно заглянуть. мне логика питон нравиться)))
там есть замыкания и можно вообще без ооп писать, в старом по крайней мере, кому что нравится
ну можно, но все равно минимальный строительный блок это объект
что-то кстати давно его не видно..
неужто действительно под другими никами пошёл ?
Не, это не Петр, совсем другой стиль письма.
суровый энтерпрайзный OOP это Java. В нашей сфере представлена Du* *opy (поскипано дабы не нарваться). Жаждите объектных красот - попробуйте на трезвую разобраться и запомнить их API, благо что тематика известна :-)
а вообще фигня всё это..
для поднятия программистского скила стоит освоить чё-нить мозговыворачивающее. Например есть Rebol/Red ( https://www.red-lang.org/) - офигенная штука, нихрена не понятная, но прикольная.
или сразу классику - Smalltalk (https://pharo.org/) . Его даже в продакшене кто-то использует
А все эти "давайте напишем A+B в разных стилях", детский лепет, чесно слово.
И тогда все вопросы про кто круче, ООП или ФП отпадут сами.
ну можно, но все равно минимальный строительный блок это объект
объект это был прорыв.
Где удобнее ООП, использую ООП, где нужно экономить память и время, и кодится для себя - остаюсь в процедурном. Просто подвернулась статья, хотел выслушать мнения, где/что лучше). Итог - наслушался через край разного в свой адрес, а не о программировании) Всё как обычно.
Так вам ничего нового никто и не скажет. Используйте то что вам комфортно, все.
Для минимизации ошибок есть целая сфера, которая называется доказательное программирование (формальная верификация в частности)
В качестве частичных мер для улучшения качества кода можно предложить следовать какому-нибудь из общепринятых стилей кодирования (например google codestyle), использование утверждений (assert), ограничений (const, override, спецификаторы доступа) которые по сути не влияют на выполнение но вызывают ошибки компиляции в случае неправильного использования, ознакомиться с подходами в проектировании в целом
Факт в том что если не считать критичных отраслей программирования в целом важнее скорость получения продакшн версии нежели качество кода, это плохо но это так