Мой подход. Ядро - Движок. - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Формат простой, но не работа с ним. Имею ввиду когда много свойств у объектов.
Вот пример вашего подхода, реально используется, принципы те же. Лексический разбор текста, вручную тут крайне сложно что-то сделать. Только автоматика. И не говорите, что это удобно.
Показанный массив прототипов - это результат ручной инициализации свойств Объектов значениями по умолчанию. Его видит только разработчик.
Главное Ядро - составляется автоматически из прототипов элементов. Потом, прототипы превращаются в конкретные элементы. Тоже автоматически.
Что касается работы с конструктором, - то там простые ключевые слова и удобная форма составления графики. Никаких подобных таблиц там нет.
Вот ещё пример, который вписывается в вашу идею, только много динамических элементов. Тут уже целые стратегии, в примере три штуки. Удобством тут и не пахнет. В прикрепленном файле.
Т.е. что бы соблюсти размерность массива некоторые из твоих объектов имеют фейковые свойства. Очень гибко, ничего не скажешь.
Увы, временно приходится мирится с этим неудобством. Зато, двумерность ядра обеспечивает чрезвычайно удобный и быстрый доступ, построение в циклах и многое другое. Если сделать одномерное ядро, то "фейковых" свойств не будет. Но удобства станет в разы меньше. Или, можно просто поместить свойства текста и иконки в ряд свойств Основания. И проблема устранится. В будущем так и сделаю.
Вот ещё пример, который вписывается в вашу идею, только много динамических элементов. Тут уже целые стратегии, в примере три штуки. Удобством тут и не пахнет. В прикрепленном файле.
Я изначально предупредил читателей, что мой подход не ориентируется на удобство программиста. А предлагает концепцию наиболее мощного и быстрого развития программы.
Конечно скажут, что самое быстрое развитие программы - это подключение готовых блоков. Да, но при этом качество программы падает, а оверхед растет. Соединение блоков - не лучшее решение в плане эффективности.
Я изначально предупредил читателей, что мой подход не ориентируется на удобство программиста. А предлагает концепцию наиболее мощного и быстрого развития программы.
Это удобно, когда напрямую программист не изменяет/создаёт такие данные.
Использование кода, который работает с такими данными довольно удобно.
Я изначально предупредил читателей, что мой подход не ориентируется на удобство программиста. А предлагает концепцию наиболее мощного и быстрого развития программы.
Как могут сосуществовать вместе эти два положения: отсутствие удобства для программиста и быстрое развитие программы? Как можно развивать программу быстро, если это делать неудобно?
А в чем проблема контроллировать? Добавляем свойство, и увеличиваем размер рядов Ядра. Вот и все.
А как вы поступите если необходимо будет сделать не прямоугольную кнопку, а допустим круглую или треугольную?
Если использовать ООП то создается базовый класс Button в котором есть абстрактный метод Draf этот метод отвечает за рисование кнопки. Для круглой кнопки необходимо будет создать наследника от Button в котором достаточно будет переопределить метод Draf в котором реализовать рисование круглой кнопки. Для прямоугольной также достаточно создать наследника от Button и переопределить метод Draf для рисования уже прямоугольной кнопки.
Как все это будет выглядеть если использовать вашу методику?
Вот ещё пример, который вписывается в вашу идею, только много динамических элементов. Тут уже целые стратегии, в примере три штуки. Удобством тут и не пахнет. В прикрепленном файле.
Да вы что!
Это-ж прекрасная штуковина..явный стековый автомат
при минимальном знакомстве с ассемблером и фортом читается влёт. Если бы были коменты, вышло бы не сложнее MQL.
Это удобно, когда напрямую программист не изменяет/создаёт такие данные.
Использование кода, который работает с такими данными довольно удобно.
Поймете, массив прототипов создается один раз. И потом, меняется ОЧЕНЬ редко. Только в случае серьезных переделок в программе.
Да вы что!
Это-ж прекрасная штуковина..явный стековый автомат
при минимальном знакомстве с ассемблером и фортом читается влёт. Если бы были коменты, вышло бы не сложнее MQL.
Штуковина классная). Согласитесь, на MQL программы писать легче чем в таком подобии ассемблера. Я говорю про удобство, эффективность работы.