Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да в С++ понимание ООП приходит не сразу, я где то через год, полтора после понимания процедурного подхода стал немного въезжать в ООП.
Ну и я так же - понемногу... а полное понимание только через 4-5 лет приходит (и это для обычного человека нормально)
ЗЫ: как изменить цвет кнопки? - убить предыдущий обьект и создать новую кнопку другого цвета? - а статус кнопки как получить? - а если это цветовая схема сотни кнопок - опять все убить и создать другие? ;)
А как это происходит у MQ?
class CButton : public CWndObj :
class CChartObjectText : public CChartObject
class CChartObject : public CObject :
class CWndObj : public CWnd :
Поэтому в класс CButton достаточно добавить функцию:
А как это происходит у MQ?
class CButton : public CWndObj :
class CChartObjectText : public CChartObject
class CChartObject : public CObject :
class CWndObj : public CWnd :
Поэтому в класс CButton достаточно добавить функцию:
все правильно, все приемы ООП выглядят так, хоть в MQL - я смотрел исходники СБ, хоть в Delphi, хоть в VS - структура кода и логика всегда повторяется
вот смотрите, есть у меня в подписках этот канал, в целом я позитивного мнения об авторе, есть и даже повтор темы Вашего видео из за которого спор начался:
и есть еще один канал, который мне нравится:
смысл видео в части ООП диаметрально противоположные
удалил свое сообщение, обсуждение займет больше времени чем планирую, сомневаюсь, что дождусь конкретики, а обсуждать "сферического ООП" без практической пользы, не самая лучшая затея
все правильно, все приемы ООП выглядят так, хоть в MQL - я смотрел исходники СБ, хоть в Delphi, хоть в VS - структура кода и логика всегда повторяется
вот смотрите, есть у меня в подписках этот канал, в целом я позитивного мнения об авторе, есть и даже повтор темы Вашего видео из за которого спор начался:
и есть еще один канал, который мне нравится:
смысл видео в части ООП диаметрально противоположные
удалил свое сообщение, обсуждение займет больше времени чем планирую, сомневаюсь, что дождусь конкретики, а обсуждать "сферического ООП" без практической пользы, не самая лучшая затея
Если честно, я сам только начинаю потихоньку въезжать в ООП. С Егором Бугаенко согласен больше интуитивно и основываясь на том небольшом опыте, который уже есть.
Тем более знаю чисто философски, что усложнение часто заводит в тупик, поэтому считаю, что схема "целое, состоящее из простых компонентов" более совершеннее, чем "целое, состоящее из одного сложного компонента".
Поэтому после просмотра этого видео буду стараться придерживаться следующей логики и парадигмы:
Если в какой-то момент кажется, что единственный путь решения задачи лежит через громоздкое усложнение, значит пришло время на разбиение на более простые элементы. Если кажется, что это невозможно, значит выбрана неправильная концепцию и ее нужно менять и переписывать весь код. Думаю, это в дальнейшем сэкономит время.
Вариантов множество. Все зависит от того что вам надо, и на что хватает фантазии. Например так.
удалил свое сообщение, обсуждение займет больше времени чем планирую
Темы Петра - это безжалостная стихия, которая втягивает всё на своём пути )), это только вступление, впереди выход на "ядро-движок-концепцию", а там у Петра опыта больше )).
Поэтому после просмотра этого видео буду стараться придерживаться следующей логики и парадигмы:
Если в какой-то момент кажется, что единственный путь решения задачи лежит через громоздкое усложнение, значит пришло время на разбиение на более простые элементы. Если кажется, что это невозможно, значит выбрана неправильная концепцию и ее нужно менять и переписывать весь код. Думаю, это в дальнейшем сэкономит время.
в теории это будет работать, на практике - зависит от индустрии в которой Вы будете работать, кроме разработки игр, где любая ошибка будет компенсирована игровым железом геймера или офисный софт, где ошибки тоже не сильно критичны - потом залатаем или перепишем, существуют сферы деятельности программиста, где ошибаться нельзя, я работал на автоматизации производства, причем автоматизация не лампочками помигать, а энергетика - силовые турбины. Софта и автоматики "вагон с тележкой" - стойки САУ, АСУ ТП, виброконтроля, АРМ операторов и контроллеры и датчики исполнительных механизмов, и все это работает одновременно в комплексе, любая ошибка концепции - в лучшем случае это аварийный останов, в худшем разрушение оборудования и материальный ущерб.
К чему это? - опять к тому, что код прежде всего должен быть эффективным! На "не правильном применении ООП" написано все, что годами создавалось, а новаторы... ну посидеть за бокалом пива, помечтать о том, что человечество Майкрософт и Гугл заблуждались - это круто! но пока нет ответственности
Вы мне 1ый написали (значит вас что беспокоит), я вообще на вопросы Alexey Viktorov про Стандартную библиотеку отвечал
Вопрос-то был риторический. Разве это не понятно было?
Вопрос-то был риторический. Разве это не понятно было?
Риторический вопрос содержит очевидное утверждение - я не понял в чем утверждение было. Можете пояснить?
Риторический вопрос никак не может содержать утверждение как и любой вопрос. Вопрос он и в Африке, вопрос. Это тот-же вопрос, но не требующий, не ожидающий ответа. Вопрос в никуда.