Структура рулит. Учимся структурировать программы, изучаем возможности, ошибки, решения и т.п. - страница 3

 
Urain:

Да ладно, у меня вообще когда то ни какой модели небыло, потом начал с процедурки, потом перешёл на объектную.

А вообще по умолчанию от MQ мы имеем событийную модель. Нам изначально даны события по которым всё и происходит.

речь об mq5?

что бы уж об одном и том же

 
MetaDriver:
Из ветки "Ошибки, баги, вопросы" :

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

Хотите обсудить варианты?

Вообще это более глобальный вопрос и он не сводится только лишь к организации грамотной событийной модели. Многое зависит от самого языка. К сожалению языковые средства MQL5 находятся на уровне 80-ых годов прошлого века. Современные стандарты программирования далеко ушли от первоначальных принципов ООП программирования. Ныне декомпозиция предпочтительнее наследования, полиморфизм обеспечивается горизонтальными не иерархическими связями на уровне интерфейсов, а повторное использование кода обеспечивается богатыми коллекциями библиотек стандартной поставки, декомпозитным проектированием и прозрачным включением сторонних сборок в проект. 
 
C-4:
Вообще это более глобальный вопрос и он не сводится только лишь к организации грамотной событийной модели. Многое зависит от самого языка. К сожалению языковые средства MQL5 находятся на уровне 80-ых годов прошлого века. Современные стандарты программирования далеко ушли от первоначальных принципов ООП программирования. Ныне декомпозиция предпочтительнее наследования, полиморфизм обеспечивается горизонтальными не иерархическими связями на уровне интерфейсов, а повторное использование кода обеспечивается богатыми коллекциями библиотек стандартной поставки, декомпозитным проектированием и прозрачным включением сторонних сборок в проект. 
Какой язык вы считаете образцом для подражания (по уровню современности и удобства пользования)?
 
Urain:

А есть для например какая нить литературка?

Конкретно на эту тему:

 

 

 
Urain:
Какой язык вы считаете образцом для подражания (по уровню современности и удобства пользования)?

Java/C#

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

 

Прежде чем писать большой проект, неплохо было бы создать четкую налаженную инфраструктуру поддержки проекта:

  • Система резервного копирования и безопасности; 
  • Система контроля версий;
  • Система документации проекта (хорошо если проект к тому же будет самодокументированным);
  • Система тестирования как отдельных модулей так и всего проекта;
 
Urain:

А есть для например какая нить литературка?

Конечно есть. 

//  Насчёт литературы:  давайте делиться литературными источниками.  Но не будем забывать, что живое общение иногда гораздо (на порядки) эффективнее для обучения, нежели книги (даже хорошие).

--

В своё время (в начале 90-х) очень помогла книга:

Б.Лисков, Дж.Гатэг. "Использование абстракций и спецификаций при разработке программ."

Из неё хорошо усвоил основную фишку объектно-ориентированного программирования.  Которая состоит вовсе не в дополнительной возможности нарезать программу на удобные "кубики" - это только дополнительные сопутствующие удобства.  Основная фишка - абстракция данных.

sanyooooook:
ты мыслишь объектно ориентированно, я функционально )
Поясню в нескольких предложениях. 

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

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

2.  Абстракция данных - инкапсуляция базовых структур данных (вместе с базовыми операциями над ними) в отдельные сущности ("классы"), с соблюдением базового правила: никогда не обращаться к ним (инкапсулированным данным) напрямую, обращаться только и исключительно через функции этого же класса, специально для этого созданными ("интерфейс").  Таким образом достигается абстрагирование формы хранения данных от способов работы с этими данными.  И возникает невиданная доселе (в процедурном программировании) возможность - разрабатывать программу не заботясь заранее о способах представления данных.  Поскольку обращение к данным происходит через стандартный неизменный интерфейс, можно совершенствовать способы представления данных на любом этапе разработки проекта, при том что такое изменение не влечёт за собой необходимость изменения других частей проекта.  В процедурном программировании это было невозможно - структура основных данных жёстко определяла способы их обработки.

 
sanyooooook:

ещё перед написанием программы учили делать наброски на бумаге, упрощённый алго язык, но я так к нему и не привык.

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

ЗЫ Я рисую на бумаге, мне так удобнее, иногда до 50 листов уходит пока чёткая структура вырисовывается. Можно конечно в спец.редакторах но каждый из них для меня неудобен (ограничен), невозможно воплотить полёт фантазии, короче тормозят работу.

А что будет с вашей четкой структурой если в середине или даже ближе к окончанию проекта заказчик неожиданно изменит:

  • 5% первоначальных требований;
  • 10% первоначальных требований;
  • 25% первоначальных требований. 

Это хороший тест, показывающий на сколько Ваш проект готов к изменениям и устойчив к ним. На практике, всегда приходится сталкиваться с изменениями в первоначальных требованиях. Поэтому лучше вообще отойти от парадигмы "Предусмотреть все" к парадигме "Задача - решение".