The EOP for schoolchildren. - page 3

New comment
 
Koldun Zloy:

I thought this was obvious even with a small number of dots. If there are thousands of them, and they make up more complex shapes, the advantage will be even greater.

You have shown the "syntactic technique" of writing data and working with it. These are techniques, not the concept of OOP. In simple problems, it is more convenient to work with arrays rather than to hollow out entities from every structure and class, it is not clear why they are squeezed into the solution.

There is such a notion as: mechanism efficiency.

OOP in simple tasks reduces efficiency and readability. You need a hammer to hammer nails and it doesn't matter if it has a display with a punch counter and a force meter.

 
Реter Konow:

You have shown the "syntactic technique" of writing data and working with it. These are techniques, not the concept of OOP. In simple tasks, it is more convenient to work with arrays than to build entities from each structure and class, it is not clear why they are crammed into the solution.

There is such a notion as: mechanism efficiency.

OOP in simple tasks reduces efficiency and readability. To hammer nails, you need a hammer, and it doesn't matter if it has a display with a punch counter and a force meter.

In my example, readability is much better and efficiency is just as good.

I don't know what the "OOP concept" is.

I'm a programmer, not a philosopher.

 
Koldun Zloy:

In my example, the readability is much better and the efficiency is just as good.

I don't know what the concept of OOP is.

I'm a programmer, not a philosopher.

Transferring OOP syntax techniques to small problems, creates unnecessary entities in the solution.

First you have to learn how to make efficient solutions with minimal syntax and "objectivity". Look at algorithms that work with colour. There's nothing superfluous there. Bare mechanisms. That is, hammers and nails. And as things get more complex, move on to the concept of "Object", "Class"...

That's what I would do. But, I won't get in your way.

 
Реter Konow:

Transferring OOP syntax techniques to small problems, creates unnecessary entities in the solution.

First you have to learn how to make efficient solutions with minimal syntax and "objectivity". Look at algorithms that work with colour. There's nothing superfluous there. Bare mechanisms. That is, hammers and nails. And as things get more complex, move on to the concept of "Object", "Class"...

That's what I would do. But, I won't get in your way.

In this thread, I'm asking for concrete examples, not abstract reasoning. What did thePOINT structure do against you?

You are not disturbing me either. This thread is also for you.

 
Koldun Zloy:

Does it change anything?

The syntax changes.

obj.val=1; or obj.val(1);

and vice versa:

x=obj.val; or x=obj.val();

 
Dmitry Fedoseev:

The syntax changes.

obj.val=1; or obj.val(1);

and vice versa:

x=obj.val; or x=obj.val();

I communicate with those who know how not to be rude.

And you get the hell out.

 
Koldun Zloy:

I communicate with people who know how not to be rude.

And you, get out.

Are you out of line?

Yeah... members really don't like to be dipped in their own bullshit.


TheXpert:
essentially no.

And here's the thing: they also like to lick each other.

--

Now, imagine if I'd given you all that crap about a getter and a setter...

--

Koldun Zloy, rename the topic to "schoolboy LLC from schoolboy".

 
Koldun Zloy:

In this thread, I'm asking for concrete examples, not abstract reasoning. What is your problem with thePOINT structure?

You are not bothering me either. This thread is also for you.

Ok, let's move on to the code.

What task was set? - To store coordinates of points. For what? - For quick access.

The POINT structure and its instances are unnecessary entities in the solution if the task is only to quickly access the data. Look how much easier it is to have access via a matrix:

int Points[2][10]; //Объявляем в глобальной области.
//---------------------
//цикл по точкам для вычесления расстояний между ними:
//---------------------
for(int i = 0; i < 9; i++)
  {  
   int x_dist = Points[0][i + 1] - Points[0][i];
   int y_dist = Points[1][i + 1] - Points[1][i];
  }
//--------------------------

You say you're not a philosopher, but "structure" is a philosophical concept and its presence in the solution must be justified.

 
Реter Konow:

OK, let's move on to the code.

What was the objective? - To conveniently store point coordinates. For what? - For the quick access.

The POINT structure and its instances are unnecessary entities in the solution if the task is only to quickly access the data. Look how much easier it is to have access via a matrix:

You say you're not a philosopher, but "structure" is a philosophical concept and its presence in the solution must be justified.

It's just inconvenient - you need to know which element has x and which has y. When using the structure, however, everything is clear, and it eliminates error and reduces the amount of code.

 
Dmitry Fedoseev:


Now imagine if I'd given that nonsense about a getter and a setter.

What's the gibberish? Open the definition of getter and read:

A specialmethod to retrieve data that is directly restricted

But the mechanism by which private data can be retrieved may be different. In C# it is one way, in C++ and MQL it is another. But this does not deprive the methods of the "getter" definition.
12345678910...18
New comment