Вопрос знатокам ООП. - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
модификаторы прав доступа позволяют на этапе компиляции выявить ошибки
в общем, все это не затрудняет работу с классами, не нужно не пользуйтесь, пишите все в public: , потом разберетесь будет проще
ЗЫ: Много красивых фраз про ООП, то вот инкапсуляция, то вот наследование... это все хорошо, но самое главное преимущество ООП перед другими стилями программирования - это хранение всех данных (поля класса) и функций работы с этими данными (методы класса) в одном месте (класс) - по книжному это инкапсуляция. Дальше использование ООП зависит от задач, если задача позволяет масштабировать классы, то будет нужна иерархия и будут базовые классы и их наследники - пользоваться ли этим, зависит от Вас
В массиве тоже можно "инкапсулировать" все свойства объекта. Там же можно прописать связи между объектами через конкретные свойства-указатели. Там присутствует порядок, потому что каждое свойство индексировано и его значение храниться в конкретной ячейке. Сами объекты инкапсулируются в ядре. Доступ самый простой - по номеру объекта и по номеру свойства. Переходы между объектами одного элемента управления - через свойства-указатели.
это не удобно прежде всего!
тем более, Вы выше уже писали про читаемость кода (как и выше Вы упоминали скорость - скорость выполнения, зависит вообще от другого, а не от стиля программирования)
тут в общем как и везде - не попробуешь не узнаешь, начните писать в стиле ООП, появятся конкретные действия и конкретные вопросы, пример уже есть в этом топике
если речь идет о ИИ, то тут нужно тоже отделить данные от работы с ними, с ООП будет проще это выполнить
ЗЫ: чем лучше ООП, ну вот например: есть разного типа данные, пусть это в MQL настройки эксперта, и эти настройки имеют повторы блоками, берем один блок настроек, и описываем поля класса, чтобы эти настройки передать в класс, проще всего создать конструктор с параметрами, и затем пишем методы которые работают с этими настройками эксперта. Закончив это все мы создаем или массив экземпляров класса или вообще просто несколько экземпляров класса ( "переменные типа класс" ) и все - задача решена путем написания одного класса, а не созданием нескольких массивов, созданием способов идентификации каждого массива, созданием группы функций которые мало того, чтобы производят изменения данных в массивах, так и главное, чтобы не испортили данные которые не должны быть обработаны при этом вызове....
ЗЫЗЫ: имхо, ООП это просто удобно, есть некая легенда, что нефиг пользоваться ООП если не будет наследования... ноу коментс, это будет спор с пеною у рта, без меня
это не удобно прежде всего!
тем более, Вы выше уже писали про читаемость кода (как и выше Вы упоминали скорость - скорость выполнения, зависит вообще от другого, а не от стиля программирования)
тут в общем как и везде - не попробуешь не узнаешь, начните писать в стиле ООП, появятся конкретные действия и конкретные вопросы, пример уже есть в этом топике
если речь идет о ИИ, то тут нужно тоже отделить данные от работы с ними, с ООП будет проще это выполнить
ЗЫ: чем лучше ООП, ну вот например: есть разного типа данные, пусть это в MQL настройки эксперта, и эти настройки имеют повторы блоками, берем один блок настроек, и описываем поля класса, чтобы эти настройки передать в класс, проще всего создать конструктор с параметрами, и затем пишем методы которые работают с этими настройками эксперта. Закончив это все мы создаем или массив экземпляров класса или вообще просто несколько экземпляров класса ( "переменные типа класс" ) и все - задача решена путем написания одного класса, а не созданием нескольких массивов, созданием способов идентификации каждого массива, созданием группы функций которые мало того, чтобы производят изменения данных в массивах, так и главное, чтобы не испортили данные которые не должны быть обработаны при этом вызове....
ЗЫЗЫ: имхо, ООП это просто удобно, есть некая легенда, что нефиг пользоваться ООП если не будет наследования... ноу коментс, это будет спор с пеною у рта, без меня
Удобно или нет, субъективный вопрос. Мне ближе табличный расклад данных. Другим - в виде виноградной грозди или дерева. Третьем - еще как то... Но, я серьезно подумаю над Вашими словами и попытаюсь усвоить базовые принципы работы с данными в ООП.
В ООП под "объектом" понимается ссылка на класс, в котором объявлены его поля (свойства). Я под объектом понимаю нумерованный комплекс свойств, каждое из которых - ячейка в массиве. В этом разница.
ЗЫ т.е. если в программе есть класс, но нет его экземпляров, то компилятор проигнорирует (не заметит) этот класс.
Я как-то уже вам говорил, что массив указателей на массивы указателей - это двумерная таблица. Один список - строки, списки, лежащие в первом - столбцы. В них могут быть свои списки. И так до заката солнца. Это и есть искомая вами иерархия. И выполняется всего одним классом.
В теории - да. Но, нужно все организовать так, чтобы переходы между звениями иерархии (условно - индукция и дедукция. т.е. от частного к общему и обратно) осуществлялись по цепочке. То есть, порядок указателей должен быть структурирован особым образом, чтобы в цикле можно было двигаться в любом (правильном) направлении, без лишних "поворотов" и "перескоков". Поэтому, простая табличная раскладка указателей наверное не подойдет.
Добавлено:
Но, может и подойдет. Пока не знаю.
в практическую плоскость нужно эти вопросы переводить, иначе не будет видно что удобно, а что кажется не удобным ))))
вот банальный пример, который по стопятьсот раз используется в MQL - определение нового бара:
ОК, это рабочий код, но что делать если мне нужно определить новый бар на 2-х ТФ? а если хочу использовать все ТФ из терминала?
в ООП это будет примерно так:
и все что мне теперь нужно будет сделать это обьявить несколько экземпляров класса CNewbar - как? хоть в массив, хоть несколько переменных, но я сразу с помощью ООП защитил данные от случайного изменения
Я уже публично решал эту задачу. Суть была в том, что создается таблица всех символов и всех таймфремов и в цикле по ней, фиксируются произошедшие события нового бара. После первого запроса любой функции этого события, его флаг стирается из таблицы. Насколько это сложнее чем в ООП - не берусь судить. Но, на деле довольно простое и удобное решение.
Петр, нужно четко понимать, что при определении самого класса память не выделяется, даже если внутри класса есть экзепляры других классов в качестве его свойств. Поэтому и ссылки на класс не может быть, а только на объект класса. Выделение памяти происходит при объявлении (создании) экземпляра(объекта) класса.
В теории - да. Но, нужно все организовать так, чтобы переходы между звениями иерархии (условно - индукция и дедукция. т.е. от частного к общему и обратно) осуществлялись по цепочке. То есть, порядок указателей должен быть структурирован особым образом, чтобы в цикле можно было двигаться в любом (правильном) направлении, без лишних "поворотов" и "перескоков". Поэтому, простая табличная раскладка указателей наверное не подойдет.