Интересное мнение про ООП - страница 5

 
Igor Makanu:

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


ЗЫ: применительно к трейдингу - писал и еще провожу эксперименты с сетками ордеров, где логика выставления ордеров у меня и пишется как A + B - C , где A,  B, и C - это ордера с заранее заданными параметрами, очень удобно использовать для генетических алгоритмов - интересная тема

Обертки это хорошее и логичное решение. Когда к месту. И думаю, обертки это инновация в процедурном языке. Именно в смысле новизны и полезности.

 
Igor Makanu:

применительно к трейдингу - писал и еще провожу эксперименты с сетками ордеров, где логика выставления ордеров у меня и пишется как A + B - C , где A,  B, и C - это ордера с заранее заданными параметрами, очень удобно использовать для генетических алгоритмов - интересная тема

A,  B, и C  с заранее заданными параметрами - как фенотип для генетических алгоритмов?

 
Valeriy Yastremskiy:

инкапсуляция дает свободу имен. И если эту проблему решить логикой имен. Это конечно же  затратно. то пайтон можно написать на функциях. но это будет не рыночное решение. НО это ВОЗМОЖНО.

в питоне любая ф-я, как и переменная, это объект )

 
Maxim Dmitrievsky:

кстати пример сплошного ООП - это питон. Там, скорее, никто не знает что существует что-то кроме ООП

там есть замыкания и можно вообще без ооп писать, в старом по крайней мере, кому что нравится

 
Maxim Dmitrievsky:

в питоне любая ф-я, как и переменная, это объект )

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

 
Andrei Trukhanovich:

там есть замыкания и можно вообще без ооп писать, в старом по крайней мере, кому что нравится

ну можно, но все равно минимальный строительный блок это объект

 
Maxim Kuznetsov:

что-то кстати давно его не видно..

неужто действительно под другими никами пошёл ? 

Не, это не Петр, совсем другой стиль письма.

 

суровый энтерпрайзный OOP это Java. В нашей сфере представлена Du* *opy (поскипано дабы не нарваться). Жаждите объектных красот - попробуйте на трезвую разобраться и запомнить их API, благо что тематика известна :-)

а вообще фигня всё это..

для поднятия программистского скила стоит освоить чё-нить мозговыворачивающее. Например есть Rebol/Red ( https://www.red-lang.org/) - офигенная штука, нихрена не понятная, но прикольная. 

или сразу классику - Smalltalk (https://pharo.org/) . Его даже в продакшене кто-то использует

А все эти "давайте напишем A+B в разных стилях", детский лепет, чесно слово. 

И тогда все вопросы про кто круче, ООП или ФП отпадут сами. 

Red/System: New Features
  • 2020.08.20
  • Nenad Rakocevic
  • www.red-lang.org
In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to...
 
Maxim Dmitrievsky:

ну можно, но все равно минимальный строительный блок это объект

объект это был прорыв.

 
Mikhail Mishanin:

Где удобнее ООП, использую ООП, где нужно экономить память и время, и кодится для себя - остаюсь в процедурном. Просто подвернулась статья, хотел выслушать мнения, где/что лучше). Итог - наслушался через край разного в свой адрес, а не о программировании) Всё как обычно.

Так вам ничего нового никто и не скажет. Используйте то что вам комфортно, все.

Для минимизации ошибок есть целая сфера, которая называется доказательное программирование (формальная верификация в частности)

В качестве частичных мер для улучшения качества кода можно предложить следовать какому-нибудь из общепринятых стилей кодирования (например google codestyle), использование утверждений (assert), ограничений (const, override, спецификаторы доступа) которые по сути не влияют на выполнение но вызывают ошибки компиляции в случае неправильного использования, ознакомиться с подходами в проектировании в целом

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