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