как создавать объекты динамически? (Некоторые вопросы ООП) - страница 4

 

Безусловно. У меня ушли месяцы на создание собственного GUI-фреймворка на MQL, не считая опыта, который я уже имел в прошлом, создавая подобные библиотеки. Самой сложной частью являются не события, а архитектура и почти невозможность отладки кода из-за всех вложенностей и рекурсий, а также из-за состояний мыши, которые становятся недействительными, когда начинается отладка.

Кстати, я предлагал MQ сотрудничество с этими библиотеками несколько месяцев назад и, к сожалению, даже не получил ответа. Но факт в том, что стандартная библиотека управления - это просто хорошая, но и плохая попытка по сравнению с тем, что на самом деле возможно. Можно сделать гораздо лучше. Возможно, я должен предложить библиотеку на рынке здесь, но меня пугает куча работы по написанию всей документации для нее.

 
Doerk Hilger:
Это вообще не вопрос. ООП основана на принципах природы. Земля не кормит вас, она просто предоставляет ресурсы, а вы сами решаете, если, когда и где вам что нужно.
Вы можете сказать, что вы имеете в виду? Я понял общее ощущение от того, что вы говорите, но не совсем ясно.
Вы имеете в виду, что при создании фреймворка нужно просто заботиться о предоставлении ресурсов? Я понял это, но почему-то мне трудно практиковать, потому что моя тенденция слишком сильна.

Например, если я создаю фреймворк и создаю кнопку и радиокнопку, которая является своего рода контейнером кнопки - когда я прихожу к созданию радиокнопки, моя тенденция заключается в том, чтобы думать о зависимом объекте, кнопке в данном случае, и о том, как я с ней взаимодействую. Это привычка процедурного программирования, мне интересно, совершили ли вы когда-то в прошлом переход от процедурного к OO и можете ли вы указать мне на четкое представление о том, на чем мне нужно сосредоточиться в этом случае. Потому что я больше сосредоточен на кнопке (зависимый объект), чем на radiobutton.

Не уверен, что я ясно выразился, это просто вопрос об указании на важные вещи, на которых нужно сосредоточиться при создании уровня во фреймворке.
 
Amir Yacoby:
Можете ли вы сказать, что вы имеете в виду? Я улавливаю общее ощущение от того, что вы говорите, но не совсем ясно.
Вы имеете в виду, что при создании фреймворка нужно просто заботиться о предоставлении ресурсов? Я понял это, но почему-то мне трудно практиковать, потому что моя тенденция слишком сильна.

Например, если я создаю фреймворк и создаю кнопку и радиокнопку, которая является своего рода контейнером кнопки - когда я прихожу к созданию радиокнопки, моя тенденция заключается в том, чтобы думать о зависимом объекте, кнопке в данном случае, и о том, как я с ней взаимодействую. Это привычка процедурного программирования, мне интересно, совершили ли вы когда-то в прошлом переход от процедурного к OO и можете ли вы указать мне на четкое представление о том, на чем мне нужно сосредоточиться в этом случае. Потому что я больше сосредоточен на кнопке (зависимый объект), чем на radiobutton.

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

Возможно, я упустил суть, но я хотел бы высказать свое мнение.

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

Эта тема началась с практического случая, и она превратилась в непонятную дискуссию об ООП. Есть интересная серия статей по GUI, вам стоит посмотреть, затем попробовать построить интерфейс, используя Стандартную библиотеку, и используя библиотеку из этих статей, и изучить код... или нет.

Просто совет, поскольку я действительно не вижу, как вам можно помочь лучше.

Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
  • 2016.02.01
  • Anatoli Kazharski
  • www.mql5.com
This article is the beginning of another series concerning development of graphical interfaces. Currently, there is not a single code library that would allow quick and easy creation of high quality graphical interfaces within MQL applications. By that, I mean the graphical interfaces that we are used to in familiar operating systems.
 
Alain Verleyen:

Возможно, я упустил суть, но я хотел бы высказать свое мнение.

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

Эта тема началась с практического случая, и она превратилась в непонятную дискуссию по ООП. Есть интересная серия статей по GUI, вам стоит посмотреть, затем попробовать построить интерфейс, используя стандартную библиотеку, и используя библиотеку из этих статей, и изучить код... или нет.

Просто совет, поскольку я действительно не вижу, как вам можно помочь лучше.

Ален, я создал интерфейс и читаю статьи.
Может быть, это не место для обсуждения ОО, возможно, вы правы.
Я начал его обсуждать, потому что Doerk представил эту тему как ответ начинающему и рассказал о правильном подходе к ОО.
Сам начинающий заинтересовался презентацией OO от Doerk, и я думаю, что естественно обсудить это здесь.
Возможно, вы правы, что это слишком теоретично, но я считаю, что правильное OO не может быть без привлечения теории, и в конце концов оно становится практичным.

Моя трудность заключается в правильном мышлении ОО, я просто подумал, не может ли Doerk случайно знать из своего опыта о представленной мной умственной трудности.

 
Alain Verleyen:

Есть интересная серия статей по GUI, вам стоит посмотреть, затем попробовать построить интерфейс, используя Стандартную библиотеку, и используя библиотеку из этих статей, и изучить код... или нет.


Я только что скачал ее, чтобы посмотреть, что она делает. И первое впечатление показывает, что они сделали те же самые плохие ошибки, что и со стандартной библиотекой управления. Уже самый первый пример с одним единственным диалоговым окном поднимает использование CPU с 10% (без) до 50-65% (с загрузкой). Это уже лучшее доказательство того, что у авторов нет необходимого опыта для разработки такой библиотеки и что это не может быть - способом сделать это правильно.

Я все равно не понимаю, почему MQ не предоставляет профессиональный GUI фреймворк вместо того, чтобы объяснять, как это (не) делается. Большинство MQL-программистов наверняка хотят разрабатывать советники и индикаторы, но не хотят возиться с такими вещами.

Более того, панель их примера мертва в тестере стратегий, а именно там все эти GUI вещи становятся абсурдными в любом случае. Это не критика в ваш адрес или против того, что вы написали, я сам знаю, что лучшего общедоступного материала для MQL здесь просто нет.

 
Amir Yacoby:

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

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

Здесь нет проблем с обсуждением ООП.

Я не согласен с вашим "ОО не может быть без привлечения теории", но это не важно.

 
Alain Verleyen:

Здесь нет проблем с обсуждением ООП.

Я не согласен с вашим "ООП не может быть без привлечения некоторой теории", но это не имеет значения.

В таком случае, как вы объясните тот факт, что существует плохое ООП программирование? Просто посмотрите на попытку создателей темы решить проблему ОО и ответ Doerks. Должна быть теория, которая делает разницу между правильным и неправильным, не так ли?
 
Doerk Hilger:

Я только что скачал его, чтобы посмотреть, что он делает. И первое впечатление показывает, что они допустили те же ошибки, что и со стандартной библиотекой управления. Уже самый первый пример с одним единственным диалоговым окном поднимает использование процессора с 10% (без) до 50-65% (с загрузкой). Это уже лучшее доказательство того, что у авторов нет необходимого опыта для разработки такой библиотеки и что это не может быть - способом сделать это правильно.

Я все равно не понимаю, почему MQ не предоставляет профессиональный GUI фреймворк вместо того, чтобы объяснять, как это (не) делается. Большинство MQL-программистов наверняка хотят разрабатывать советники и индикаторы, но не хотят возиться с такими вещами.

Более того, панель их примера мертва в тестере стратегий, а именно там все эти GUI вещи становятся абсурдными в любом случае. Это не критика против вас или против того, что вы написали, я сам знаю, что лучшего общедоступного материала для MQL здесь просто нет.

Doerk, скорее всего вы правы, но я не об этом.

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

 
Проблема в том, что этот вопрос слишком сложен, чтобы дать точные инструкции. Именно поэтому я пытаюсь предоставить некоторые идеи и возможные пути тем, кто заинтересован. К сожалению, у меня нет времени ни на написание статьи, ни на публикацию полностью документированной библиотеки. Извините.
 
Doerk Hilger:
Проблема в том, что этот вопрос слишком сложен, чтобы дать точные инструкции. Именно поэтому я пытаюсь предоставить некоторые идеи и возможные пути для тех, кто заинтересован. К сожалению, у меня нет времени ни на написание статьи, ни на публикацию полностью документированной библиотеки. Извините.
Shxxxx. Вы поняли