Ответ: Блиц против ООП ;-)))
 

еще раз повторю:
1. Forth летает даже на микроконтроллерах и однокристалках:ok:
2. LISP есть даже для консолей PS2. На консолях, как понимаешь, не летать нельзя, паблишер не пустит:wallbash:

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

Ответ: Блиц против ООП ;-)))
 

Можно бесконечно наблюдать за несколькими вещами:
1)как горит огонь
2)как течёт вода
3)как люди спорят на тему "что лучше: лопата или грабли? (калькулятор или экскаватор)"

Ответ: Блиц против ООП ;-)))
 

как работает пожарная команда ты хотел сказать.

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

Ответ: Блиц против ООП ;-)))
 

ffinder
пример который привели на КРИ может говорить только о том что автор примера явно против ООП, потому что :
1) автор пытается совместить модель графической системы и модель игрового мира в одной архитектуре
2) автор пытается совместить пункт 1 с data driven engine
3) автор не учитывает существование такой професии как архитектор на котором висит создание всей ООП (и не ооп тоже) архитектуры проекта
4) дальше появляется какие-то статьи про обработчики ? callback'и ? так они еще большее зло чем любое ООП плюс сатана плюс обработчик ошибок, что обьясняется только догадками автора "ага етим заплатили 10 тыс $, а вторым только 5 тыс $, но вторые сделали калькулятор лутче, ага ага реализовывали на обработчиках в делфи"
5) все доверие подрывает постоянная путаница что такое игровое применение ООП, применение ООП в графическом движке и применение ООП при общем программировании
6) после всего этого автор обвиняет ООП в СВОИХ проблемах

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

процедурный подход нужен там где работают только с одной абстракцией (базы данных к примеру)
ООП подход нужен где нужна гибкость создания новых обьектов

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

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

Ответ: Блиц против ООП ;-)))
 

jimon
спасибо, что написал развернутый ответ.
"Hо в песне ты не понял, увы, ничего."

Ответ: Блиц против ООП ;-)))
 

ffinder
в своём посте я написал своё имхо что идинственое что полезное в ООП это наследие классов и методы классов
там где не нужна абстракция - там не нужно и ООП (так же написано в моём посте)
так же я написал что автор доклада просто обвиняет ООП в том что оно неподходит для процедурного написания его идей, следовательно автор просто не видел нормальных реализаций игровой архитектуры

скажи пожалуйста чего я не понял ? глубокой дзенской мысли автора доклада что все ооп'шники - пид*ры ? это тоже самое что кричать все делфисты - пид*ры, собсно кем бы программисты на делфи не являлись, крик не является доказательством или аргументом (тут просто выражается мнение заядлых сишников о делфистах, это не моё мнение и я к нему не имею никакого отношения :) я к делфи отношусь неинтрально )

доказательство - спланированый проект, обьем кода которого не меньше 400-1000 кб, написанный в ооп и процедурной версии
кармак идеально писал движки как в процедурной форме, так и в обьектно-ориентированой и не ругался (id tech 3, id tech 4)

ps. делись своей песней ? если она заключается "в b3d нет ооп и оно нам нафиг не надо %POCHEMU_NENADO_OOP%, и вообще ооп это плохо"
то у тебя нету никаких везких аргументов

я уже привел пример с коровой, змеей, собакой и кошкой
опиши как ты будешь реализовывать такую схему ?

Ответ: Блиц против ООП ;-)))
 

jimon
меня опять не понимают...
опровержения:
1. я далек от мысли "ООП в топку" (в названии темы смайлик, если не заметил)
2. я не одобряю подходов ООП против ФП, т.к. и существительные (объекты) и глаголы (функции) необходимы в языке. Java ярчайший пример перекоса в ООП.
с чем я согласен:
1. маловероятно, что оратор за 12 лет стажа не видел нормальной ООП архитектуры
2. ключевая мысль выступления: "объект - точка в пространстве функций"
3. что проектировать надо исходя из use case'ов. а не из "объектов".
4. что "конвеер" в "типичной" (среднеарифметической по палате) ООП архитектуре размазан по вызовам методов объектов в неочевидном порядке.
5. что надо разделять функциональность, а не лепить её в одну кучу (это про паттерн chain of responsibility)

ЗЫ: ты не привел use case про зверей, следовательно непонятно какая функциональность от них нужна.

Ответ: Блиц против ООП ;-)))
 

ffinder
твой оратор привел самый худший пример что может быть на свете
вот потратил минут 15 и нарисовал примерную архитектуру такой игры в моём понимании
теперь сравнивай мою архитектуру, с архитектурой оратора с 12 летнем стажем (я умею программировать порядка 7 лет, стаж работы где-то 6 месяцев :lol: )

справко : Iblabla это интерфейс класса, Cblabla это его реализация
это такой патерн при программировании движков и прочего
мы пишем интерфейс, программы юзают только интерфейс
а реализацию в движке можно менять сколько угодно, хоть другой
двиг прикрутить к уже готовому интерфейсу

Обьясню моей подход :
1) IMesh может содержать как анимированый так и статичный меш
2) IEntity просто содержит меш, положение и другое
тоесть любой 3д обьект представляется как IEntity
3) уровень ILevel содержит только список ссылок на ILevelObject
ему не важно какие конкретно это обьекты
Жемчужина наследуется от ILevelObject и содержит одну ссылку на IEntity
это позволяет делать LevelObject обьектом любой сложности любого типа
4) есть обобщение IAnimal, рыба и рак наследуются от них
в классах рыбы и рака реализуется ИИ, физика и прочее
5) класс IPlayer содержит в себе IAnimal, тоесть игрок может управлять любым животным игры

выделим плюсы архитектуры :
1) можно добавлять любого вида животных
2) можно добавлять любого вида игровых обьектов
3) игрок может управлять любым видом животного
4) 3д модель и её тонкости скрыты за классом IEntity

посмотрим на критерии оратора :
1) "Крутящаяся Жемчужина - это " - это та жа "Жемчужина" в моей архитектуре
просто при загрузке модели указали анимированый файл
делов-то - ПОМЕНЯЛИ ТОЛЬКО НАЗВАНИЯ ФАЙЛА МОДЕЛИ ПРИ ЗАГРУЗКЕ

2) "Главная Рыба - это " - это "Рыба", игрок вообще может управлять любым животным так что не важно что это

3) "Построение непротиворечивой иерархии объектным способом невозможно"
какого чёрта, я её ТОЛЬКО ЧТО ПОСТРОИЛ !!! щас весь мир взорвётся ? :lol: :lol: :lol:

ps. можно вообще-то для IAnimal выделить IAI, но это уже так, мелочи

Ответ: Блиц против ООП ;-)))
 

jimon OpenOffice Draw?
А по теме. Вы еще подеритесь ;) Кто как хочет, тот так и программит.

Ответ: Блиц против ООП ;-)))
 

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

Ps. Кстати если о теме топика - никто не мешает реализовать ооп на блице :)

Ответ: Блиц против ООП ;-)))
 

dimanche13
это удобный редактор простенькой векторной графики, схожий по возможностям с Microsoft Visio :)
http://ru.wikipedia.org/wiki/OpenOffice.org_Draw

Ответ: Блиц против ООП ;-)))
 

не взорвется, потому что твоя схема на работает.
у тебя IAnimal не является ILevelObject.
во первых это нелогично, а во вторых кто где хранится?
IPlayer тоже непонятно чем занимается.
короче больше конкретики нужно.

Ответ: Блиц против ООП ;-)))
 

ffinder
IAnimal может наследоватся от ILevelObject, просто я посчитал это не нужным, в принципе согласен с этим :)
и тогда действительно все обьекты хранятся в классе уровня

IPlayer занимается управлением IAnimal, снятием показаний для гуи, управление переключением оружия и тд и тп
так же IPlayer занимается переносом игрока на новый уровень

Ответ: Блиц против ООП ;-)))
 

повторюсь: ООП не может быть против ФП и ПП, как существительные не могут быть против глаголов, это все части одной речи.
ОК, давайте прикидывать как сделать юниты для стратегии, HolyDel, давал картинку. Посмотрим на разные варианты.
хе-хе, сам Блиц и мешает. В нем нет указателей на функции - следовательно, функции не могут быть полями типов (в терминах Блица3Д).
А жалкое подобие ООП сделать можно. Я года 2 назад нашел даже туториал по этому делу.

Ответ: Блиц против ООП ;-)))
 

Можно тупо сопоставить по программерски:
>> ООП:
+ Классы позволяют проводить конструирование из полезных компонентов, обладающих простыми инструментами, что дает возможность абстрагироваться от деталей реализации.
+Данные и операции вместе образуют определенную сущность
+Локализация кода и данных улучшает наглядность и удобство сопровождения программного обеспечения.
+Защита данных типа от несанкционированного доступа.
+Каркасность программы
-Плохая читаемость
-Сложен дебаг
-Сложность в освоении для новичков
Итог: 4-2=2 2балла
Без ООП:
+хорошая читаемость
+чёткий контроль за исполнением программы(лёгкий дебаг)
+лёгкость освоения
-не универсальность кода(именно типов)
-малая типизация обьектов внутри программы

Итог: 3-2=1 1балл

Прошу не сильно меня ругать, основывался на личном опыте, плюсы и минусы возможно додумал не полностью.

НЕДОСТАТКИ ООП :
Необходимо понимать базовые концепции, такие как классы, наследование и динамическое связывание. Для программистов, уже знакомых с понятием модуля и с абстрактными типами данных, это потребует минимальных усилий. Для тех же, кто никогда не использовал инкапсуляцию данных, это может означать изменения мировоззрения и может отнять на изучение значительное количество времени.
Многоразовое использование требует от программиста познакомиться с большими библиотеками классов. А это может оказаться сложнее, чем даже изучение нового языка программирования. Библиотека классов фактически представляет собой виртуальный язык, который может включать в себя сотни типов и тысячи операций.
Проектирование классов — задача куда более сложная, чем их использование. Проектирование класса, как и проектирование языка, требует большого опыта. Это итеративный процесс, где приходится учиться на своих же ошибках.
Очень трудно изучать классы, не имея возможности их «пощупать». Только с приобретением мало-мальского опыта можно уверенно себя почувствовать при работе с использованием ООП.


Лично я даже не знаю что лучше но ООП это чертовски удобно, скужу так: Оно ближе всех пододвигает программиста к реализации идеального движка, заточеного под всё.

Вобще если уж говорить об освоении то начинал я с ZXSpectrum на нём ни ООП тебе ни имагов никаких вобщем бери plot line circle и ещё шрифт букв можно коверкать для изображения героя игры.
Потом я перешол на Delphi, а Delphi - это царство ООП и там я ООП и научился даже глупости своей не ведая написал мини 2д движок для игр(был он на GDI ужас).Потом увидел блиц и понял что вот он ремейк спектрумского языка. Попрогал и заностальгировал по ООП ибо удобно както и схватил BlitzMAX.

Что лучше даж не знаю.
Но Microsoft и прочие товарищи двумя руками за ооп. Но я им не доверяю. Вот на php ооп уж точно не нужно. Нафиг оно там я пока не понял. Также WEB 2.0 подрузомевает ООП и в скриптах сервера и даже в Javascript. Но это вобще, когда я узнал что в JavaScript есть ООП мне хотелось задать разработчикам вопрос: Нафига? Наверно за тем же зачем и в папке Windows XP у большенства людей лежит clock.avi.