Мой подход. Ядро - Движок. - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
не смог пройти мимо... а какое разрешение монитора нужно, чтобы такие горизонтальные "портянки" кода видеть??
как то неудобно смотреть в редактор и гонять туда сюда полосы прокрутки, чтобы редактировать или посмотреть код ))))
И так.
Первое преимущество моего подхода - это Сжатость. Меньше слов - больше цифр. Объект - вектор. Элемент - комплекс векторов внутри матрицы. Комплекс Элементов - Окно. Комплекс окон - Ядро.
Суть в том, что Объект не обязательно должен быть графическим. Элемент можно сделать Понятием, и наделить его не меньшим количеством Объектов и свойств. А движок будет логической машиной работающей с этими понятиями(Элементами).
ООП очень гибкая методология, поэтому в нем нет каких-либо априорных идей вроде понятия "ядра". Однако с помощью ООП очень хорошо можно построить модель ядра, о которой здесь ведется речь. Поэтому утверждение не совсем корректное.
Да, я сам поглядел, и удивился - Петер описывает как есть ООП-штуку.
Но, как я понял, Петер как достоинство выносит возможность пользователя иметь полный доступ ко всем свойствам и методам Ядра. А ООП-стиль - это как раз инкапсуляция, когда права доступа всемерно ограничиваются.
Помню, в молодости я тоже жутко возмущался, что в защищенном режиме мне не доступна вся память компьютера. Как это так, какие-то, понимаешь, программы будут запускаться, а я не могу получить доступ к их памяти... Специально строил "обходные маневры" с помощью программирования контроллера прямого доступа к памяти, даже получал содержимое памяти другого процесса, недоступного мне из программы (правда, для этого надо использовать команды доступа к портам контроллера ПДП, а это само по себе непросто в многозадачной среде Виндовс, я использовал специальный драйвер).
И лишь потом понял, что защищенный режим, разделение доступа (да и вобще инкапсуляция) - это очень важная штука, необходимая мне же. Чтобы я не влезал случайно туда, куда лезть нельзя. И поэтому сейчас я твердо стою на позиции "в любом месте программы процессу должны быть доступны исключительно лишь те ресурсы, свойства и методы, которые ему нужны конкретно сейчас".
Но, Петер, как я понимаю, не сторонник инкапсуляции.
не смог пройти мимо... а какое разрешение монитора нужно, чтобы такие горизонтальные "портянки" кода видеть??
как то неудобно смотреть в редактор и гонять туда сюда полосы прокрутки, чтобы редактировать или посмотреть код ))))
Как я говорил, в моем подходе удобство не главное. Главное - эффективность и потенциал развития и применения.
Как я говорил, в моем подходе удобство не главное. Главное - эффективность и потенциал развития и применения.
ОК, подожду еще примеров кода, но пока очень не читаемый код вижу, может быть что прояснится позже
ООП очень гибкая методология, поэтому в нем нет каких-либо априорных идей вроде понятия "ядра". Однако с помощью ООП очень хорошо можно построить модель ядра, о которой здесь ведется речь. Поэтому утверждение не совсем корректное.
Условное ядро можно построить. Думаю, серьезные программы это и делают. Но, у меня все построено на "физическом" ядре.
ОК, подожду еще примеров кода, но пока очень не читаемый код вижу, может быть что прояснится позже
Смотрите. Показанное лишь общий пример. Вот более понятный вариант.
И так, Вы построили матрицу из трех векторов, каждый из которых несет свойства одного объекта кнопки.
Потом, Вы можете использовать эту матрицу как прототип. Шаблон, по которому будут создаваться любые другие кнопки. Все что Вам нужно, менять в конечном варианте какие то значения объектов и будет получаться новая кнопка.
В принципе, В ООП можно делать тоже самое. Но, в качестве шаблона используется класс. У меня в качестве шаблона используется массив.
Вот и вся разница.
Как я говорил, в моем подходе удобство не главное. Главное - эффективность и потенциал развития и применения.
Где код, чтобы можно было эти "портянки" ( #9 ) проверить?