Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » ООП, Python, Ruby, Lua, Obj-C, Smalltalk, D » Корневые классы


Корневые классы

Сообщений 1 страница 10 из 10

1

Какая основная цель создания корневого класса для всех остальных классов в приложении? К примеру как класс Object в книге "Графика трехмерной компьютерной игры на основе OpenGL". Какие это дает приемущества?

0

2

X-ti написал(а):

Какие это дает приемущества?

Никаких. И идеологически это неверно.

X-ti написал(а):

Какая основная цель создания корневого класса для всех остальных классов в приложении?

\
Сие есть неведомо

0

3

Мне нравится когда есть нормальная объектная модель.
Когда для сериализации обектов не нужно использовать кучу гавна типа boost
Я разделяю классы на абстрактные типы данных (например Vector3D) - там не нужно никаких виртуальных методов и т.п., важна скорость и компактность, и собственно объеткы.
И если посмотреть на практически любой ОО-язык (кроме С++), то там все объекты имеют общий класс (Java, C#, Python, Obj-C и т.п.)
Это позволяет использовать универсальные контейнеры, преобразователи и т.п.
Это дает возможность ввести нормальный механизм RTTI, а не то убожество, что есть в С++
Понятно, что в качесвте объектов не должны выступать сущности, методы которых огромное количество раз будут вызываться каждый кадр - тут DOD рулит
А, например, для GUI это очень удобно и затраты не заметны.
Упоминаемая книга просто очень стара и там дейсвтительно есть сильный перебор в стороны красоты дизайна по отношению к быстродействию, например оформлять каждый полигон как полноценный объект - это плохо

IMHO плохо что С++ не различает понятия объекта и абстраткного типа (и вообще давно ушел в сторону шаблонов)
Но это лишь мое личное мнение.

0

4

Steps3D написал(а):

Это позволяет использовать универсальные контейнеры, преобразователи и т.п.

В 99% случаев это указывает на плохую архитектуру системы. Это примерно как в одном вагоне перевозить волков и ягнят. При том, что если верить биологии, у них есть общий базовый тип. А вот найти связь между рендером и звуком мне совсем тяжело.

Steps3D написал(а):

Это дает возможность ввести нормальный механизм RTTI, а не то убожество, что есть в С++

Даже в том же obj-c для этого совершенно не нужна общая база. Рантайм языка спокойно справится и без нее. И хоть убейте меня, я не понимаю почему NSNumber должен быть рефкаунтнутым. В obj-c, кстати, основная цель общей базы - и есть рефкаунты. Причем они в большинстве случаев смотрятся как очень неудачный костыль для управления памятью в условиях С99. Особенно в связке с autorelease пулами.

Steps3D написал(а):

А, например, для GUI это очень удобно и затраты не заметны.

Да, у элементов GUI есть общая база. Назовем ее widget. Или UIView. Как угодно. GUI по природе своей иерархичны, поэтому очень удобно иметь общую базу. Однако вся механика "RTTI" там легко управляется ровно одной константой которую можно заставить генерировать компилятор. И уж точно GUI не должны иметь ничего общего, например, с сетью. И даже с каким-нибудь View контроллером.

Steps3D написал(а):

С++ не различает понятия объекта и абстраткного типа

А вон Гамма с компанией умудрились сделать терминологию так, что она с минимальными оговорками вписывается как в идеологию С++, так и в Smalltalk (примеры у них и на С++, и на Smaltalk). Они, кстати, считают, что структура приложения и связи в нем должны задаваться на этапе проектирования и фиксироваться при компиляции, а не меняться неожиданно в рантайме. Переиспользование кода != 100500 не нужных рантайм фишек, лучше всего у которых получается разрушать инкапсуляцию.

0

5

В 99% случаев это указывает на плохую архитектуру системы. Это примерно как в одном вагоне перевозить волков и ягнят. При том, что если верить биологии, у них есть общий базовый тип. А вот найти связь между рендером и звуком мне совсем тяжело.

Я так не считаю, по мне кривой дизайн - это когда для каждого класса мы создаем свой контейнер во имя бредовой строгой типизации
И при чем тут связть между перевозкой волков и ягнят я не вижу. Зато это очень удобно в ряде случаев - уже не в первый раз сталиваюсь с ситуацией, когда мне ифнормация об объекте представлена набором совершенно разнородных значений и именно в С++ приходится думать как все это всести вместе (без говнокодла вроде boost::any). А в нормальной объектной модели такого вопроса даже не стоит - все легко складывается в один словарь
Собственно Вы пропустили часть, про то что практически во всех ОО-языках (кроме С++, который IMHO ОО с большой нтяжкой) используется именно такя иерархия - т.е. все программы на этих языках имеют плохую архитектуру ?
Народ вот пишет на Java/C# и как-то на это не жалуется.

Возможность удобной и универсальной сериализации IMHO очень удобна и в условиях С++ ее дает именно объектная модель.
По поводу obj-c - так отнюдь не только refCount засунут в базовый класс - посмотримте описание класса и протокола NSObject - там очень много чего есть.

А насчет Гамма & Co - примеры у них очень простые и даже на них видно, что варианты на Smalltalk'е гораздо красивее и проще. Ну надо было в книжку прикрутить примеры на С++

Они, кстати, считают, что структура приложения и связи в нем должны задаваться на этапе проектирования и фиксироваться при компиляции, а не меняться неожиданно в рантайме

Это где у них написано - у них как-раз почти все паттерны работают именно во времня рантайма, и связи и поведение меняется во время рантайма - не надо путать их с тем, что сделал Александресу - он перенес кучу паттернов именно на этап компиляции

0

6

Steps3D написал(а):

По поводу obj-c - так отнюдь не только refCount засунут в базовый класс - посмотримте описание класса и протокола NSObject - там очень много чего есть.

Ага, куча оберток над рантаймом. Которые, о чудо, дергают рантайм. Причем в ряде случаев самих себя же. (- (id)performSelector:(SEL)aSelector кагбе намекает, что что-то здесь не то...) Хотя это идеология языка походу. Делать обертки над обертками оберток. Зато псевдо смаллток получилсо. С псевдо, но тем не менее строгой типизацией. Которой в Smalltalk не было. Из-за чего не было необходимости в куче костылей.

Steps3D написал(а):

И при чем тут связть между перевозкой волков и ягнят я не вижу.

А что в одном контейнере забыли совершенно разные объекты из совершенно разных посистем. Они вообще друг о друге знать ничего не должны. А тут опа, в одном контейнере. И что Вы с ними будете делать? Напишите здоровенный свитч который по типу будет выбирать действия, которые совершить? А не логичней ли их по разным контейнерам разложить?

Steps3D написал(а):

Собственно Вы пропустили часть, про то что практически во всех ОО-языках

Во всех строготипизированных ОО языках. Это необходимый костыль, для того что бы компилятор/виртуальная машина потом с ума не сошли, пытаясь разобраться как и что получилось. И еще раз, ни в Smalltalk, ни даже в Obj-C в этом нет необходимости. Рантайм языка спрвится и без наличия ненужных селекторов у каждого объекта.

Steps3D написал(а):

Народ вот пишет на Java/C# и как-то на это не жалуется.

Я рад за народ. У них все так хорошо и просто, что ошибки в коде, написанном за несколько часов ошибки потом фиксятся пару месяцев. Я понимаю, что это малосвязанные вещи, но тенденция такая есть. И что-то мне подсказывает, что это связанно именно с тем, что народ не парится.

Steps3D написал(а):

и связи и поведение меняется во время рантайма

Ну не скажите. Они требуют строго типизации (интерфейса) при композировании и делегировании. Да и в других паттернах тоже. И эта связь разрабатывается на этапе проектирования и становится статичной на этапе компиляции. Да, в теории мы можен в рантайме заменить объекта получателя при делигировании, но мы ждем от него, что он будет предоставлять и реализовать требуемый интерфейс целиком. И сюда никак не вписывается необходимость в общей базе. Зато сюда без особых проблем вписывается С++. Да и на практике такая ситуация встречается крайне редко.

Отредактировано crsib (2011-02-18 16:39:01)

0

7

http://petecubano.wordpress.com/2010/12 … e-numbers/

Вот тут есть некоторая интересная информация к размышлению) честно говоря удивило, что DOD-подход дал почти двухкратный выигрыш в скорости...

0

8

X-ti написал(а):

что DOD-подход дал почти двухкратный выигрыш в скорости...

Как уже говорили на gd.ru и как непосредственно гориться в первом кометарии - данный пример - сферический конь в вакууме. На практике он не даст и 10% прироста. Однако он дает правильное направление для размышления о том, что такое кэш и о том, почему память такая медленная.

+1

9

1. Нет в obj-c строгой типизации, по крайне мере в отношении объектов. И это вполне нормальный смолток
Кстати на performSelector куча всего сделано и как-то с его налогом в С++ фигово :((

2.

А что в одном контейнере забыли совершенно разные объекты из совершенно разных посистем.

Я разьве об этом писал ?
Я писал о том, что я могу не заводить разных типов контейнеров, отличающихся исключительно типов хранимых данных.
Понятно что в один  контейнер складываются отнюдь не рандомные данные, Но наличие отдного универсльного хэшмэпа IMHO удобнее кучу кривых std::map'ов

3.

Во всех строготипизированных ОО языках. Это необходимый костыль, для того что бы компилятор/виртуальная машина потом с ума не сошли, пытаясь разобраться как и что получилось. И еще раз, ни в Smalltalk, ни даже в Obj-C в этом нет необходимости. Рантайм языка спрвится и без наличия ненужных селекторов у каждого объекта.

А что питон и руби уже стали строготипизированными языками. Или смолток строготипизирпованный язык ?

Они требуют строго типизации (интерфейса) при композировании и делегировании. Да и в других паттернах тоже.

Они требуют это в С++. А другим языкам это фиолетово. Понятие duck typing работает в куче языков и вполне хорошо.
Ну а про ошибки - нормальные тесты еще никто отменял и никакая типизация их не заменит. А вот тесты вполне могут заменить хорошую часть типизации.

Ну и опять про интерфейсы - если бы онип в С++ были хотя бы сделаны (как во многих ОО-языках со строгой типизаций). А то вместо них имеется непонятно что - класс выдаем за интерфейс и получаем всякие гадости вроде multiple inheritance. Где еще, кроме С++ возникает такоя проблема ?
AFAIK это исключительная фича С++

Возможно в C++ и не всегда удачно вписывается корневой класс, IMHO из-за отсутствия объектной модели как таковой и кучи странных решений (ну не бред ли указатели на методы в том виде, в котором они сделаны в С++ и как ими без шаблонов можно пользоваться ?)
Мне нравится вариант, когда объекты имеют корневой общий класс, куда выносится много полезного функционала. Вам - похоже что нет.

0

10

Steps3D написал(а):

А что питон и руби уже стали строготипизированными языками. Или смолток строготипизирпованный язык ?

А можно поименно названия root-классов для этих языков? То, что рантайм языка предоставляется всем объектам языка возможность "отзываться" на определенный список методов/сообщений/{как их там еще не звали} вовсе не требует одного суперкласса. Рантайму, строго говоря, вообще пофиг на это. Не пофиг компилятору языка, если он строго типизированный.

Steps3D написал(а):

Где еще, кроме С++ возникает такоя проблема ?

В Python есть multiply inheritance, если вы об этом. В остальном, глобальная раница между pure virtual классом и интерфейсом из Джавы находится в ключевом слове. Если так уж хочется слова interface то сделайте себе дефайн)

Steps3D написал(а):

Понятие duck typing работает в куче языков и вполне хорошо.

Оно работает хорошо, пока соблюдается Liskov Substitution Principle. Если про него забыть, то по закону Мерфи вся потеха начнется тысяч через 10 строк кода, кода уже будет поздновато все менять, ибо вообще говоря релиз был вчера и количества ***** в коде превышает 50%, потому что на типизацию мы забыли и надеемся что все будет ок. К сожалению не бывает... А если не дай бог еще придется переиспользовать код потом...

Steps3D написал(а):

куда выносится много полезного функционала

Что у NSObject'a полезного, чего нельзя сделать в 3-7 раз быстрее без него, непосредсвенно используя obj-c runtime?

Steps3D написал(а):

Кстати на performSelector

Примерчики пожалуйста. Кроме NSNotificationCentre. Потому что на нем сразу вспомним, что такое "компилятор" obj-c, подумаем, чем он отличается от moc и вспомним, что в Qt это сделано лучше (ну ладно, не хуже), на gtk+ примерно также, а boost.signals2 вообще header only. Хотя даже notification centre плохой пример. Я не думаю, что он использует performSelector внутри себя. Это дороговато. Есть еще всякие performSelectorInBackground, но они тоже примеры не очень. Потому что во первых нифига не гибко. А во вторых опять же, тема использования performSelector не раскрыта... Вы поймите, я не против такой методики "посылки сообщений". Я не понимаю того, какое отнощение она имеет к NSObject. И я не понимаю, как минимальная аккуратность и хотя бы соблюдение LSP (не говоря уже о строгой типазации) могут существенно усложнить код.

0


Вы здесь » Компьютерная графика » ООП, Python, Ruby, Lua, Obj-C, Smalltalk, D » Корневые классы


создать свой форум бесплатно