ООП для школьников. - страница 3

Новый комментарий
 
Koldun Zloy:

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

Вы показали "синтаксический прием" записи данных и работы с ними. Это приемы, а не концепция ООП. В простых задачах удобнее работать с массивами, чем городить сущности от каждой структуры и класса, непонятно зачем втиснутых в решение.  

Есть такое понятие как: Эффективность механизма. 

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

 
Реter Konow:

Вы показали "синтаксический прием" записи данных и работы с ними. Это приемы, а не концепция ООП. В простых задачах удобнее работать с массивами, чем городить сущности от каждой структуры и класса, непонятно зачем втиснутых в решение.  

Есть такое понятие как: Эффективность механизма. 

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

В моём примере читабельность намного выше, а эффективность не хуже.

Я не знаю что такое "концепция ООП".

Я программист, а не философ.

 
Koldun Zloy:

В моём примере читабельность намного выше, а эффективность не хуже.

Я не знаю что такое "концепция ООП".

Я программист, а не философ.

Перенос синтаксических приемов ООП в маленькие задачи, создает лишние сущности в решении.

Сначала нужно учиться делать эффективные решения с минимальным синтаксисом и "объектностью". Посмотрите на алгоритмы работающие с цветом. Там ничего лишнего. Голые механизмы. То есть - молотки и гвозди. А по мере усложнения задач, перейти к понятию "Объект", "Класс"… 

Я бы делал так. Но, не буду мешать Вам.

 
Реter Konow:

Перенос синтаксических приемов ООП в маленькие задачи, создает лишние сущности в решении.

Сначала нужно учиться делать эффективные решения с минимальным синтаксисом и "объектностью". Посмотрите на алгоритмы работающие с цветом. Там ничего лишнего. Голые механизмы. То есть - молотки и гвозди. А по мере усложнения задач, перейти к понятию "Объект", "Класс"… 

Я бы делал так. Но, не буду мешать Вам.

В этой теме, прошу конкретные примеры, а не абстрактные рассуждения. Чем Вам помешала структура POINT?

И Вы мне не мешаете. Эта тема, в том числе, и для Вас.

 
Koldun Zloy:

Разве это что-то меняет?

Синтаксис меняется.

obj.val=1; или obj.val(1);

и наоборот:

x=obj.val; или x=obj.val(); 

 
Dmitry Fedoseev:

Синтаксис меняется.

obj.val=1; или obj.val(1);

и наоборот:

x=obj.val; или x=obj.val(); 

Я общаюсь с теми, кто умеет не хамить.

А ты пошёл вон.

 
Koldun Zloy:

Я общаюсь с теми, кто умеет не хамить.

А ты пошёл вон.

Берега попутал?

Да... члены клуба очень не любят когда их окунают в их собственный бред.


TheXpert:
по сути нет.

И вот: еще они любят друга друга лизать.

--

А теперь все представьте, если бы я выдал такой бред про геттер и сеттер

--

Koldun Zloy, переименуй тему в "ООО для школьников от школьника".

 
Koldun Zloy:

В этой теме, прошу конкретные примеры, а не абстрактные рассуждения. Чем Вам помешала структура POINT?

И Вы мне не мешаете. Эта тема, в том числе, и для Вас.

Хорошо, перейдем к коду.

Какая была поставлена задача? - Удобно хранить координаты точек. Для чего? - Для быстрого доступа.

Структура POINT и ее экземпляры - лишние сущности в решении, если задача только в быстром доступе к данным. Посмотрите, насколько проще иметь доступ через матрицу:

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];
  }
//--------------------------

Вы говорите, что не философ, но "структура" - философское понятие и ее присутствие в решении должно быть оправдано.

 
Реter Konow:

Хорошо, перейдем к коду.

Какая была поставлена задача? - Удобно хранить координаты точек. Для чего? - Для быстрого доступа.

Структура POINT и ее экземпляры - лишние сущности в решении, если задача только в быстром доступе к данным. Посмотрите, насколько проще иметь доступ через матрицу:

Вы говорите, что не философ, но "структура" - философское понятие и ее присутствие в решении должно быть оправдано.

Как раз неудобно - нужно знать в каком элементе х а в каком y. При использовании же структуры все понятно, и это исключает ошибку, сокращает количество кода.

 
Dmitry Fedoseev:


А теперь все представьте, если бы я выдал такой бред про геттер и сеттер

В чем бред? Открываем определение геттеров и читаем:

специальный метод, позволяющий получить данные, доступ к которым напрямую ограничен

А вот механизм, при помощи которого можно получить приватные данные, может быть разным. В C# - это один способ, в C++ и MQL - другой. Но от этого методы не лишаются определения "геттер".
12345678910...18
Новый комментарий