Петр, у тебя ООП как красная тряпка перед глазами быка. Ни в одной другой ветке столько ООП не обсуждают как с тобой. И это при том, что ты за все это время так и не написал ни одной программы на этом самом ООП. Не находишь все это странным?
Vasiliy Sokolov: Петр, у тебя ООП как красная тряпка перед глазами быка. Ни в одной другой ветке столько ООП не обсуждают как с тобой. И это при том, что ты за все это время так и не написал ни одной программы на этом самом ООП. Не находишь все это странным?
Я просто отвечаю на предложения, использовать ООП внутри моего подхода. Эти подходы не совместимы.
Поэтому, дальше я продолжу объяснять свой подход, без объяснений почему я не использую внутри него синтаксис ООП.
Если что-то не понимаешь, то никогда и не может возникнуть необходимости это использовать. Поэтому что бы ты там не городил в своих мега-библиотеках - для ООП там "не будет необходимости".
Если что-то не понимаешь, то никогда и не может возникнуть необходимости это использовать. Поэтому что бы ты там не городил в своих мега-библиотеках - для ООП там "не будет необходимости".
И так, начнем с простого. Создадим прототип элемента внутри прото-ядра:
int P_CORE[3][5] = {
//Основание кнопки.-----------------------------//// X Y X_SIZE Y_SIZE COLOR //----------------------------------------------
{ 100, 100, 200, 50, C'245,245,245'},
//---------------------------------------------- //Текст кнопки.---------------------------------//// X Y X_SIZE Y_SIZE COLOR //----------------------------------------------
{ 120, 120, 0, 0, C'245,0,0'},
//---------------------------------------------- //Иконка кнопки.-------------------------------- //// X Y X_SIZE Y_SIZE COLOR
{ 140, 140, 16, 16, 0},
//----------------------------------------------
};
P_CORE - массив. Я называю его прото-ядром, потому что он содержит прототип элемента, который далее будет изменен.
Элемент кнопка состоит из 3-ех объектов. Каждому из них мы предоставили 5 свойств.
#define BASE 0#define TEXT 1#define ICON 2//-------------------#define X 0#define X_SIZE 1#define Y 2#define Y_SIZE 3#define BG_COLOR 4#define TEXT_COLOR 4//-------------------
//Вот как будут выглядеть обращения к свойствам элемента:
P_CORE[BASE][X]
P_CORE[BASE][Y]
P_CORE[BASE][X_SIZE]
P_CORE[BASE][Y_SIZE]
P_CORE[BASE][COLOR]
P_CORE[TEXT][X]
P_CORE[TEXT][Y]
P_CORE[TEXT][X_SIZE]
P_CORE[TEXT][Y_SIZE]
P_CORE[TEXT][COLOR]
P_CORE[ICON][X]
P_CORE[ICON][Y]
P_CORE[ICON][X_SIZE]
P_CORE[ICON][Y_SIZE]
P_CORE[ICON][COLOR]
Для авторизации и пользования сайтом MQL5.com необходимо разрешить использование файлов Сookie.
Пожалуйста, включите в вашем браузере данную настройку, иначе вы не сможете авторизоваться.
Вы вошли в аккаунт. Двухфакторная аутентификация отключена. Настройте её заново и отсканируйте новый QR-код или продолжите с отключённой двухфакторной аутентификацией.
Петр, у тебя ООП как красная тряпка перед глазами быка. Ни в одной другой ветке столько ООП не обсуждают как с тобой. И это при том, что ты за все это время так и не написал ни одной программы на этом самом ООП. Не находишь все это странным?
Я просто отвечаю на предложения, использовать ООП внутри моего подхода. Эти подходы не совместимы.
Поэтому, дальше я продолжу объяснять свой подход, без объяснений почему я не использую внутри него синтаксис ООП.
Если не использую, значит нет необходимости.
Оба тезиса ложны.
не драконьте топикстартера! вот уже 6 страниц, а что хочет он показать пока не ясно, ясно что все дело в кернеле )))
покажет пример, потом убедим его, что ООП сокращает время на разработку софта ;)
Если не использую, значит нет необходимости.
Если что-то не понимаешь, то никогда и не может возникнуть необходимости это использовать. Поэтому что бы ты там не городил в своих мега-библиотеках - для ООП там "не будет необходимости".
Если что-то не понимаешь, то никогда и не может возникнуть необходимости это использовать. Поэтому что бы ты там не городил в своих мега-библиотеках - для ООП там "не будет необходимости".
И так, начнем с простого. Создадим прототип элемента внутри прото-ядра:
И так, элемент предствлен в прото-ядре в развернутом, табличном виде.
Табличное представление дает свои преимущества. В первую очередь - в циклах.
Теперь напишем функцию, которая будет создавать элемент.
Но сначала, определим свойства элемента через дефайны, чтобы легко к ним обращаться.
//Вот как будут выглядеть обращения к свойствам элемента: P_CORE[BASE][X] P_CORE[BASE][Y] P_CORE[BASE][X_SIZE] P_CORE[BASE][Y_SIZE] P_CORE[BASE][COLOR] P_CORE[TEXT][X] P_CORE[TEXT][Y] P_CORE[TEXT][X_SIZE] P_CORE[TEXT][Y_SIZE] P_CORE[TEXT][COLOR] P_CORE[ICON][X] P_CORE[ICON][Y] P_CORE[ICON][X_SIZE] P_CORE[ICON][Y_SIZE] P_CORE[ICON][COLOR]Пишем функцию, которая будет создавать кнопку:
Конечно, кто то скажет что ядро не нужно. Достаточно такого вызова:
и все будет тоже самое. Да, но только вначале. Проблема с таким вызовом в том, что его невозможно нормально развивать.
Нам нужно, чтобы свойства каждого элемента были упорядочены в глобальной памяти и к ним был бы наипростейший доступ.