Обсуждение статьи "Графические интерфейсы XI: Рефакторинг кода библиотеки (build 14.1)" - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
От Вас, кроме пустозвонства, больше и нет ничего. )
Всё, что сделано, уж точно не благодаря тому, что это Вы так сказали. Всё это было запланировано изначально и публиковалось строго в определённой последовательности. Но Вы конечно же можете думать иначе и далее пребывать, как Вы говорите, в "хаосе отчаянных поисков для обретения новой версии себя". Я не против. )
Я также говорил, что технологический рост обуславливается не только расширением и добавлением функционала, но и сжатием и универсализацией кода. Объединением разрозненных функций в блоки. Именно это Вы и продемонстрировали в статье.
Вы многократно объединили несколько классов в один и сжали код. При этом, классы стали более универсальными в том смысле, что один класс содержит в себе несколько похожих элементов и их выбор осуществляется режимом. Это и есть сжатие и универсализация.
И опять я был прав.
Так в чем же я не прав?
Конечно, Вы все сделали не благодаря тому, что я говорил. Я это знаю. Только ведь я был прав в том, что говорил...
Помните единственный способ избавиться от тролля? Правильно, не кормить его.
Помните единственный способ избавиться от тролля? Правильно, не кормить его.
Некоторые пояснения дам. На десерт. )
...
Конечно, Вы все сделали не благодаря тому, что я говорил. Я это знаю. Только ведь я был прав в том, что говорил...
Да какая разница, правы Вы или нет? ) Независимо от того, что Вам скажут другие, всё равно Вы останетесь для самого себя таким, каким сами себя считаете. )
Вы говорили само собой разумеющиеся вещи и Вам на это было изначально указано. Но кроме этого Вы ещё много всяких глупостей транслировали. Например, что с помощью ООП нельзя реализовать такую схему эффективно. Хотя, как Вы могли сделать такие выводы, если даже ООП не знаете?
А Вы обратили внимание, что общая схема осталась такой же, как и до рефакторинга? И сложности в таком переходе, как раз таки и не было. Основное время ушло просто на то, чтобы перебрать несколько десятков файлов, а также на тесты.
В текущей реализации переход на третий этап был бы ещё проще. Сложность как раз не в этом. Если бы я делал такую реализацию, то я бы всё рисовал от начала и до конца на одном объекте, а не как это было продемонстрировано некоторыми участниками форума, когда некоторые объекты иногда (на время использования) появляются поверх основного GUI. С точки зрения личного развития, как программиста, мне такие полумеры уже неинтересны. Это недалеко уходит от того, что сделано сейчас в версии представленной в статье. А пользователи MQL-приложений вообще разницы не увидят.
В моей текущей версии все элементы рисуются на отдельных объектах и есть только одно исключение — объекты-графики (OBJ_CHART). Реализовать такой элемент в нарисованном виде в таком качестве и с такими возможностями было бы конечно интересно, но на данный момент в этом просто нет смысла. Есть вещи, которые мне намного более интересны в представленных разработчиками MQ сервисах на этом сайте. Ещё буквально две-три статьи на тему "графические интерфейсы" в ближайшее время, а потом обновления, если и будут выходить, то очень редко. В основном это будет глубокая оптимизация библиотеки, когда потребление ресурсов будет сведено к максимально возможному минимуму.
Некоторые пояснения дам. На десерт. )
1. Да какая разница, правы Вы или нет? ) Независимо от того, что Вам скажут другие, всё равно Вы останетесь для самого себя таким, каким сами себя считаете. )
2. Вы говорили само собой разумеющиеся вещи и Вам на это было изначально указано. Но кроме этого Вы ещё много всяких глупостей транслировали.
3.Например, что с помощью ООП нельзя реализовать такую схему эффективно. Хотя, как Вы могли сделать такие выводы, если даже ООП не знаете?
4. А Вы обратили внимание, что общая схема осталась такой же, как и до рефакторинга? И сложности в таком переходе, как раз таки и не было. Основное время ушло просто на то, чтобы перебрать несколько десятков файлов, а также на тесты.
5. В текущей реализации переход на третий этап был бы ещё проще. Сложность как раз не в этом. Если бы я делал такую реализацию, то я бы всё рисовал от начала и до конца на одном объекте, а не как это было продемонстрировано некоторыми участниками форума, когда некоторые объекты иногда (на время использования) появляются поверх основного GUI. С точки зрения личного развития, как программиста, мне такие полумеры уже неинтересны. Это недалеко уходит от того, что сделано сейчас в версии представленной в статье. А пользователи MQL-приложений вообще разницы не увидят.
В моей текущей версии все элементы рисуются на отдельных объектах и есть только одно исключение — объекты-графики (OBJ_CHART). Реализовать такой элемент в нарисованном виде в таком качестве и с такими возможностями было бы конечно интересно, но на данный момент в этом просто нет смысла. Есть вещи, которые мне намного более интересны в представленных разработчиками MQ сервисах на этом сайте. Ещё буквально две-три статьи на тему "графические интерфейсы" в ближайшее время, а потом обновления, если и будут выходить, то очень редко. В основном это будет глубокая оптимизация библиотеки, когда потребление ресурсов будет сведено к максимально возможному минимуму.
1. Не совсем так. Если я не прав и тому есть убедительные доказательства, - то я это признаю и меняю свою точку зрения.
2. Зачастую эти очевидные вещи, совсем не очевидны. Умение разработчика мыслить абстрактно, и масштабно понимать процесс разработки, - это плюс. Я не нашел этого понимания у Вас, потому и говорил об этом. Мне интересна философская подоплека действия, а не только копание в деталях и рутина. Вычленение и видиние сути. Знание сценария и логики процесса ценно для некоторых людей. )
3. Насколько эффективна реализованная схема сейчас сказать сложно. Это относительно. Однако, существуют параметры по которым можно определить эффективность реализации. Я думаю, их можно найти. В этом случае можно было бы сравнить эффективность реализации тех же механизмов, но сделанных по другой технологии. Вот тогда, можно сделать вывод об эффективности. Если хотите, мы можем с Вами это попробывать выяснить. Я попрежнему считаю эту реализацию недостаточно эффективной. Увы, есть основания.
4. Не совсем таже схема. Вы сделали изменения в базовых классах. В "ядре" библиотеки. О чем сами и сказали в статье. Внешне, схема похожа, но вы же перешли на другую технологию создания элементов.
5. Я кстати, никогда не говорил, что хочу сделать полностью рисованный GUI на одном битмапе. Считаю эту затею плохой. Это очевидно не лучшее решение со многих точек зрения. Так что для меня, - это не "полумеры", а выбор в сторону более практичного варианта.
Добавлю: Сделать все на одном битмапе можно следующим образом: Все рисованные элементы - это массивы с пикселями изображения. После того, как они созданы, вы создаете один битмап и большой массив изображения и пихаете в него последовательно содержание каждого элемента. В результате, у вас получается битмап с полным изображением всего содержания окна. Я нахожусь на один шаг от этого. Думаю, Вы тоже можете это сделать.
...
Вот тогда, можно сделать вывод об эффективности. Если хотите, мы можем с Вами это попробывать выяснить. Я попрежнему считаю эту реализацию недостаточно эффективной. Увы, есть основания.
...
...
Добавлю: Сделать все на одном битмапе можно следующим образом: Все рисованные элементы - это массивы с пикселями изображения. После того, как они созданы, вы создаете один битмап и большой массив изображения и пихаете в него последовательно содержание каждого элемента. В результате, у вас получается битмап с полным изображением всего содержания окна.
...
Без комментариев, Капитан Очевидность. )
Вы сначала опубликуйтесь эффективно. А то кроме Вас предмет Вашей "эффективности" в руках ещё никто не держал. Наверное из-за того, что очень уж эффективная эффективность получилась, что показывать страшно. )
Без комментариев, Капитан Очевидность. )
Ну так давайте сравним эффективность? Я же прямо предложил.
Я не против. Сравнивайте. )
Ок.
1. Сначала мы определимся с критериями оценки эффективности применяемой технологии.
2. Потом мы определимся с критериями оценки эффективности реализованных механизмов.
3. Выберем одинаковые механизмы сделанные и у меня и у Вас и проведем с ними тесты.
После этого, мы придем к однозначному выводу.
Согласны с планом?
...
Сначала мы
...
Не мы, а Вы. Мне есть, чем заняться (читайте внимательней). Желания тратить время впустую у меня нет. )
Жаль.
Жаль что бойцовский дух сейчас где то отдыхает...)