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