как создавать объекты динамически? (Некоторые вопросы ООП) - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Безусловно. У меня ушли месяцы на создание собственного GUI-фреймворка на MQL, не считая опыта, который я уже имел в прошлом, создавая подобные библиотеки. Самой сложной частью являются не события, а архитектура и почти невозможность отладки кода из-за всех вложенностей и рекурсий, а также из-за состояний мыши, которые становятся недействительными, когда начинается отладка.
Кстати, я предлагал MQ сотрудничество с этими библиотеками несколько месяцев назад и, к сожалению, даже не получил ответа. Но факт в том, что стандартная библиотека управления - это просто хорошая, но и плохая попытка по сравнению с тем, что на самом деле возможно. Можно сделать гораздо лучше. Возможно, я должен предложить библиотеку на рынке здесь, но меня пугает куча работы по написанию всей документации для нее.
Это вообще не вопрос. ООП основана на принципах природы. Земля не кормит вас, она просто предоставляет ресурсы, а вы сами решаете, если, когда и где вам что нужно.
Вы имеете в виду, что при создании фреймворка нужно просто заботиться о предоставлении ресурсов? Я понял это, но почему-то мне трудно практиковать, потому что моя тенденция слишком сильна.
Например, если я создаю фреймворк и создаю кнопку и радиокнопку, которая является своего рода контейнером кнопки - когда я прихожу к созданию радиокнопки, моя тенденция заключается в том, чтобы думать о зависимом объекте, кнопке в данном случае, и о том, как я с ней взаимодействую. Это привычка процедурного программирования, мне интересно, совершили ли вы когда-то в прошлом переход от процедурного к OO и можете ли вы указать мне на четкое представление о том, на чем мне нужно сосредоточиться в этом случае. Потому что я больше сосредоточен на кнопке (зависимый объект), чем на radiobutton.
Не уверен, что я ясно выразился, это просто вопрос об указании на важные вещи, на которых нужно сосредоточиться при создании уровня во фреймворке.
Можете ли вы сказать, что вы имеете в виду? Я улавливаю общее ощущение от того, что вы говорите, но не совсем ясно.
Вы имеете в виду, что при создании фреймворка нужно просто заботиться о предоставлении ресурсов? Я понял это, но почему-то мне трудно практиковать, потому что моя тенденция слишком сильна.
Например, если я создаю фреймворк и создаю кнопку и радиокнопку, которая является своего рода контейнером кнопки - когда я прихожу к созданию радиокнопки, моя тенденция заключается в том, чтобы думать о зависимом объекте, кнопке в данном случае, и о том, как я с ней взаимодействую. Это привычка процедурного программирования, мне интересно, совершили ли вы когда-то в прошлом переход от процедурного к OO и можете ли вы указать мне на четкое представление о том, на чем мне нужно сосредоточиться в этом случае. Потому что я больше сосредоточен на кнопке (зависимый объект), чем на radiobutton.
Не уверен, что я ясно выразился, это просто вопрос об указании важных вещей, на которых нужно сосредоточиться при создании уровня во фреймворке.
Возможно, я упустил суть, но я хотел бы высказать свое мнение.
Я думаю, что вы слишком много внимания уделяете "теории", и ждете света от кого-то другого. Нет одного идеального решения, есть решения, и вам нужно найти его, исходя из вашего опыта и ваших конкретных потребностей.
Эта тема началась с практического случая, и она превратилась в непонятную дискуссию об ООП. Есть интересная серия статей по GUI, вам стоит посмотреть, затем попробовать построить интерфейс, используя Стандартную библиотеку, и используя библиотеку из этих статей, и изучить код... или нет.
Просто совет, поскольку я действительно не вижу, как вам можно помочь лучше.
Возможно, я упустил суть, но я хотел бы высказать свое мнение.
Мне кажется, вы слишком много внимания уделяете "теории", и ждете света от кого-то другого. Нет одного идеального решения, есть решения, и вы должны найти его на основе вашего опыта и ваших конкретных потребностей.
Эта тема началась с практического случая, и она превратилась в непонятную дискуссию по ООП. Есть интересная серия статей по GUI, вам стоит посмотреть, затем попробовать построить интерфейс, используя стандартную библиотеку, и используя библиотеку из этих статей, и изучить код... или нет.
Просто совет, поскольку я действительно не вижу, как вам можно помочь лучше.
Ален, я создал интерфейс и читаю статьи.
Может быть, это не место для обсуждения ОО, возможно, вы правы.
Я начал его обсуждать, потому что Doerk представил эту тему как ответ начинающему и рассказал о правильном подходе к ОО.
Сам начинающий заинтересовался презентацией OO от Doerk, и я думаю, что естественно обсудить это здесь.
Возможно, вы правы, что это слишком теоретично, но я считаю, что правильное OO не может быть без привлечения теории, и в конце концов оно становится практичным.
Моя трудность заключается в правильном мышлении ОО, я просто подумал, не может ли Doerk случайно знать из своего опыта о представленной мной умственной трудности.
Есть интересная серия статей по GUI, вам стоит посмотреть, затем попробовать построить интерфейс, используя Стандартную библиотеку, и используя библиотеку из этих статей, и изучить код... или нет.
Я только что скачал ее, чтобы посмотреть, что она делает. И первое впечатление показывает, что они сделали те же самые плохие ошибки, что и со стандартной библиотекой управления. Уже самый первый пример с одним единственным диалоговым окном поднимает использование CPU с 10% (без) до 50-65% (с загрузкой). Это уже лучшее доказательство того, что у авторов нет необходимого опыта для разработки такой библиотеки и что это не может быть - способом сделать это правильно.
Я все равно не понимаю, почему MQ не предоставляет профессиональный GUI фреймворк вместо того, чтобы объяснять, как это (не) делается. Большинство MQL-программистов наверняка хотят разрабатывать советники и индикаторы, но не хотят возиться с такими вещами.
Более того, панель их примера мертва в тестере стратегий, а именно там все эти GUI вещи становятся абсурдными в любом случае. Это не критика в ваш адрес или против того, что вы написали, я сам знаю, что лучшего общедоступного материала для MQL здесь просто нет.
Ален, я создал интерфейс и прочитал статьи.
Может быть, это не место для обсуждения ООП, возможно, вы правы.
Я начал обсуждать это, потому что Doerk представил эту тему как ответ начинающему и говорил о правильном подходе к ООП.
Сам начинающий заинтересовался презентацией OO от Doerk, и я думаю, что естественно обсудить это здесь.
Возможно, вы правы, что это слишком теоретично, но я считаю, что правильное OO не может быть без привлечения теории, и в конце концов оно становится практичным.
Моя трудность заключается в правильном мышлении ОО, я просто хотел узнать, может быть Doerk случайно знает из своего опыта ту ментальную трудность, которую я представил.
Здесь нет проблем с обсуждением ООП.
Я не согласен с вашим "ОО не может быть без привлечения теории", но это не важно.
Здесь нет проблем с обсуждением ООП.
Я не согласен с вашим "ООП не может быть без привлечения некоторой теории", но это не имеет значения.
Я только что скачал его, чтобы посмотреть, что он делает. И первое впечатление показывает, что они допустили те же ошибки, что и со стандартной библиотекой управления. Уже самый первый пример с одним единственным диалоговым окном поднимает использование процессора с 10% (без) до 50-65% (с загрузкой). Это уже лучшее доказательство того, что у авторов нет необходимого опыта для разработки такой библиотеки и что это не может быть - способом сделать это правильно.
Я все равно не понимаю, почему MQ не предоставляет профессиональный GUI фреймворк вместо того, чтобы объяснять, как это (не) делается. Большинство MQL-программистов наверняка хотят разрабатывать советники и индикаторы, но не хотят возиться с такими вещами.
Более того, панель их примера мертва в тестере стратегий, а именно там все эти GUI вещи становятся абсурдными в любом случае. Это не критика против вас или против того, что вы написали, я сам знаю, что лучшего общедоступного материала для MQL здесь просто нет.
Doerk, скорее всего вы правы, но я не об этом.
Вы должны написать конкретный пример, почему происходит эта проблема с процессором, объяснить Анатолию (автору статьи), в чем проблема. Мне жаль говорить, что до сих пор все, что вы сказали, почти бесполезно, даже если вы правы на 100%. Все слишком общо и теоретично. Не обижайтесь.
Проблема в том, что этот вопрос слишком сложен, чтобы дать точные инструкции. Именно поэтому я пытаюсь предоставить некоторые идеи и возможные пути для тех, кто заинтересован. К сожалению, у меня нет времени ни на написание статьи, ни на публикацию полностью документированной библиотеки. Извините.