Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ох ты, спасибо, ознакомлюсь
Мне больше нравиться статья Дмитрия по ООП.
Мне больше нравиться статья Дмитрия по ООП.
Благодарю!
ООП это возможность повторения функций со своими переменными с разными типами данных, это просто надо понимать и в изучении таких возможностей изначально, конечно есть плюс. Это всего лишь часть алгоритмов решений. Поэтому конечно лучше эти решения знать. А не изобретать свои решения.)))
По моему у вас каша в голове и вы вообще не понимаете зачем нужен ООП. Команда и величина проекта тут вообще нипричем. А потом получаются "небольшие советники" которые текут со всех щелей с лютым говнокодом, которые легче переписать заново чем дорабатывать.
Если вы качаете Visual Studio с торрентов - то похоже, что вы вчера приступили к изучению программирования и ходите тут раздаете советы на тему использования ООП. Visual Studio бесплатно качается с официального сайта.
Столько агрессии и никакой конкретики. Причем тут качество кода вообще и ООП? Мне за структуру и манеру написания своей кода, его надежность и доступность для последующих модернизаций, сомневаться не приходится от слова совсем.
Если вы создали класс, и через объект вызываете его функцию, это не делает автоматом ваш код идеальным, удобным и надежным.
Я качал Visual Studio Pro примерно году в 2012-14, когда изучал C#, не помню что там можно было скачать с сайта или нет.
Сейчас когда шарпом пользуюсь редко, то мне хватает и простого SharDevelop.
Если просто создать две и функций, с одинаковым именем, но с разными входными типами данных, то это тоже работает, без ООП. Зачем для этого создавать класс и потом его объект.
В моем понимании инкапсуляция переменных функций и разделение переменных на локальные и глобальные это уже начало ООП.)))
Столько агрессии и никакой конкретики. Причем тут качество кода вообще и ООП? Мне за структуру и манеру написания своей кода, его надежность и доступность для последующих модернизаций, сомневаться не приходится от слова совсем.
Если вы создали класс, и через объект вызываете его функцию, это не делает автоматом ваш код идеальным, удобным и надежным.
Я качал Visual Studio Pro примерно году в 2012-14, когда изучал C#, не помню что там можно было скачать с сайта или нет.
Сейчас когда шарпом пользуюсь редко, то мне хватает и простого SharDevelop.
Конкретика. В классе хранятся переменные состояния объекта и разграничение прав на них. В функциональщине, для хранения чего либо придется использовать глобальные переменные. А глобальные переменные - это зло, за крайне редким исключением. Хороший код обычно разбивается по правилу "одна функция - один экран". Если вы разбиваете большой кусок кода на кучу функций - вместо удобного хранения переменных состояния объекта в классе - приходится таскать кучу переменных с собой и передавать их в каждую отдельную функцию. Функциональщина так же плодит функции телескопы c огромным количеством параметров. В ООП сделали группу сеттеров и все прекрасно работает. Наследование позволяет избежать огромного количества дублирований одинакового кода. Использование обьектов позволяет наиболее эффективно использовать отладчик. ООП позволяет делать синглтоны. Например, для получения текущих цен, в функциональщине, в каждом месте, get_bid() вы будете делать стандартное получение цены через копирование буфера. Что в конечном итоге, в разы снизит быстродействие вашего советника. В случае с синглтоном - у вас на весь процесс есть один объект отвечающий за маркет дату, в начале OnTick идет вызов обновления цен, а на всех последующих этапах, вы просто дергаете готовые данные. ООП код проще структурировать. У вас есть четкая иерархия классов и сделать спагетти код намного сложнее, чем в случае с функциональщиной. ООП код, как правило, получается намного более компактным и читаемым чем функциональный. В ООП почти невозможно допустить утечку памяти, функциональный же код, который работает с дин памятью, как правило, течет со всех мест. Плюсы же функционального кода (и то не MQL5) - скорость работы и эффективность оптимизации в виду более оптимального ассемблерного кода на выходе. Никаких иных приемуществ он не дает. Равно как и в скорости разработки у функционального программирования приемуществ нет.
Конкретика. В классе хранятся переменные состояния объекта и разграничение прав на них. В функциональщине, для хранения чего либо придется использовать глобальные переменные. А глобальные переменные - это зло, за крайне редким исключением. Хороший код обычно разбивается по правилу "одна функция - один экран". Если вы разбиваете большой кусок кода на кучу функций - вместо удобного хранения переменных состояния объекта в классе - приходится таскать кучу переменных с собой и передавать их в каждую отдельную функцию. Функциональщина так же плодит функции телескопы c огромным количеством параметров. В ООП сделали группу сеттеров и все прекрасно работает. Наследование позволяет избежать огромного количества дублирований одинакового кода. Использование обьектов позволяет наиболее эффективно использовать отладчик. ООП позволяет делать синглтоны. Например, для получения текущих цен, в функциональщине, в каждом месте, get_bid() вы будете делать стандартное получение цены через копирование буфера. Что в конечном итоге, в разы снизит быстродействие вашего советника. В случае с синглтоном - у вас на весь процесс есть один объект отвечающий за маркет дату, в начале OnTick идет вызов обновления цен, а на всех последующих этапах, вы просто дергаете готовые данные. ООП код проще структурировать. У вас есть четкая иерархия классов и сделать спагетти код намного сложнее, чем в случае с функциональщиной. ООП код, как правило, получается намного более компактным и читаемым чем функциональный. В ООП почти невозможно допустить утечку памяти, функциональный же код, который работает с дин памятью, как правило, течет со всех мест. Плюсы же функционального кода (и то не MQL5) - скорость работы и эффективность оптимизации в виду более оптимального ассемблерного кода на выходе. Никаких иных приемуществ он не дает. Равно как и в скорости разработки у функционального программирования приемуществ нет.
Конкретика. В классе хранятся переменные состояния объекта и разграничение прав на них. В функциональщине, для хранения чего либо придется использовать глобальные переменные. А глобальные переменные - это зло, за крайне редким исключением. Хороший код обычно разбивается по правилу "одна функция - один экран". Если вы разбиваете большой кусок кода на кучу функций - вместо удобного хранения переменных состояния объекта в классе - приходится таскать кучу переменных с собой и передавать их в каждую отдельную функцию. Функциональщина так же плодит функции телескопы c огромным количеством параметров. В ООП сделали группу сеттеров и все прекрасно работает. Наследование позволяет избежать огромного количества дублирований одинакового кода. Использование обьектов позволяет наиболее эффективно использовать отладчик. ООП позволяет делать синглтоны. Например, для получения текущих цен, в функциональщине, в каждом месте, get_bid() вы будете делать стандартное получение цены через копирование буфера. Что в конечном итоге, в разы снизит быстродействие вашего советника. В случае с синглтоном - у вас на весь процесс есть один объект отвечающий за маркет дату, в начале OnTick идет вызов обновления цен, а на всех последующих этапах, вы просто дергаете готовые данные. ООП код проще структурировать. У вас есть четкая иерархия классов и сделать спагетти код намного сложнее, чем в случае с функциональщиной. ООП код, как правило, получается намного более компактным и читаемым чем функциональный. В ООП почти невозможно допустить утечку памяти, функциональный же код, который работает с дин памятью, как правило, течет со всех мест. Плюсы же функционального кода (и то не MQL5) - скорость работы и эффективность оптимизации в виду более оптимального ассемблерного кода на выходе. Никаких иных приемуществ он не дает. Равно как и в скорости разработки у функционального программирования приемуществ нет.
ООП это подход все таки более сложный чем процедурный с гоуту и без инкапсуляции или функциональный без гоуту с раздельной видимостью переменных. Создание описание объекта / сущности и только потом инициализация объекта требует своего понимания, не относящегося к алгоритму решения конкретной задачи. Это подход для повторяющихся подзадач ( грубо и совсем не полностью конечно)))) ). Обычно выделить и определить какие задачи будут повторяться требует понимания и времени.
Так то верно, но это другой уровень подхода, постановки задач и программирования.)))) Здесь далеко не все на этом уровне))))
Конкретика. В классе хранятся переменные состояния объекта и разграничение прав на них. В функциональщине, для хранения чего либо придется использовать глобальные переменные. А глобальные переменные - это зло, за крайне редким исключением. Хороший код обычно разбивается по правилу "одна функция - один экран". Если вы разбиваете большой кусок кода на кучу функций - вместо удобного хранения переменных состояния объекта в классе - приходится таскать кучу переменных с собой и передавать их в каждую отдельную функцию. Функциональщина так же плодит функции телескопы c огромным количеством параметров. В ООП сделали группу сеттеров и все прекрасно работает. Наследование позволяет избежать огромного количества дублирований одинакового кода. Использование обьектов позволяет наиболее эффективно использовать отладчик. ООП позволяет делать синглтоны. Например, для получения текущих цен, в функциональщине, в каждом месте, get_bid() вы будете делать стандартное получение цены через копирование буфера. Что в конечном итоге, в разы снизит быстродействие вашего советника. В случае с синглтоном - у вас на весь процесс есть один объект отвечающий за маркет дату, в начале OnTick идет вызов обновления цен, а на всех последующих этапах, вы просто дергаете готовые данные. ООП код проще структурировать. У вас есть четкая иерархия классов и сделать спагетти код намного сложнее, чем в случае с функциональщиной. ООП код, как правило, получается намного более компактным и читаемым чем функциональный. В ООП почти невозможно допустить утечку памяти, функциональный же код, который работает с дин памятью, как правило, течет со всех мест. Плюсы же функционального кода (и то не MQL5) - скорость работы и эффективность оптимизации в виду более оптимального ассемблерного кода на выходе. Никаких иных приемуществ он не дает. Равно как и в скорости разработки у функционального программирования приемуществ нет.
МТ4 или МТ5, или обе версии.
Конкретика. В классе хранятся переменные состояния объекта и разграничение прав на них. В функциональщине, для хранения чего либо придется использовать глобальные переменные. А глобальные переменные - это зло, за крайне редким исключением. Хороший код обычно разбивается по правилу "одна функция - один экран". Если вы разбиваете большой кусок кода на кучу функций - вместо удобного хранения переменных состояния объекта в классе - приходится таскать кучу переменных с собой и передавать их в каждую отдельную функцию. Функциональщина так же плодит функции телескопы c огромным количеством параметров. В ООП сделали группу сеттеров и все прекрасно работает. Наследование позволяет избежать огромного количества дублирований одинакового кода. Использование обьектов позволяет наиболее эффективно использовать отладчик. ООП позволяет делать синглтоны. Например, для получения текущих цен, в функциональщине, в каждом месте, get_bid() вы будете делать стандартное получение цены через копирование буфера. Что в конечном итоге, в разы снизит быстродействие вашего советника. В случае с синглтоном - у вас на весь процесс есть один объект отвечающий за маркет дату, в начале OnTick идет вызов обновления цен, а на всех последующих этапах, вы просто дергаете готовые данные. ООП код проще структурировать. У вас есть четкая иерархия классов и сделать спагетти код намного сложнее, чем в случае с функциональщиной. ООП код, как правило, получается намного более компактным и читаемым чем функциональный. В ООП почти невозможно допустить утечку памяти, функциональный же код, который работает с дин памятью, как правило, течет со всех мест. Плюсы же функционального кода (и то не MQL5) - скорость работы и эффективность оптимизации в виду более оптимального ассемблерного кода на выходе. Никаких иных приемуществ он не дает. Равно как и в скорости разработки у функционального программирования приемуществ нет.