Вопрос знатокам ООП. - страница 4

 
Igor Makanu:

модификаторы прав доступа позволяют на этапе компиляции выявить ошибки

в общем, все это не затрудняет работу с классами, не нужно не пользуйтесь, пишите все в public: , потом разберетесь будет проще

ЗЫ: Много красивых фраз про ООП, то вот инкапсуляция, то вот наследование... это все хорошо, но самое главное преимущество ООП перед другими стилями программирования - это хранение всех данных (поля класса) и функций работы с этими данными (методы класса) в одном месте (класс) - по книжному это инкапсуляция. Дальше использование ООП зависит от задач, если задача позволяет масштабировать классы, то будет нужна иерархия и будут базовые классы и их наследники - пользоваться ли этим, зависит от Вас

В массиве тоже можно "инкапсулировать" все свойства объекта. Там же можно прописать связи между объектами через конкретные свойства-указатели. Там присутствует порядок, потому что каждое свойство индексировано и его значение храниться в конкретной ячейке. Сами объекты инкапсулируются в ядре. Доступ самый простой - по номеру объекта и по номеру свойства. Переходы между объектами одного элемента управления - через свойства-указатели.
 
Реter Konow:
В массиве тоже можно "инкапсулировать" все свойства объекта. Там же можно прописать связи между объектами через конкретные свойства-указатели. Там присутствует порядок, потому что каждое свойство индексировано и его значение храниться в конкретной ячейке. Сами объекты инкапсулируются в ядре. Доступ самый простой - по номеру объекта и по номеру свойства. Переходы между объектами одного элемента управления - через свойства-указатели.

это не удобно прежде всего!

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

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

если речь идет о ИИ, то тут нужно тоже отделить данные от работы с ними, с ООП будет проще это выполнить

ЗЫ: чем лучше ООП, ну вот например: есть разного типа данные, пусть это в MQL настройки эксперта, и эти настройки имеют повторы блоками, берем один блок настроек, и описываем поля класса, чтобы эти настройки передать в класс, проще всего создать конструктор с параметрами, и затем пишем методы которые работают с этими настройками эксперта. Закончив это все мы создаем или массив экземпляров класса или вообще просто несколько экземпляров класса ( "переменные типа класс" ) и все - задача решена путем написания одного класса, а не созданием нескольких массивов, созданием способов идентификации каждого массива, созданием группы функций которые мало того, чтобы производят изменения данных в массивах, так и главное, чтобы не испортили данные которые не должны быть обработаны при этом вызове.... 

ЗЫЗЫ: имхо, ООП это просто удобно, есть некая легенда, что нефиг пользоваться ООП если не будет наследования... ноу коментс, это будет спор с пеною у рта, без меня 

 
Igor Makanu:

это не удобно прежде всего!

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

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

если речь идет о ИИ, то тут нужно тоже отделить данные от работы с ними, с ООП будет проще это выполнить

ЗЫ: чем лучше ООП, ну вот например: есть разного типа данные, пусть это в MQL настройки эксперта, и эти настройки имеют повторы блоками, берем один блок настроек, и описываем поля класса, чтобы эти настройки передать в класс, проще всего создать конструктор с параметрами, и затем пишем методы которые работают с этими настройками эксперта. Закончив это все мы создаем или массив экземпляров класса или вообще просто несколько экземпляров класса ( "переменные типа класс" ) и все - задача решена путем написания одного класса, а не созданием нескольких массивов, созданием способов идентификации каждого массива, созданием группы функций которые мало того, чтобы производят изменения данных в массивах, так и главное, чтобы не испортили данные которые не должны быть обработаны при этом вызове.... 

ЗЫЗЫ: имхо, ООП это просто удобно, есть некая легенда, что нефиг пользоваться ООП если не будет наследования... ноу коментс, это будет спор с пеною у рта, без меня 

Удобно или нет, субъективный вопрос. Мне ближе табличный расклад данных. Другим - в виде виноградной грозди или дерева. Третьем - еще как то... Но, я серьезно подумаю над Вашими словами и попытаюсь усвоить базовые принципы работы с данными в ООП.
 
Реter Konow:
Удобно или нет, субъективный вопрос. Мне ближе табличный расклад данных. Другим - в виде виноградной грозди или дерева. Третьем - еще как то... Но, я серьезно подумаю над Вашими словами и попытаюсь усвоить базовые принципы работы с данными в ООП.
Я как-то уже вам говорил, что массив указателей на массивы указателей - это двумерная таблица. Один список - строки, списки, лежащие в первом - столбцы. В них могут быть свои списки. И так до заката солнца. Это и есть искомая вами иерархия. И выполняется всего одним классом.
 
Реter Konow:

В ООП под "объектом" понимается ссылка на класс, в котором объявлены его поля (свойства). Я под объектом понимаю нумерованный комплекс свойств, каждое из которых - ячейка в массиве. В этом разница.

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

ЗЫ т.е. если в программе есть класс, но нет его экземпляров, то компилятор проигнорирует (не заметит) этот класс.

ЗЫЫ Есть одно исключение. Память может выделяться при определении класса на статические методы и параметры, если они есть.
 
Artyom Trishkin:
Я как-то уже вам говорил, что массив указателей на массивы указателей - это двумерная таблица. Один список - строки, списки, лежащие в первом - столбцы. В них могут быть свои списки. И так до заката солнца. Это и есть искомая вами иерархия. И выполняется всего одним классом.

В теории - да. Но, нужно все организовать так, чтобы переходы между звениями иерархии (условно - индукция и дедукция. т.е. от частного к общему и обратно) осуществлялись по цепочке. То есть, порядок указателей должен быть структурирован особым образом, чтобы в цикле можно было двигаться в любом (правильном) направлении, без лишних "поворотов" и "перескоков". Поэтому, простая табличная раскладка указателей наверное не подойдет.

Добавлено:

Но, может и подойдет. Пока не знаю.

 
Igor Makanu:

в практическую плоскость нужно эти вопросы переводить, иначе не будет видно что удобно, а что кажется не удобным ))))

вот банальный пример, который по стопятьсот раз используется в MQL - определение нового бара:

ОК, это рабочий код, но что делать если мне нужно определить новый бар на 2-х ТФ? а если хочу использовать все ТФ из терминала?

в ООП это будет примерно так:

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

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

 
Nikolai Semko:
Петр, нужно четко понимать, что при определении самого класса память не выделяется, даже если внутри класса есть экзепляры других классов в качестве его свойств. Поэтому и ссылки на класс не может быть, а только на объект класса. Выделение памяти происходит при объявлении (создании) экземпляра(объекта) класса.
ЗЫ т.е. если в программе есть класс, но нет его экземпляров, то компилятор проигнорирует (не заметит) этот класс.
Не знал. Интересно. Проблема в том, насколько использование ООП позволит легко работать со всеми данными иерархии в циклах. Именно циклы - главные механизмы любого движка. Чем лучше работают циклы - тем больше данных можно перелопатить и больше работы сделать.
 
При создании объекта класса кроме выделения памяти на все свойства(переменные) класса происходит запуск одного из конструкторов(их может быть больше одного). Конструкторы бывают безпараметрические(по умолчанию), параметрические(когда при создании экземпляра класса указываются некоторые параметры, или конструктор копирования, когда в качестве параметра экземпляра класса указывается другой экземпляр класса.
 
Реter Konow:
В теории - да. Но, нужно все организовать так, чтобы переходы между звениями иерархии (условно - индукция и дедукция. т.е. от частного к общему и обратно) осуществлялись по цепочке. То есть, порядок указателей должен быть структурирован особым образом, чтобы в цикле можно было двигаться в любом (правильном) направлении, без лишних "поворотов" и "перескоков". Поэтому, простая табличная раскладка указателей наверное не подойдет.
Все списки уже наделены бинарным поиском. А это означает не поочерёдный  перебор, а фильтрацию по искомому свойству. В итоге получаем индекс искомого элемента.