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

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

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

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

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

зависит от прямоты рук
зависит от прямоты рук
точно такую же (+ более глубокий анализ) чёткость обеспечивает дебаггер 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]

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