Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
В движке все это кстати есть. Все вводы выводы(доги,... 28.08.04 12:42 Число просмотров: 2923
Автор: DgtlScrm Статус: Member
|
> > Как нет? Минимум - это то что все системы унаследованы
> от
> > абстрактного класса системы, которы й реализует все
> > необходимые базовые функции любой системы. А
> инкапсуляция и
> Ну а если нет "базовых функций любой системы". Какой
> интерфейс ты бы предоставил для базового класса например
> WinNT-шных подсистем: ввода/вывода, справочного монитора
> безопасности, менеджера объектов, менеджера конфигурации
> (проще говоря реестра) и прочего. Эти подсистемы очень
> хорошо друг от друга отделены, но используя чисто
> процедурные приемы. А кода немало: одного ядра - почти 40
> метров (такое за месяц не напишешь).
В движке все это кстати есть. Все вводы выводы(доги, консоль, файл, память, клавиатура, контроллеры и сеть) имеют файлоподобный интерфейс. Тоесть открыть читать, писать... и т.д.
Все коллекции порождены от менеджера коллекций, это менежер объектов, ресурсов, событий, графичесских ресурсов и граф. объектов. Каждый менеджер очень прост потому как изменяются только функции подгрузки выгрузки и контроля за коллекцией.
А все настройки читаются из файла (а это может быть и сеть и память, покрайней мере чаще всего это файл :) )( XML, LUA и возвращаются уже в виде дерева.
Чем больше думаешь над взаимосвязями тем больше их замечаешь... Хуже всего, когда весь движок уже в виде UML-ки и ты думаешь... а можно было сделать по другому, но влом очередной раз переписывать :) Ведь срока как всегда горят %)
> > полиморфизм присутствуют в интерфейсе для движка и
> > внекоторых системах(там где есть необходимость).
> Ну и в чем выражается полиморфизм?
Это Что?Где Когда? :)
Дело в том, что движок написан так чтобы на LUA у меня небыло никаких неудобств. Поэтому много методов(в основном обработки данных) имеют перегруженые интерфейсы, чтобы мне не приходилось производить конвертирование из скриптов. И вто же время gInterface должен на лету создать сотни графичесских объектов, анимаций; система ввода со старта загружает все доступные ей " источники информации о человечесских действиях". С сервера подгружаются административные скрипты, с архивов читаются конфиги, делается mmap крохотного раздела и мы уже подключены к системе внутреннего хранилища пользовательских данных. И когда я писал систему чтения конфигурационных файлов, я даже не знал откуда будут грузится данные, с начала это было "file#main.lua", а потом пошло поехало... "zip#data.zip", "net#127.0.0.0.1/port/configname"... Я предполагаю ты догадываешся, что все создается на лету... ладно, что они создаются по имени... Если, такого объекта нет, то создается фиктывный экзепляр объекта который ничего не делает... Ну а подключаясь к файловой подсистеме, тебе возвращается указатель на базовый клас файла, хотя на самом деле это полиморфные классы порожденные от него.
Вобщем берем к примеру объект gCard - это игровая карта(пиковый король, дама трефь, етц...) Но вот незадача, у меня есть колода которая нарисована с лева... карты лежат стопкой. Когда тебе сдают карты они появляются у тебя на игровом поле, а при дупляжке они маленькие... Так вот, все это дело сделано так, что есть понятия gCard это просто карта она умеет вращатся, прятаться вообщем это даже не ее методы... все они унаследованы от gObject. Некоторые из них перегружены но это не факт важно. Зато есть понятия gCard, gCardFromPack, gCardFromMainScene, gCardFromBonus. И их единственная разница - это Draw и Rotate. При прорисовке, они фигурируют как gObject, помоему это и есть полиморфность...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
