Структура рулит. Учимся структурировать программы, изучаем возможности, ошибки, решения и т.п. - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да ладно, у меня вообще когда то ни какой модели небыло, потом начал с процедурки, потом перешёл на объектную.
А вообще по умолчанию от MQ мы имеем событийную модель. Нам изначально даны события по которым всё и происходит.
речь об mq5?
что бы уж об одном и том же
Из ветки "Ошибки, баги, вопросы" :
Весьма типичная проблема для начала проектирования: как бы так организовать (структурировать) обработку событий в программе, чтобы её (программу) в дальнейшем можно было развивать и при этом минимально переделывать уже сделанное.
Хотите обсудить варианты?
Вообще это более глобальный вопрос и он не сводится только лишь к организации грамотной событийной модели. Многое зависит от самого языка. К сожалению языковые средства MQL5 находятся на уровне 80-ых годов прошлого века. Современные стандарты программирования далеко ушли от первоначальных принципов ООП программирования. Ныне декомпозиция предпочтительнее наследования, полиморфизм обеспечивается горизонтальными не иерархическими связями на уровне интерфейсов, а повторное использование кода обеспечивается богатыми коллекциями библиотек стандартной поставки, декомпозитным проектированием и прозрачным включением сторонних сборок в проект.
А есть для например какая нить литературка?
Конкретно на эту тему:
Какой язык вы считаете образцом для подражания (по уровню современности и удобства пользования)?
Java/C#
И дело даже не в моей предвзятости (хотя куда без нее), а в том, что эти языки конечный продукт длительной эволюции технологий программирования. Они создавались в наше время, и основывались на опыте своих предшественников.
Прежде чем писать большой проект, неплохо было бы создать четкую налаженную инфраструктуру поддержки проекта:
А есть для например какая нить литературка?
Конечно есть.
// Насчёт литературы: давайте делиться литературными источниками. Но не будем забывать, что живое общение иногда гораздо (на порядки) эффективнее для обучения, нежели книги (даже хорошие).
--
В своё время (в начале 90-х) очень помогла книга:
Б.Лисков, Дж.Гатэг. "Использование абстракций и спецификаций при разработке программ."
Из неё хорошо усвоил основную фишку объектно-ориентированного программирования. Которая состоит вовсе не в дополнительной возможности нарезать программу на удобные "кубики" - это только дополнительные сопутствующие удобства. Основная фишка - абстракция данных.
ты мыслишь объектно ориентированно, я функционально )
1. Процедурная (алгоритмическая) абстракция - фишка функционального программирования. Абстрагирующая сущность - процедура (функция). Позволяет отделить запрос на выполнение какого либо действия или вычисления от его реализации. Код функции выделяется в отдельный блок (процедуру, функцию), обращение к этому коду происходит через развязку формальные/фактические параметры (это суть и основная фишка процедурного подхода). Программа получает возможность оставаться неизменной при необходимости изменить способ (алгоритм) вычисления или действия (например записи в файл).
Но если в программе требуется изменить какую либо базовую структуру данных (глобальные массивы, например), это повлечёт за собой необходимость переписывания множества процедур, работающих с этими данными. -- В этом состоит базовое ограничение процедурного стиля программирования
2. Абстракция данных - инкапсуляция базовых структур данных (вместе с базовыми операциями над ними) в отдельные сущности ("классы"), с соблюдением базового правила: никогда не обращаться к ним (инкапсулированным данным) напрямую, обращаться только и исключительно через функции этого же класса, специально для этого созданными ("интерфейс"). Таким образом достигается абстрагирование формы хранения данных от способов работы с этими данными. И возникает невиданная доселе (в процедурном программировании) возможность - разрабатывать программу не заботясь заранее о способах представления данных. Поскольку обращение к данным происходит через стандартный неизменный интерфейс, можно совершенствовать способы представления данных на любом этапе разработки проекта, при том что такое изменение не влечёт за собой необходимость изменения других частей проекта. В процедурном программировании это было невозможно - структура основных данных жёстко определяла способы их обработки.
ещё перед написанием программы учили делать наброски на бумаге, упрощённый алго язык, но я так к нему и не привык.
Сейчас ни один нормальный программист не рисует блок-схемы. Все это теоретический бред разработанный для преподавания школьникам, но не для работы в реальных проектах.
ЗЫ Я рисую на бумаге, мне так удобнее, иногда до 50 листов уходит пока чёткая структура вырисовывается. Можно конечно в спец.редакторах но каждый из них для меня неудобен (ограничен), невозможно воплотить полёт фантазии, короче тормозят работу.
А что будет с вашей четкой структурой если в середине или даже ближе к окончанию проекта заказчик неожиданно изменит:
Это хороший тест, показывающий на сколько Ваш проект готов к изменениям и устойчив к ним. На практике, всегда приходится сталкиваться с изменениями в первоначальных требованиях. Поэтому лучше вообще отойти от парадигмы "Предусмотреть все" к парадигме "Задача - решение".