Вопрос знатокам ООП. - страница 9

Новый комментарий
 
Roman:

Да в С++ понимание ООП приходит не сразу, я где то через год, полтора после понимания процедурного подхода стал немного въезжать в ООП.

Ну и я так же - понемногу... а полное понимание только через 4-5 лет приходит (и это для обычного человека нормально)

 
Igor Makanu:


ЗЫ: как изменить цвет кнопки? - убить предыдущий обьект и создать новую кнопку другого цвета? - а статус кнопки как получить? - а если это цветовая схема сотни кнопок - опять все убить и создать другие?  ;)

А как это происходит у MQ?

class CButton : public CWndObj :

private:
   CChartObjectButton m_button;             // chart object
..
virtual bool      OnSetColor(void)             { return(m_button.Color(m_color));                }

class CChartObjectText : public CChartObject

class CChartObject : public CObject :

bool CChartObject::Color(const color new_color) const
  {
//--- check
   if(m_chart_id==-1)
      return(false);
//--- result
   return(ObjectSetInteger(m_chart_id,m_name,OBJPROP_COLOR,new_color));
  }

class CWndObj : public CWnd :

color             m_color;               // object color
...
bool CWndObj::Color(const color value)
  {
//--- save new value of parameter
   m_color=value;
//--- call virtual event handler
   return(OnSetColor());
  }


Поэтому в класс CButton достаточно добавить функцию:

virtual bool      OnSetColor(uint clr)         { return(m_button.Color(clr));  }
 
Nikolai Semko:

А как это происходит у MQ?

class CButton : public CWndObj :

class CChartObjectText : public CChartObject

class CChartObject : public CObject :

class CWndObj : public CWnd :


Поэтому в класс CButton достаточно добавить функцию:

все правильно, все приемы ООП выглядят так, хоть в MQL - я смотрел исходники СБ, хоть в Delphi, хоть в VS - структура кода и логика всегда повторяется


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



и есть еще один канал, который мне нравится:


смысл видео в части ООП диаметрально противоположные


удалил свое сообщение, обсуждение займет больше времени чем планирую, сомневаюсь, что дождусь конкретики, а обсуждать "сферического ООП"  без практической пользы, не самая лучшая затея

 
Igor Makanu:

все правильно, все приемы ООП выглядят так, хоть в MQL - я смотрел исходники СБ, хоть в Delphi, хоть в VS - структура кода и логика всегда повторяется


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


и есть еще один канал, который мне нравится:


смысл видео в части ООП диаметрально противоположные


удалил свое сообщение, обсуждение займет больше времени чем планирую, сомневаюсь, что дождусь конкретики, а обсуждать "сферического ООП"  без практической пользы, не самая лучшая затея

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

 

Вариантов множество. Все зависит от того что вам надо, и на что хватает фантазии. Например так.

class A
  {
public:
                     A(void)  {    };
                    ~A(void)  {    };
  };
  
class B
  {
public:
                     B(void)  {    };
                    ~B(void)  {    };
  };

class C
  {
public:
                     C(void)  {    };
                    ~C(void)  {    };
  };

struct STest
  {
   A a[];
   B b[];
   C c[];
  } test[];
 
Igor Makanu:

удалил свое сообщение, обсуждение займет больше времени чем планирую

Темы Петра - это безжалостная стихия, которая втягивает всё на своём пути )), это только вступление, впереди выход на "ядро-движок-концепцию", а там у Петра опыта больше )).

 
Nikolai Semko:

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

в теории это будет работать, на практике - зависит от индустрии в которой Вы будете работать, кроме разработки игр, где любая ошибка будет компенсирована игровым железом геймера или офисный софт, где ошибки тоже не сильно критичны - потом залатаем или перепишем, существуют сферы деятельности программиста, где ошибаться нельзя, я работал на автоматизации производства, причем автоматизация не лампочками помигать, а энергетика - силовые турбины. Софта и автоматики "вагон с тележкой" - стойки САУ, АСУ ТП, виброконтроля, АРМ операторов и контроллеры и датчики исполнительных механизмов, и все это работает одновременно в комплексе, любая ошибка концепции - в лучшем случае это аварийный останов, в худшем разрушение оборудования и материальный ущерб.

К чему это? - опять к тому, что код прежде всего должен  быть эффективным! На "не правильном применении ООП" написано все, что годами создавалось, а новаторы... ну посидеть за бокалом пива, помечтать о том, что человечество Майкрософт и Гугл заблуждались - это круто! но пока нет ответственности

 
A100:

Вы мне 1ый написали (значит вас что беспокоит), я вообще на вопросы  Alexey Viktorov про Стандартную библиотеку отвечал 

Вопрос-то был риторический. Разве это не понятно было?

 
Alexey Viktorov:

Вопрос-то был риторический. Разве это не понятно было?

Риторический вопрос содержит очевидное утверждение - я не понял в чем утверждение было. Можете пояснить?
 
A100:
Риторический вопрос содержит очевидное утверждение - я не понял в чем утверждение было. Можете пояснить?

Риторический вопрос никак не может содержать утверждение как и любой вопрос. Вопрос он и в Африке, вопрос. Это тот-же вопрос, но не требующий, не ожидающий ответа. Вопрос в никуда.

12345678910111213141516...55
Новый комментарий