Мой подход. Ядро - Движок. - страница 2

 

не смог пройти мимо... а какое разрешение монитора нужно, чтобы такие горизонтальные "портянки" кода видеть??

 как то неудобно смотреть в редактор и гонять туда сюда полосы прокрутки, чтобы редактировать или посмотреть код ))))

 

И так.

Первое преимущество моего подхода - это Сжатость. Меньше слов - больше цифр. Объект - вектор. Элемент - комплекс векторов внутри матрицы. Комплекс Элементов - Окно. Комплекс окон - Ядро.

Суть в том, что Объект не обязательно должен быть графическим. Элемент можно сделать Понятием, и наделить его не меньшим количеством Объектов и свойств. А движок будет логической машиной работающей с этими понятиями(Элементами).

 
Vasiliy Sokolov:

ООП очень гибкая методология, поэтому в нем нет каких-либо априорных идей вроде понятия "ядра". Однако с помощью ООП очень хорошо можно построить модель ядра, о которой здесь ведется речь. Поэтому утверждение не совсем корректное.

Да, я сам поглядел, и удивился - Петер описывает как есть ООП-штуку.

Но, как я понял, Петер как достоинство выносит возможность пользователя иметь полный доступ ко всем свойствам и методам Ядра. А ООП-стиль - это как раз инкапсуляция, когда права доступа всемерно ограничиваются.

Помню, в молодости я тоже жутко возмущался, что в защищенном режиме мне не доступна вся память компьютера. Как это так, какие-то, понимаешь, программы будут запускаться, а я не могу получить доступ к их памяти... Специально строил "обходные маневры" с помощью программирования контроллера прямого доступа к памяти, даже получал содержимое памяти другого процесса, недоступного мне из программы (правда, для этого надо использовать команды доступа к портам контроллера ПДП, а это само по себе непросто в многозадачной среде Виндовс, я использовал специальный драйвер).

И лишь потом понял, что защищенный режим, разделение доступа (да и вобще инкапсуляция) - это очень важная штука, необходимая мне же. Чтобы я не влезал случайно туда, куда лезть нельзя. И поэтому сейчас я твердо стою на позиции "в любом месте программы процессу должны быть доступны исключительно лишь те ресурсы, свойства и методы, которые ему нужны конкретно сейчас".

Но, Петер, как я понимаю, не сторонник инкапсуляции.

 
Igor Makanu:

не смог пройти мимо... а какое разрешение монитора нужно, чтобы такие горизонтальные "портянки" кода видеть??

 как то неудобно смотреть в редактор и гонять туда сюда полосы прокрутки, чтобы редактировать или посмотреть код ))))

Как я говорил, в моем подходе удобство не главное. Главное - эффективность и потенциал развития и применения.

 
Реter Konow:

Как я говорил, в моем подходе удобство не главное. Главное - эффективность и потенциал развития и применения.

ОК, подожду еще примеров кода, но пока очень не читаемый код вижу, может быть что прояснится позже

 
Vasiliy Sokolov:

ООП очень гибкая методология, поэтому в нем нет каких-либо априорных идей вроде понятия "ядра". Однако с помощью ООП очень хорошо можно построить модель ядра, о которой здесь ведется речь. Поэтому утверждение не совсем корректное.

Условное ядро можно построить. Думаю, серьезные программы это и делают. Но, у меня все построено на "физическом" ядре. 

 
Igor Makanu:

ОК, подожду еще примеров кода, но пока очень не читаемый код вижу, может быть что прояснится позже

Смотрите. Показанное лишь общий пример. Вот более понятный вариант.

  1. Вы хотите нарисовать Кнопку. 
  2. Вы создаете массив и записываете в него значения свойств кнопки которую хотите создать.
  3. Кнопка состоит из трех объектов: Основание, Текст, Картинка.
  4. Каждый объект существует внутри Элемента кнопки, следовательно, массив должен быть двумерным.
  5. Каждый ряд массива будет у Вас представлять один объект Элемента "Кнопка".
  6. Три объекта будут предствалять всю кнопку.

И так, Вы  построили матрицу из трех векторов, каждый из которых несет свойства одного объекта кнопки.

Потом, Вы можете использовать эту матрицу как прототип. Шаблон, по которому будут создаваться любые другие кнопки. Все что Вам нужно, менять в конечном варианте какие то значения объектов и будет получаться новая кнопка.

В принципе, В ООП можно делать тоже самое. Но, в качестве шаблона используется класс.    У меня в качестве шаблона используется массив.

Вот и вся разница.

 
Реter Konow:

Как я говорил, в моем подходе удобство не главное. Главное - эффективность и потенциал развития и применения.

Потенциал развития зависит также от удобства.
 
Где код, чтобы можно было эти "портянки" (   ) проверить?
 
Vladimir Karputov:
Где код, чтобы можно было эти "портянки" (   ) проверить?
Да ладно код, хотя бы ex4-файл. Так понимаю, речь пока о МТ4.