ООП для школьников. - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не, они (школьник) не поймут. Тем более матрицы какие-то. Они скажут: нафига нам этот полиморфизм... какой-то?
поли чего...
В чем бред? Открываем определение геттеров и читаем:
А вот механизм, при помощи которого можно получить приватные данные, может быть разным. В C# - это один способ, в C++ и MQL - другой. Но от этого методы не лишаются определения "геттер".Вот и читаем "специальный" метод.
Как раз неудобно - нужно знать в каком элементе х а в каком y. При использовании же структуры все понятно, и это исключает ошибку, сокращает количество кода.
В этом случае, (допустим), структура используется как синтаксический прием, и при обращении к ее данным нужно плодить экземпляры, в отличии от массива, что уравновешивает неудобство.
Смысл использования структуры глубже, но, ТС преподносит ее только в этом качестве. Получается - ООП - набор синтаксических приемов. Именно это усвоят "школьники". Потом, они поймут что можно упростить синтаксис в их задачах и начнут отрицать ООП.
Нужно концептуальное доказательство необходимости ООП, а не синтаксическое.
Вот и читаем "специальный" метод.
Чуть дальше пролистайте статью. Там нет MQL, но есть C++. Или в C++ тоже нет геттеров?
В этом случае, (допустим), структура используется как синтаксический прием, и при обращении к ее данным нужно плодить экземпляры, в отличии от массива, что уравновешивает неудобство.
Смысл использования структуры глубже, но, ТС преподносит ее только в этом качестве. Получается - ООП - набор синтаксических приемов. Именно это усвоят "школьники". Потом, они поймут что можно упростить синтаксис в их задачах и начнут отрицать ООП.
Нужно концептуальное доказательство необходимости ООП, а не синтаксическое.
Ничего не нужно плодить. Работает как с обычным массивом, только все удобней.
Концептуальное доказательство... тогда оно требуется и в сфере производства кирпичей... сразу из глины стены мазать - удобней, и попробуй доказать, что нет.
Чуть дальше пролистайте статью. Там нет MQL, но есть C++. Или в C++ тоже нет геттеров?
Даже и не открывал эту стать. Что я там должен увидеть? Причем тут c++?
Ничего не нужно плодить. Работает как с обычным массивом, только все удобней.
Концептуальное доказательство... тогда оно требуется и в сфере производства кирпичей... сразу из глины стены мазать - удобней, и попробуй доказать, что нет.
Необходимость ООП в работе с данными. ПОВТОРЮ - С ДАННЫМИ.
ООП помогает распределять данные и организовать к ним удобный доступ. ДЛЯ ЭТОГО НУЖНЫ КЛАССЫ И СТРУКТУРЫ.
В задаче координат, данных слишком мало и потому структуры и классы не требуются. Если масштабировать задачу и внести в ее "поле" множество типов данных, то потребуется классификация. А за ней - классы и структуры.
Без необходимости классификации, нет необходимости в классах. Без необходимости в структурировании, - нет необходимости в структурах.
Без многообразия данных объединяемых различными объектами - нет необходимости в ООП.
Внесение ООП в плоские программы с однообразными данными - вредно даже в обучении, потому что неверно выставляет концепцию. Людям начинает казаться, что ООП - набор синтаксических приемов и они используют его как попало. Где надо и не надо.
1. Необходимость ООП в работе с данными. ПОВТОРЮ - С ДАННЫМИ.
ООП помогает распределять данные и организовать к ним удобный доступ. ДЛЯ ЭТОГО НУЖНЫ КЛАССЫ И СТРУКТУРЫ.
2. В задаче координат, данных слишком мало и потому структуры и классы не требуются. Если масштабировать задачу и внести в ее "поле" множество типов данных, то потребуется классификация. А за ней - классы и структуры.
Без необходимости классификации, нет необходимости в классах. Без необходимости в структурировании, - нет необходимости в структурах.
3. Без многообразия данных объединяемых различными объектами - нет необходимости в ООП.
Внесение ООП в плоские программы с однообразными данными - вредно даже в обучении, потому что неверно выставляет концепцию. Людям начинает казаться, что ООП - набор синтаксических приемов и используют его как попало. Где надо и не надо.
1. Пустой разговор. Все программирование, без исключения, это работа с данными.
2. В самой задаче координат мало данных, но если работы много, будет легче. Не надо в ООП искать что-то эпичное. Это способ группировки данных и методов работы с ними, а так же способ многократного использования кода.
3. Любое многообразие, если в нем можно выделить независимые совокупности можно разделить на классы и будет хорошо.Хорошо, перейдем к коду.
Какая была поставлена задача? - Удобно хранить координаты точек. Для чего? - Для быстрого доступа.
Структура POINT и ее экземпляры - лишние сущности в решении, если задача только в быстром доступе к данным. Посмотрите, насколько проще иметь доступ через матрицу:
Вы говорите, что не философ, но "структура" - философское понятие и ее присутствие в решении должно быть оправдано.
Возможно для Вас было бы проще называть: "Рука №1" и "Рука №2", но большинство предпочтут называть их "левая" и "правая".