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

 
Dmitry Fedoseev:

Не, они (школьник) не поймут. Тем более матрицы какие-то. Они скажут: нафига нам этот полиморфизм... какой-то?

поли чего...

 
Ihor Herasko:

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

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

Вот и читаем "специальный" метод.

 
Dmitry Fedoseev:

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

В этом случае, (допустим), структура используется как синтаксический прием, и при обращении к ее данным нужно плодить экземпляры, в отличии от массива, что уравновешивает неудобство.

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

Нужно концептуальное доказательство необходимости ООП, а не синтаксическое. 

 
Спасибо за ветку. Мне нравится
 
Dmitry Fedoseev:

Вот и читаем "специальный" метод.

Чуть дальше пролистайте статью. Там нет MQL, но есть C++. Или в C++ тоже нет геттеров?

 
Реter Konow:

В этом случае, (допустим), структура используется как синтаксический прием, и при обращении к ее данным нужно плодить экземпляры, в отличии от массива, что уравновешивает неудобство.

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

Нужно концептуальное доказательство необходимости ООП, а не синтаксическое. 

Ничего не нужно плодить. Работает как с обычным массивом, только все удобней.

Концептуальное доказательство... тогда оно требуется и в сфере производства кирпичей... сразу из глины стены мазать - удобней, и попробуй доказать, что нет.

 
Ihor Herasko:

Чуть дальше пролистайте статью. Там нет MQL, но есть C++. Или в C++ тоже нет геттеров?

Даже и не открывал эту стать. Что я там должен увидеть? Причем тут c++? 

 
Dmitry Fedoseev:

Ничего не нужно плодить. Работает как с обычным массивом, только все удобней.

Концептуальное доказательство... тогда оно требуется и в сфере производства кирпичей... сразу из глины стены мазать - удобней, и попробуй доказать, что нет.

Необходимость ООП в работе с данными. ПОВТОРЮ - С ДАННЫМИ.

ООП помогает распределять данные и организовать к ним удобный доступ. ДЛЯ ЭТОГО НУЖНЫ КЛАССЫ И СТРУКТУРЫ. 


В задаче координат, данных слишком мало и потому структуры и классы не требуются. Если масштабировать задачу и внести в ее "поле" множество типов данных, то потребуется классификация. А за ней - классы и структуры.

Без необходимости классификации, нет необходимости в классах. Без необходимости в структурировании, - нет необходимости в структурах. 

Без многообразия данных объединяемых различными объектами - нет необходимости в ООП.

Внесение ООП в плоские программы с однообразными данными - вредно даже в обучении, потому что неверно выставляет концепцию. Людям начинает казаться, что ООП - набор синтаксических приемов и они используют его как попало. Где надо и не надо.

 
Реter Konow:

1. Необходимость ООП в работе с данными. ПОВТОРЮ - С ДАННЫМИ.

ООП помогает распределять данные и организовать к ним удобный доступ. ДЛЯ ЭТОГО НУЖНЫ КЛАССЫ И СТРУКТУРЫ. 


2. В задаче координат, данных слишком мало и потому структуры и классы не требуются. Если масштабировать задачу и внести в ее "поле" множество типов данных, то потребуется классификация. А за ней - классы и структуры.

Без необходимости классификации, нет необходимости в классах. Без необходимости в структурировании, - нет необходимости в структурах. 

3. Без многообразия данных объединяемых различными объектами - нет необходимости в ООП.

Внесение ООП в плоские программы с однообразными данными - вредно даже в обучении, потому что неверно выставляет концепцию. Людям начинает казаться, что ООП - набор синтаксических приемов и используют его как попало. Где надо и не надо.

1. Пустой разговор. Все программирование, без исключения, это работа с данными. 

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

3. Любое многообразие, если в нем можно выделить независимые совокупности можно разделить на классы и будет хорошо.
 
Реter Konow:

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

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

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

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

Возможно для Вас было бы проще называть: "Рука №1" и "Рука №2", но большинство предпочтут называть их "левая" и "правая".