Я не профи в программировании - так - продвинутый (может, и не очень))) графоман.
Подход ООП для создания индикаторов, "перемалывающих числа", мне кажется не оптимальным по быстродействию. Процедурность поэкономичней будет. Может, в экспертах?
В двух словах. ООП - это средство разработки больших и сверхбольших проектов, а с прагматической точки зрения, при наличии хороших библиотек классов (встроенных или собственных), код становится компактнее и читабельнее, следовательно, содержит меньшее количество досадных ошибок.
В двух словах. ООП - это средство разработки больших и сверхбольших проектов, а с прагматической точки зрения, при наличии хороших библиотек классов (встроенных или собственных), код становится компактнее и читабельнее, следовательно, содержит меньшее количество досадных ошибок.
Я в курсе двух слов, потому и спрашиваю: это нам надо? Если да, то чтобы хотелось увидеть созданным таким образом? У меня лично фантазии не хватает - больших и сверхбольших проектов на MQL не представляю.
Я в курсе двух слов, потому и спрашиваю: это нам надо? Если да, то чтобы хотелось увидеть созданным таким образом? У меня лично фантазии не хватает - больших и сверхбольших проектов на MQL не представляю.
Я думаю так: Если использование ООП увеличит ваши прибыли на Форексе, то имеет смысл это использовать, а если не увеличит, то нафига тогда?
Я в курсе двух слов, потому и спрашиваю: это нам надо? Если да, то чтобы хотелось увидеть созданным таким образом? У меня лично фантазии не хватает - больших и сверхбольших проектов на MQL не представляю.
Ну если "в теме", то вспомните, что ООП создавался, чтобы кодить а) быстро б) качественно. Это вам надо ;)
Вас что интересует, процесс или конечный рез-т?)))
Меня - и то, и другое, но результат как-то больше. ("… ООП предоставляет вам множество способов замедлить работу ваших программ …")
Я не вижу, где ООП позволит мне написать быстрее, чем при процедурном подходе, и это бы перевесило все минусы ООП. Кому надо - это как раз понятно - разработчику, который пишет для других.
Svinozavr писал(а) >>
Вас что интересует, процесс или конечный рез-т?)))
Еще сопровождение и доработка.
Меня - и то, и другое, но результат как-то больше. ("… ООП предоставляет вам множество способов замедлить работу ваших программ …")
... если вы не умеете его пользовать
Я не вижу, где ООП позволит мне написать быстрее, чем при процедурном подходе, и это бы перевесило все минусы ООП. Кому надо - это как раз понятно - разработчику, который пишет для других.
Перечислите минусы ООП. Скажите как с помощью ООП замедлять программы на критичное время. 2% разницы не в счет. И то не факт, что в пользу ФП.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Я не профи в программировании - так - продвинутый (может, и не очень))) графоман.
Подход ООП для создания индикаторов, "перемалывающих числа", мне кажется не оптимальным по быстродействию. Процедурность поэкономичней будет. Может, в экспертах?
Зубры программерства, что думаете?