Используете ли вы ООП в программировании на MQL4 и MQL5? - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Многие забывают, что здесь является целью... а mql -- это лишь инструмент. И незаметно инструмент превратился в цель. Эдакая метаморфоза "с ног на голову" ;))
Многие забывают, что сейчас в первую очередь важна скорость разработки. Именно то, что дает ООП при умелом использовании.
А вообще тут идет разговор зрячих со слепцами. Зрячие говорят, смотрите, какой прекрасный мир вокруг, солнышко светит. А слепцы бредут, спотыкаются о кочки и постоянно брюзжат, как известный тут ...угадайте кто с первого раза :)))
имха, ООП полезно для проектов в которых участвуют много программеров. Проще разделить работу и потом подключить новых. Т.е. для достаточно глобальных проектов. В них преимущества раскрываются. Особенно при поддержки сторонними программистами open source проектов.
А для мелких проектов, которые делаются 1 человеком вполне можно без ООП обойтись, используя библиотеки функций для часто повторяемых фрагментов кода. Это как пушкой по воробьям.
Для каждой задачи свой идеальный инструмент. А когда в руках молоток, то всё кажется гвоздём)) И по привычке пытаешься прикрутить ООП туда, где в нем нет необходимости. Аналогично и с процедурным
Многие забывают, что здесь является целью... а mql -- это лишь инструмент. И незаметно инструмент превратился в цель. Эдакая метаморфоза "с ног на голову" ;))
Многие забывают, что здесь является целью... а mql -- это лишь инструмент. И незаметно инструмент превратился в цель. Эдакая метаморфоза "с ног на голову" ;))
имха, ООП полезно для проектов в которых участвуют много программеров. Проще разделить работу и потом подключить новых. Т.е. для достаточно глобальных проектов. В них преимущества раскрываются. Особенно при поддержки сторонними программистами open source проектов.
Согласен.
Я как-то участвовал в достаточно большом проекте > 1 ляма строк, портирование виндовых кодеков wma (audio) и wmv (video) на один media-processor. Все исходники были в виде наборов функций на Си, работало 3-6 человек, состав был такой, плавающий.
Никто нихрена не представлял, как это все работает, даже менеджер проекта, тупо портировали из double в int и оптимизировали. Цельной картины не было ни у кого, тем более, что MS не дала почти никакой сопроводительной документации, только наборы тестов. Ну, какие-то комментарии были в исходниках.
Я думаю, если бы это было сделано в виде четкой структуры классов, с пониманием было бы куда лучше. Помню, проект неимоверно просрочили, менеджер, бедняга, спал в офисе, еле сдали.
Я как-то участвовал в достаточно большом проекте > 1 ляма строк, портирование виндовых кодеков wma (audio) и wmv (video) на один media-processor. Все исходники были в виде наборов функций на Си, работало 3-6 человек, состав был такой, плавающий.
Никто нихрена не представлял, как это все работает, даже менеджер проекта, тупо портировали из double в int и оптимизировали. Цельной картины не было ни у кого, тем более, что MS не дала почти никакой сопроводительной документации, только наборы тестов. Ну, какие-то комментарии были в исходниках.
Я думаю, если бы это было сделано в виде четкой структуры классов, с пониманием было бы куда лучше. Помню, проект неимоверно просрочили, менеджер, бедняга, спал в офисе, еле сдали.
я когда-то работал над цифровой "отечественной" телефонной станцией, купленной у французов (разработка начала 80х). Чтобы понять как всё работает люди всю жизнь изучали код и документацию. И то не всё знали)) А чтобы принципиально дополнить функционал проще было создать отдельное устройство, которое обменивалось со станцией данными.
Думаю, что есть предел кода в строках, когда уже становится эффективным ООП.
З.Ы. глупо пользоваться плодами ООП (любая современная платформа) и отрицать его полезность
1) Многие забывают, что сейчас в первую очередь важна скорость разработки. 2) Именно то, что дает ООП при умелом использовании.
А вообще тут идет разговор зрячих со слепцами. Зрячие говорят, смотрите, какой прекрасный мир вокруг, солнышко светит. А слепцы бредут, спотыкаются о кочки и постоянно брюзжат, как известный тут ...угадайте кто с первого раза :)))
Согласен.
Я как-то участвовал в достаточно большом проекте > 1 ляма строк, портирование виндовых кодеков wma (audio) и wmv (video) на один media-processor. Все исходники были в виде наборов функций на Си, работало 3-6 человек, состав был такой, плавающий.
Никто нихрена не представлял, как это все работает, даже менеджер проекта, тупо портировали из double в int и оптимизировали. Цельной картины не было ни у кого, тем более, что MS не дала почти никакой сопроводительной документации, только наборы тестов. Ну, какие-то комментарии были в исходниках.
Я думаю, если бы это было сделано в виде четкой структуры классов, с пониманием было бы куда лучше. Помню, проект неимоверно просрочили, менеджер, бедняга, спал в офисе, еле сдали.
3-6 ничего крупного создать не могут в принципе. Если работа такой команды продолжается не более года, то организационные проблемы можно вообще не обсуждать. Именно поэтому и удалось завершить проект без единоначалия.
Проблемы начинаются с проектов в котором участвуют 20-30 квалифицированных и сработанных между собой человек. Причем в такой команде участвуют люди нескольких специализаций, обычно: математики (постановщики) алгоритмисты, кодеры, которые пишут строки кода. Кроме этого необходимы люди, которые подготовят контрольный пример для отладки, а также люди, которые либо сами, либо организуют опытную эксплуатацию полученного продукта.
Лично я участвовал в разработке продукта с командой от 300 до 350 человек. И это была не единственная команда в нашей конторе. Команд менее 20 человек вообще не бывало, так как никто не хотел связываться с мелочевкой.
Какие проблемы может в таких работах решить ООП?
Или более общий вопрос: а какие проблемы существуют в разработке крупных программных продуктов?
Первая проблема - это создание проектной документации, которая в будущем организует всю эту прорву народа. Не может быть и речи, чтобы в проекте не было человека, который бы не понимал проект целиком. Чтобы достичь этого разработка ведется этапами с постепенным утонением деталей.
И так далее...
Где здесь место ООП. Может быть есть, а может и нет так как он никаких проблем не решает, точно также как не решает проблем выбора языка программирования вообще. С самого начала и до конца проблема одна - это координация разработки, чтобы в конце получился работающий продукт, продукт, в который можно вносить изменения, продукт который могут понимать новые разработчики.
Для решения этих проблем был разработан ГОСТ "Единая система программной документации ЕСПД". Это только по поводу программного продукта. Кроме этого были и другие ГОСТы в области обработки данных. Все эти ГОСТы были как язык, на котором описывался продукт, этот язык был единым в стране и поэтому продукт можно было передавать с этапа на этап, между разными разработчиками одной специальности и разработчиками разных специальностей - все говорили на одном языке, точно было известно где и что искать и в какой последовательности.
А ООП? Может быть и полезным, хотя я не увидел ни одного поста, который бы описывал решение выше перечисленных проблем организации разработки крупных программных продуктов. Надо всегда помнить, что собственно кодирование - это только часть проблемы даже на уровне советника, причем не самая трудоемкая. Вот найти модель,которая не переобучается .... а закодировать готовую мысль с ООП или без него особой роли не играет.
Если для себя? Допускаю... Лично для меня смысла не вижу. Лет пять или более перестал писать что-либо новое - есть готовые куски, иногда вижу интересные куски в кодобазе. И зачем мне лично ООП?
я когда-то работал над цифровой "отечественной" телефонной станцией, купленной у французов (разработка начала 80х). Чтобы понять как всё работает люди всю жизнь изучали код и документацию. И то не всё знали)) А чтобы принципиально дополнить функционал проще было создать отдельное устройство, которое обменивалось со станцией данными.
Думаю, что есть предел кода в строках, когда уже становится эффективным ООП.
З.Ы. глупо пользоваться плодами ООП (любая современная платформа) и отрицать его полезность
3-6 ничего крупного создать не могут в принципе. Если работа такой команды продолжается не более года, то организационные проблемы можно вообще не обсуждать. Именно поэтому и удалось завершить проект без единоначалия.
Проблемы начинаются с проектов в котором участвуют 20-30 квалифицированных и сработанных между собой человек. Причем в такой команде участвуют люди нескольких специализаций, обычно: математики (постановщики) алгоритмисты, кодеры, которые пишут строки кода. Кроме этого необходимы люди, которые подготовят контрольный пример для отладки, а также люди, которые либо сами, либо организуют опытную эксплуатацию полученного продукта.
Лично я участвовал в разработке продукта с командой от 300 до 350 человек. И это была не единственная команда в нашей конторе. Команд менее 20 человек вообще не бывало, так как никто не хотел связываться с мелочевкой.
Какие проблемы может в таких работах решить ООП?
Или более общий вопрос: а какие проблемы существуют в разработке крупных программных продуктов?
Первая проблема - это создание проектной документации, которая в будущем организует всю эту прорву народа. Не может быть и речи, чтобы в проекте не было человека, который бы не понимал проект целиком. Чтобы достичь этого разработка ведется этапами с постепенным утонением деталей.
И так далее...
Где здесь место ООП. Может быть есть, а может и нет так как он никаких проблем не решает, точно также как не решает проблем выбора языка программирования вообще. С самого начала и до конца проблема одна - это координация разработки, чтобы в конце получился работающий продукт, продукт, в который можно вносить изменения, продукт который могут понимать новые разработчики.
Для решения этих проблем был разработан ГОСТ "Единая система программной документации ЕСПД". Это только по поводу программного продукта. Кроме этого были и другие ГОСТы в области обработки данных. Все эти ГОСТы были как язык, на котором описывался продукт, этот язык был единым в стране и поэтому продукт можно было передавать с этапа на этап, между разными разработчиками одной специальности и разработчиками разных специальностей - все говорили на одном языке, точно было известно где и что искать и в какой последовательности.
А ООП? Может быть и полезным, хотя я не увидел ни одного поста, который бы описывал решение выше перечисленных проблем организации разработки крупных программных продуктов. Надо всегда помнить, что собственно кодирование - это только часть проблемы даже на уровне советника, причем не самая трудоемкая. Вот найти модель,которая не переобучается .... а закодировать готовую мысль с ООП или без него особой роли не играет.
Если для себя? Допускаю... Лично для меня смысла не вижу. Лет пять или более перестал писать что-либо новое - есть готовые куски, иногда вижу интересные куски в кодобазе. И зачем мне лично ООП?