Обучение MQL5 - страница 19

Новый комментарий
 
papaklass:
 Можно вопрос? В чем кардинальное отличие процедурного программирования от ООП? Несколько слов,то бишь суть отличия.

Начнем с того, что даже процедурный подход подразумевает наличие структур, ибо без них совсем тяжело. Это хоть какая-то организация данных.

ООП позволяет вполне комфортно выделять абстрактные сущности и взаимосвязи между ними еще на стадии проектирования. А потом просто кодить их, хоть даже по отдельности, не особо заморачиваясь на особенности реализации.

Да и выглядит это все логичней, и читается лучше. И зачастую работает быстрее. А главное реализуется быстрее. Несмотря на то, что кода возможно будет и больше.

 
papaklass:

 Я хотел, что бы Вы высказали свое понимание этого вопроса, а не давали мне книжную формулировку. Нет, значит нет. Скажу о себе.  

Ну, дык я и не "давал книжной формулировки" :) Я вообще ничего не сформулировал, - с объяснением причин. Просто предположил, что задан экзаменационный вопрос, ответ на который Вы уже знаете благодаря таблетке. Так оно и оказалось :) Про личный опыт отвечать не отказывался.

Иногда достаточно "пощупать" явление и, не задаваясь философскими вопросами типа "а как такое может быть" и "в чём его глубинный смысл", просто понять на примере, как оно работает. Мне хватило упоминания в Справочнике про тетрис и хватило для самого-самого начала вот этого примера:

В зависимости от того, объект какого класса создан, вызывается виртуальная  функция того или иного производного  класса.  

void CTetrisField::NewShape()
  {
//--- случайным образом создаём одну из 7 возможных фигур
   int nshape=rand()%7;
   switch(nshape)
     {
      case 0: m_shape=new CTetrisShape1; break;
      case 1: m_shape=new CTetrisShape2; break;
      case 2: m_shape=new CTetrisShape3; break;
      case 3: m_shape=new CTetrisShape4; break;
      case 4: m_shape=new CTetrisShape5; break;
      case 5: m_shape=new CTetrisShape6; break;
      case 6: m_shape=new CTetrisShape7; break;
     }
//--- отрисовываем
   m_shape.Draw();
//---
  }

 

 Интуитивно понятное создание объектов, поведение которых различается в зависимости от исходных данных, - то, что было нужно увидеть, и что достаточно было увидеть. Дальше - запросил на форуме весь файл с тетрисом, плюс материалы Справочника, библиотеки и т.д. И пошло-поехало. Куча вопросов на форуме по теме.

papaklass:
 

Прочитав кучу информации на сайте, я так и не понял, что же такое ООП.

 У нас просто кардинальное различие в подходах. Я особо не задавался вопросом "что же такое ООП" с научной точки зрения. - Чтобы не потерять за фасадом новых и непонятных терминов суть.

Я тупо полез изучать имеющиеся примеры.

papaklass:

Прочитав кучу информации на сайте, я так и не понял, что же такое ООП.

Мы даже имеющуюся информацию читаем по разному :) Ориентирующий ответ на вопрос "что же такое ООП" можно получить уже здесь: Справочник MQL5 / Основы языка / Объектно-ориентированное программирование. Просто прочитайте страничку. Судя по всему, мне этого оказалось достаточно - без необходимости искать иные определения в сторонних материалах.

 
papaklass:

Ответ на мой вопрос: 

 Продедурное программирование концентрирует внимание на действиях (глаголах), а объектно-ориентированное программирование - на предметах, или объектах (существительных). Это главное отличие.


в теории и практики так:

Процедурное программирование отвечает на вопрос что сделать (глаголы),
Объектно-ориентированное программирование - глаголит и описывает(прилагательные) объект(существительное).

То есть ООП - это обобщающая надстройка кода в осмысленные предложения со многими частями речи.


Кто говорит только глаголами, то ему можно жить в процедурах.

Кто желает повествовать свой код, то пусть пишет с ООП.


PS.

Как уже надоели все эти программистские теоретики, блин. 

Скоро темы "ООП vs Процедур" буду безжалостно убивать.
 
sergeev:

PS.

Как уже надоели все эти программистские теоретики, блин. 

Скоро темы "ООП vs Процедур" буду безжалостно убивать.      
Ну зачем же сразу "убивать"? Большинство начинающих в MQL5 знакомы именно с "процедурным програмированием". И если у них появляются вопросы о нужности и смысле ООП - надо терпеливо объяснять/расжёвывать. Как учитель в школе - из года в год одно и то же. Объяснять терпеливо, -  а не посылать нах только потому, что учитель эту тему уже задолбался повторять.
 
sergeev:

PS.

Как уже надоели все эти программистские теоретики, блин. 

Скоро темы "ООП vs Процедур" буду безжалостно убивать.

"Казнить нельзя помиловать" - Вместо расставления знаков препинания по своему хотению - Напишите толковый словарь - И некого будет "безжалостно убивать".

А то почитаешь "практиков" ООП - так прямо "каста" высокодудрых знатоков ООП.

MQL5 - язык для всех уровней понимания и возможностей, а не только для кастированных - штатные примеры индикаторов и советников - тому подтверждение. 

Язык программирования не цель, а средство. Если для достижения цели достаточно ПП - то пусть так и будет. Если кому-то понятней и проще ООП - то пусть и так будет. И для достижения цели - принципиальной разницы нет - особенно в 90% малокодных микрофункциональных индикаторах и советниках, что в основном пишутся.

 

papaklass:

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

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

Язык программирования не цель, а средство. Если для достижения цели достаточно ПП - то пусть так и будет. Если кому-то понятней и проще ООП - то пусть и так будет.  

Мудро. Сужу по себе: Одновалютные индикаторы написаны на ПП. А многовалютный эксперт - с применением ООП (так как без ООП - в моём конкретном случае - он вообще бы не появился).
 

Как уже надоели все эти программистские теоретики, блин. 

Скоро темы "ООП vs Процедур" буду безжалостно убивать.

   А это потому, что нет у народа понимания преимуществ, недостатков, мест и способов употребления того и другого. Статья с такими простыми примерами: ПП даст плюсы для этой задачи_1 такие и минусы такие, ООП даст плюсы для этой задачи_1 такие и минусы такие; ПП даст плюсы для этой задачи_2 такие и минусы такие, ООП даст плюсы для этой задачи_2 такие и минусы такие... Считаю критически важным уделить повышенное внимание сравнению классов и интерфейсов, если последние появятся в пятерке, т.к. для начинающих знакомиться с ООП тонкости и различия могут представлять сложность. И все с уклоном на решение простеньких задач, и в этом сложность - объяснение и примеры нужны по возможности простые и короткие, но использующие принципы ПП и ООП.

   Тогда можно было бы грохать тему отсылая в место где все разложено по полочкам с простыми примерами применения, систематизированными по каким-то темам.

Yedelkin:
Мудро. Сужу по себе: Одновалютные индикаторы написаны на ПП. А многовалютный эксперт - с применением ООП (так как без ООП он вообще бы не появился).
   Уважаемый Yedelkin! Могу вам прислать процедурно-оформленное мультивалютное ядро если интересно(работает по опен бара). Код написан для четверки, но пойдет и на пятерку - можно сравнить на ней быстродействие обоих вариантов.
 
-Alexey-:   Уважаемый Yedelkin! Могу вам прислать процедурно-оформленное мультивалютное ядро если интересно(работает по опен бара). Код написан для четверки.
Я - за то, чтоб, по возможности, все жили дружно и во взаимопонимании. Что касается именно моих сообщений, - то описывал исключительно своё понимание ООП. Оно (понимание) может быть трижды ошибочным, - но оно "моё". Совершенно не исключаю, что часть задач, которые мне удалось решить при помощи ООП, можно решить и в рамках ПП. Мудрость высказывания abolk'а как раз в том, что "Если для достижения цели достаточно ПП - то пусть так и будет. Если кому-то понятней и проще ООП - то пусть и так будет". Дополнение в своё сообщение внёс.
 
Yedelkin:
Я - за то, чтоб, по возможности, все жили дружно и во взаимопонимании. Что касается именно моих сообщений, - то описывал исключительно своё понимание ООП. Оно (понимание) может быть трижды ошибочным, - но оно "моё". Совершенно не исключаю, что часть задач, которые мне удалось решить при помощи ООП, можно решить и в рамках ПП. Мудрость высказывания abolk'а как раз в том, что "Если для достижения цели достаточно ПП - то пусть так и будет. Если кому-то понятней и проще ООП - то пусть и так будет".
Согласен. А для того, чтобы пободаться по настроению за то или иное предпочтение, лучше всего устраивать конкурсы-соревнования между форумчанами. Есть такая задача ...: какой подход в ней конкретно победит по быстродействию, расходованию памяти, размеру кода, портируемости...?
1...1213141516171819202122
Новый комментарий
Причина обращения: