Peter, you have the PLO like a red rag in front of a bull's eye. No other thread discusses OOP as much as you do. And this despite the fact that you haven't written a single program in this very OOP. Don't you find all this strange?
Vasiliy Sokolov: Peter, you have OOP like a red rag in front of a bull's eye. No other thread discusses OOP as much as you do. And all this despite the fact that you haven't written a single program in this very OOP. Don't you find all this strange?
I am simply responding to suggestions to use OOP within my approach. These approaches are not compatible.
So, I will go on to explain my approach, without explaining why I don't use OOP syntax within it.
If I don't use it, then there is no need to use it.
If you don't understand something, there can never be a need to use it. So whatever you've got going on in your mega-libraries, it "won't be necessary" for OOP.
If you don't understand something, there can never be a need to use it. So whatever you've got in your mega-libraries, there is "no need" for OOP there.
So, let's start with an easy one. Let's create a prototype element inside the proto-kernel:
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]
Peter, you have OOP like a red rag in front of a bull's eye. No other thread discusses OOP as much as you do. And all this despite the fact that you haven't written a single program in this very OOP. Don't you find all this strange?
I am simply responding to suggestions to use OOP within my approach. These approaches are not compatible.
So, I will go on to explain my approach, without explaining why I don't use OOP syntax within it.
If I don't use it, then there's no need to.
Both theses are false.
Don't drag the topicstarter here for 6 pages already, but it is not clear what he wants to show, it is clear that it's all about the kernel ))))
he will show us an example and then we will convince him that OOP saves time in software development ;)
If I don't use it, then there is no need to use it.
If you don't understand something, there can never be a need to use it. So whatever you've got going on in your mega-libraries, it "won't be necessary" for OOP.
If you don't understand something, there can never be a need to use it. So whatever you've got in your mega-libraries, there is "no need" for OOP there.
So, let's start with an easy one. Let's create a prototype element inside the proto-kernel:
And so, the element is represented in the proto-core in expanded, tabular form.
The tabular representation has its advantages. Primarily in loops.
Let's now write a function that will create an item.
But first, let's define the properties of the item via defines, so it's easy to refer to them.
//Вот как будут выглядеть обращения к свойствам элемента: 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]We write a function that will create a button:
Of course, some will say that the kernel is unnecessary. A call like this will suffice:
and everything will be the same. Yes, but only at the beginning. The problem with such a call is that it cannot be properly developed.
We need the properties of each element to be organized in global memory and accessible in the simplest way.