ООП vs процедурное программирование - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А Вы можете привести конкретный пример этих однотипных задач, которые без ООП лучше не делать?
без ООП решить можно, но с ООП быстрее, я же говорил..
Ну например, шаблон может содержать от 0 до 100 свечных паттернов, от 0 до 30 различных индикаторов и от 1 до 5 различных сигналов в каждом из них.. Получается 1 класс, а конструктором мы можем задать что первый экземпляр у нас будет содержать 23 таких-то паттерна и 2 индикатора по 1 сигналу каждый.. А второй экземпляр будет содержать 12 уже других паттернов и 8 других индикаторов.. Далее устанавливаем условие что оба экземпляра должны дать сигнал на открытие не далее чем на 4 бара друг от друга..
Вся эта муть делается за 5 секунд если паттерны сигналы и все остальное описаны в классе.. И комбинаций всего этого можно делать хоть угодно сколько много, и даже без заказчика, тупо все это автоматом оптимизировать в оптимизаторе и искать выгодные условия входа.. Оптимизатор может методом перебора увеличивать число экземпляров и свойства каждого их них.. ну итд ))
Не этот аргумент главный.
Ну нету в процедурном программировании аналога полиморфизма.
Странно, что за всю свою практику, начиная полным неучем в программировании и в какой то степени оставаясь им до сих пор, я так и не пришел к необходимости использования полиморфизма... Судьба такая наверное.
Черт его знает почему...))
без ООП решить можно, но с ООП быстрее, я же говорил..
Ну например, шаблон может содержать от 0 до 100 свечных паттернов, от 0 до 30 различных индикаторов и от 1 до 5 различных сигналов в каждом из них.. Получается 1 класс, а конструктором мы можем задать что первый экземпляр у нас будет содержать 23 таких-то паттерна и 2 индикатора по 1 сигналу каждый.. А второй экземпляр будет содержать 12 уже других паттернов и 8 других индикаторов.. Далее устанавливаем условие что оба экземпляра должны дать сигнал на открытие не далее чем на 4 бара друг от друга..
Вся эта муть делается за 5 секунд если паттерны сигналы и все остальное описаны в классе.. И комбинаций всего этого можно делать хоть угодно сколько много, и даже без заказчика, тупо все это автоматом оптимизировать в оптимизаторе и искать выгодные условия входа.. Оптимизатор может методом перебора увеличивать число экземпляров и свойства каждого их них.. ну итд ))
Весь этот ООП разводило вселенского масштаба.
Ведь надо иметь ТАКОЙ талант чтобы нечто подобное протолкнуть во всемирном масштабе.
Причем апологетов ничего не останавливает.
Если взять местных апологетов. У них прямо под носом находится справочник по языку мкл. Смотрим разделы. Только три раздела посвящены данным, а все остальные описывают ДЕЙСТВИЯ: программа, операции с массивами, преобразования данных ....
Может быть это язык мкл, не соответствующих "передовым идеям"?
Возьмем гораздо более крупную программную систему: R.
Содержит более 10 000 пакетов, каждый из которых содержит функции - это действия, а не объекты.
По моим представлениям все эти апологеты ООП местного разлива и всемирного ВООБЩЕ ничего не понимают в программировании, а именно: значением (семантикой) любых данных является функция, действие, которая обрабатывает эти данные. Написали int. Смысл этих символов определяется набором команд процессора, который умеет выполнять ДЕЙСТВИЯ с этой переменной.
Далее, перейдем к классам.
Если взять R, для которого классы являются частью языка.
На вход функции подается объект некоторого класса - на выходе получается объект обычно другого класса. Смысл полей на входе-выходе определяется исключительно функцией, которая все это обрабатывает. И если функция не воспринимает конкретный класс, то и смысла такой класс для этой функции не имеет. Именно поэтому документация по каждому пакету точно такая же, как и по мкл: перечисляются действия, функции. А связи между функциями одного пакета или с функциями другого пакета определяются по имени класса, с которыми работает конкретная функция.
Еще раз. В R объекты могут иметь произвольную сложность и реально бывают очень сложными. Но значение каждого поля объекта определенного класса полностью определяется той функцией, которая порождает этот объект.
Особенно это явно для тех писал компиляторы (а я это делал). Пишется некая последовательность кода. Что этот код делает? Какой смысл этого кода? Смысл текста на исходном языке любого языка программирования будет определяться исполняемым кодом, который создаст компилятор, который будет в конечном итоге воспринят процессором. Компилятор с одного языка найдет значение для написанных строчек, а другой не найдет, т.е. для этого другого написанные строчки нет обладают значением.
Отсюда: смысл объекта - это всегда функция, действие, которое способно воспринять входные данные как руководство к действия, и породить на выходе некий перечень полей, значение определяется исключительно этой функцией.
Выше Конов пытался объяснить, что надо идти от ДЕЙСТВИЙ. Надо заниматься действиями, а объекты, соединяющие эти действия - это потом, когда определятся действия. Но ясность, эффективность кода проистекает исключительно из того насколько удачно удалось организовать всю иерархию ДЕЙСТВИЙ и их взаимодействие.
Сторонники ООП говорят: давайте создадим объекты. А какое значение у полей объектов, если не определены действия с этими полями.
Как реализован шаблон который содержит паттерны? Это функция или массив или еще что то? Как записаны сами паттерны?
да обычно они описаны, суть не в этом..
Другой пример.. класс - это как библиотека с книгами,а экземпляр - тележка.. На тележку можно положить книги на выбор из библиотеки.. В оптимизаторе например можно задать сложную задачу что бы был автоматический подбор количества тележек и каждого набора книг в нем.. и искать что профитней ) Библиотеку и 1 тележку можно сделать без ООП, а когда речь о большом количестве тележек, то уже лучше с ООП
Это единственный аргумент в пользу ООП в разработке, который я сейчас принимаю.
Зря принимаете.
В последнем коллективе, в котором я работал, было около 300 человек. Общие трудозатары на всеь программный проект около 1500 человеко-лет. Организация слаженной работы ТАКОГО коллектива никакой ООП не поможет. Для этого существовали другие подходы, связанные с разбивки всей проблемы на этапы и тщательной регламентацией всего и всея на каждом шаге. Существовали ГОСТы, которые это описывали. В программировании - это ЕСПД (единая система программной документации). По трудоемкости собственно кодирование занимало около 20% трудозатрат.
Не слушайте апологетов ООП. Вы на правильном пути. Даже в том, что Вы не объединили две переменные в одну структуру - навар не виден от такого объединения
Еще самый простой пример, который на самой поверхности лежит.. Генератор советников в метаэдиторе... Любой кто даже не умеет программировать может за 10 секунд склепать советник состоящий из огромного числа индикаторов и условий ))) А все это ООП ))
Давайте не будем про генератор, а то я решил более не ругаться матом в течении 2-х месяцев )))
Товарищи разработчики MQ, я вас крупно уважаю. Я серьезно.
И я понимаю причины создания этих конструкторов. Также я понимаю, почему это все эти конструкторы - пукание в вакуум.
Да, это можно рассматривать, как некий пример для изучения MQL5, но ни в коем случае, как старт для реального робота.
Зря принимаете.
В последнем коллективе, в котором я работал, было около 300 человек. Общие трудозатары на всеь программный проект около 1500 человеко-лет. Организация слаженной работы ТАКОГО коллектива никакой ООП не поможет. Для этого существовали другие подходы, связанные с разбивки всей проблемы на этапы и тщательной регламентацией всего и всея на каждом шаге. Существовали ГОСТы, которые это описывали. В программировании - это ЕСПД (единая система программной документации). По трудоемкости собственно кодирование занимало около 20% трудозатрат.
Не слушайте апологетов ООП. Вы на правильном пути. Даже в том, что Вы не объединили две переменные в одну структуру - навар не виден от такого объединения
Сан-Саныч, ко мне недавно обратился якобы проггер, он даже смог что-то продать в Маркете.
Говорит, я попытался склеить несколько программ, а у меня ошибка компиляции, прислал мне свою, так сказать, склейку. Обещал заплатить.
Я глянул и мне поплохело, 59 ошибок компиляции
Куча глобальных переменных типа n,c,m
Все с друг другом конфликтует
А чел уверен, что просто надо кое-что подправить и можно кидать в Маркет
...
По моим представлениям все эти апологеты ООП местного разлива и всемирного ВООБЩЕ ничего не понимают в программировании, а именно: значением (семантикой) любых данных является функция, действие, которая обрабатывает эти данные. Написали int. Смысл этих символов определяется набором команд процессора, который умеет выполнять ДЕЙСТВИЯ с этой переменной.
...
на память
Зря принимаете.
В последнем коллективе, в котором я работал, было около 300 человек. Общие трудозатары на всеь программный проект около 1500 человеко-лет. Организация слаженной работы ТАКОГО коллектива никакой ООП не поможет. Для этого существовали другие подходы, связанные с разбивки всей проблемы на этапы и тщательной регламентацией всего и всея на каждом шаге. Существовали ГОСТы, которые это описывали. В программировании - это ЕСПД (единая система программной документации). По трудоемкости собственно кодирование занимало около 20% трудозатрат.
Не слушайте апологетов ООП. Вы на правильном пути. Даже в том, что Вы не объединили две переменные в одну структуру - навар не виден от такого объединения
Сейчас такие программы пишутся одним человеком за три дня.