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