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

Вчера скачал доклад с КРИ2008. Подтверждение моих (и не только) мыслей про некоторый вред от ООП наследования (в докладе есть) и применительно к программированию на Блиц3Д (в докладе этого нет)

http://www.kriconf.ru/2008/rec/KRI_2..._Evosquare.ogg

http://www.kriconf.ru/2008/rec/ppt/K..._Evosquare.ppt

2 HolyDel: это в основном ответ тебе. хотя другим тоже не помешает.

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

сколько весит?

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

9.54Mb ogg
1.45Mb ppt

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

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

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

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

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

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

ваще дело привычки.
кто то на ооп думает, а я жлоб и ретроград - у меня моск под бейсик заточен :))

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

аппаратная поддержка Бейсика в синапсах? зобавно:)

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

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

особых различий в разработке нету, некоторые вещи проще реализовуются на ООП, некоторые процедурными методами

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

Как программист я оформился на спектруме.
А там басик и асм.
И никакими ООП-ами и не пахло :-D

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

ога... и сравни теперь скорость написания программок одного уровня на спектруме и блице скажем. блиц следующий уровень - процедурное программирование. ООП - следующий уровень.

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

камрад:super:
я вот жалею что в то время не понял могучести Форта. мануалы лохобанские попадались. всё-таки масштабируемый (!) чистый функциональный(!!) низкоуровневый(!!!) язык в то время на дороге не валялся... а сейчас уже поздно. мир изувечен сиплюсами:crazy:

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

ога, а мета-языки (Lisp, Forth) - еще следующий.

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

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

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

что-то ты походу пропустил, такое железо уже лет 25 как есть (2008-1983):-D

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

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

выделил

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

еще раз повторю:
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.

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

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

Быть против ООП это как быть против эволюции и развития.

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

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

зависит от прямоты рук
зависит от прямоты рук
точно такую же (+ более глубокий анализ) чёткость обеспечивает дебаггер IDE MSVC (даже аналогичные кнупочки есть), а как вам возможность узнать файл и строку в нём места креша для скомпиленного ехе? На деле же - "лёгкий" превращается в "примитивный".
не уверен, что это "однозначный минус".

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

дадададада.... ну надо же, раскопали мою старую тему:-D

модульность и ООП - разные понятия. общее у них - только интерфейсы.
(пример: в TurboPascal 6.0 были модули, но не было объектов.)
code reuse тоже никак не зависит от ООП.
(пример: DLL имеют процедурные инфтерфейсы).

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

если классы спроектированы идиотами - то утверждение меняем на обратное.
прим.: "идиоты" - программисты которые пишут код не соответствующий предметной области.

лучший движок заточенный под все - это пустой файл.
в реальном мире есть только частные задачи (с)IronPeter (не слово в слово, но смысл именно этот).
Майкрософт - это КУЧА проектных команд, часто мало контактирующих между собой. У Майкрософта есть F#, так что не надо.

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

Был у меня забавный случай изучения сорца некого товарища, котрый настолько любил ООП что чули TType там небыло))) Ну уж настолько всё было ужасно. Дерево обьектов имело ветки длиной около 40 вложений(зы ответвлений). Сорец был на C Sharp. Эх был бы он у меня... Вместе бы посмеялись. ООП это сила но переусертствовать не надо.
А вобще кто сказал что на блице3д нельза делать ооп.
Скажем добавить в каждый тип параметр Parent в котором хэндл на тип владелец. Или жосткую типизацию без хэндла, это менее гибко.
В довешеннее вышесказаному скажу что я всёже за ООП но не за переусердствование. Классов и наследников не должно быть слижком много. Вобще при должном подходе можно обойтись и вобще без типов но это тоже самое что и молотком делать тунель в скале нежели взять динамит.
Был на памяти один знакомый, который вместо:

Type TBot
field HP
field MaxHP
field x,y,z
field bottype, ent
EndType

Писал:

Dim BotHP(9999)
Dim BotMaxHP(9999)
Dim BotX(9999)
Dim BotY(9999)
Dim BotZ(9999)
Dim BotType(9999)
Dim BotEnt(9999)
BotCount=0

Но так нельзя.
Я его спросил:
Я: Что будет если убивают одного из ботов?
Он: BotCount-1
Я: А если убьют допустим третьего а всего их 10?
Он: Ну у меня проверка по BotEnt(i) есть если он пуст то цикл идёт дальше

Ерунда налицо. Игру он делал типа Сrimsonland и получается что после убийства 500 ботов игра будет сильнейшим образом тормозить. При попытке пустить его в нужное русло и обратить взгляд его на типы он очень сильно ругался и говорил что типы это бездарно. В общем каждый прогает как умеет и грабли у всех свои.

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

у меня в варче боты - тоже массивом.
если юнита убивают - то он замещается последним из списка и кол-во юнитов уменьшается на 1.
работает очень быстро.

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

ну ты не сказал про сложность задачи - в некоторых случаях и не такое оправдано.
все сказали, в том числе и я. можно делать _подобие_ ООП. т.е. самостоятельно выполнять работу компилятора.
ты похоже путаешь древовидные структуры и ООП. это совсем никаким боком не связанные вещи.
ООП (классовое, есть еще прототипное) это:
1. инкапсуляция
- к внутренним переменным и методам нельзя обратится извне (иначе компилятор не пущает) - в Блице3д только следить самому
- объединение кода и данных в одном месте - этого тоже напрочь нет, а вместо есть аналог сишного struct. и все бы ничего можно было бы в структуру напихать указателей на функции класса - но вот указателей на функции тоже не выдали.
2. наследование - без комментариев, его не может быть как описано выше.
3. полиморфизм - нету, так как нету наследования
[/quote]

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