Войти
ФлеймФорумПрограммирование

3D диаграмма классов (2 стр)

Страницы: 1 2 3 Следующая »
#15
15:57, 18 авг. 2019

Fedor1995
> Диаграммы классов нужно тем, кто пишет на языках, не осиливших интерфейсы
Ну, все ООП - это просто детская болезнь. Если Вы ясно представляете себе решение задачи, то оно будет только мешать. А если не понимаете, понять не поможет (зато здорово поможет сделать вид, будто понимаете). Детсад, эти ваши крестопроблемы, чистый дедсад.


#16
16:34, 18 авг. 2019

gudleifr
Ты ООП код не пишешь?

#17
(Правка: 16:39) 16:39, 18 авг. 2019

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

#18
16:41, 18 авг. 2019

gudleifr
Ты как то не так понял ООП. Оно нужно для построения гибкого и поддерживаемого приложения, а не для того чтобы ты мог сводить концы с концами

#19
16:49, 18 авг. 2019

Fedor1995
> Оно нужно для построения гибкого и поддерживаемого приложения
Вся школота так думает. Но, начнем с того, что никому не нужны гибкие и поддерживаемые приложения...

#20
17:29, 18 авг. 2019

Fedor1995

Товарищъ просто отказывается понимать, что есть разница между кодом, в котором 20тыс. строк и  > 1млн. строк.  И ООП придумали не от желания сделать с подвывертом, а из необходимости не сойти с ума, поддерживая всё это. Яркий пример с С++, к которому Страуструп пришёл, когда работал в телефонной компании и поддерживал код АТС с тем самым овер 1млн. строк кода на Си.

+ Показать


gudleifr
> не нужны гибкие и поддерживаемые приложения...

Ты здоров? Если ты написал софтину, которая даже если только для внутреннего использования, то постоянно приходится в ней исправлять ошибки и осуществлять доработки, часто впихивая функционал, которого в изначальном ТЗ не было. И хорошо, если возможность расширения была (или параметризация, или система логгирования) предусмотрена изначально.  И это примерно 90% работы программиста, а не напридумывание новых иерархий их сущностей.

#21
17:36, 18 авг. 2019

0iStalker
> что есть разница между кодом, в котором 20тыс. строк и > 1млн. строк.
Есть. И на настоящей момент ООП умеет раздуть работающие 20тыс. до внушительно выглядящих 1млн., но не более того. Эти 980тыс. повисают мертвым грузом.

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

#22
(Правка: 18:16) 18:13, 18 авг. 2019

gudleifr

В шестой раз повторяю, - у Страуструпа была программа на овер 1млн. строк кода на Си, без ООП. Так что раздуть программу можно чистой копипастой и процедурным подходом, а вот как-то её поддерживать с адекватными трудозатратами  - нет.

gudleifr
> Почему не нужны гибкие и поддерживаемые приложения?

Идёт речь о гибкости кода, внутри, - малая связанность, модульность, итд. Чтобы можно было добавить поддержку какого-нибудь, например, нового сканера штрихкодов в складской программе не перелопачивая половину кода . А не о гибкости снаружи, чтобы пользователь из калькулятора мог сделать фотошоп.

#23
(Правка: 18:17) 18:17, 18 авг. 2019
0iStalker
С кем ты разговариваешь? Я сразу не понял, но видимо он какой то местный человек особоострого ума
#24
18:25, 18 авг. 2019

Fedor1995
> Я сразу не понял, но видимо он какой то местный человек особоострого ума
>

Да мы в курсе, https://gamedev.ru/flame/forum/?id=226833  просто, ещё есть надежда донести простые вещи

#25
(Правка: 18:36) 18:31, 18 авг. 2019

0iStalker
> Так что раздуть программу можно чистой копипастой и процедурным подходом
Можно. ООП только ускоряет этот процесс.

0iStalker
> Чтобы можно было добавить поддержку какого-нибудь, например, нового сканера
> штрихкодов в складской программе не перелопачивая половину кода .
А если распознаватель штрихкода и складская программа будут двумя разными программами, общающимися средствами ОС, то не только ничего перелопачивать будет не надо, но Вы сможете и фотошоп с калькулятором к ним прицеплять... И весить это будет совсем не 1млн. строк...

C++ Страуструп, действительно, придумывал с благими целями, но классическое ООП уперлось в невозможность реального рефакторинга.

Fedor1995
> Я сразу не понял
Это хорошо. ИТ-индустрия стоит на теореме об обезьянах, чем их больше, тем лучше.

0iStalker
> Да мы в курсе, https://gamedev.ru/flame/forum/?id=226833
О, оказывается, есть уже целое движение "не осиливших 8 строчек... но пишущих миллионы".

P.S. Мои извинения топикстартеру... Действительно, говорить о программировании с кончеными гуманитариями трудно.

#26
(Правка: 19:18) 19:16, 18 авг. 2019

gudleifr
Слушай, а сколько строк тебе понадобится, чтобы написать Urban Legend in Limbo? Ты будешь писать его на Форте? А какие будут минимальные системные требования для 720 х 60фпс?
А когда будешь делать адд-он с новыми персонажами - будешь переписывать всё с нуля? Или у тебя будет каждый персонаж - отдельная программа?

#27
(Правка: 19:54) 19:52, 18 авг. 2019

Delfigamer
> Слушай, а сколько строк тебе понадобится, чтобы написать Urban Legend in Limbo?
"Если кит и вдруг на слона налезет? Кто кого сборет?" (c)
На основании каких данных я должен ответить на этот вопрос?

Delfigamer
> А когда будешь делать адд-он с новыми персонажами - будешь переписывать всё с нуля?
Я для кого показывал, как решаются такие проблемы в реально работающих программах - https://gamedev.ru/flame/forum/?id=243937 ?
И, заметьте, никаких иных альтернатив мне там не предложили.

#28
12:30, 19 авг. 2019

gudleifr
> "Если кит и вдруг на слона налезет? Кто кого сборет?" (c)
Не вижу, как это относится к вопросам.

gudleifr
> На основании каких данных я должен ответить на этот вопрос?
На основании тех же самых данных, которые привели к тебя к выводу, что ООП не нужно и ни одна программа не содержит более 20к строчек эффективного эквивалента. Это же твой личный опыт, я верно понимаю?

gudleifr
> Я для кого показывал, как решаются такие проблемы в реально работающих
> программах - https://gamedev.ru/f… um/?id=243937 ?
Твоё решение - переписать всё с нуля, я правильно понял?

И ты не ответил на этот вопрос:
Delfigamer
> Ты будешь писать его на Форте?

#29
16:14, 19 авг. 2019

Delfigamer
> Не вижу, как это относится к вопросам.
А я вижу. За сколько я напишу программу, которую мне не надо писать, в условиях, которые мне неизвестны?

Delfigamer
> ни одна программа не содержит более 20к строчек эффективного эквивалента.
Дык, я говорю с людьми, которые не могут 8 строк на BASIC заменить 100 строками на "современных языках".

Delfigamer
> Твоё решение - переписать всё с нуля, я правильно понял?
В 90% случаев.

Delfigamer
> Ты будешь писать его на Форте?
Сферический конь в вакууме? Хорошо.
Всяко "язык рисования мультиков и их оживляжа" (то, что быдло называет движком), потребует "единого языка управления", позволяющего "телепать телепузиков", согласно логике игры. Каким может быть язык?
- Он может быть "машинным" (ассемблерным) с доступом к объектам "движка", например, MS CIL или  Sierra AGI/SCI...
- Ом может быть конечным интерпретаором - BASIC,
- Развивающимся интерпретатором - FORTH или LISP.
В процессе писания логики неизбежно появится еще один язык - описания мира игры/сюжета, в идеале понятный сценаристам. Для него требования ужесточаются, ОО-ассемблеры и LISP-побобные будут излишне напрягать техписов синтаксисом.
Остаются BASIC-и и FORTH. Но BASIC для каждого уровня абстракции придется писать заново, а FORTH может расти постепенно от простого управления "движком", до написания сценария дизайнером...
Какие причины побудят нас отказаться от такого подхода? Только представление игры в виде неделимого монолита, который можно просчитать строго аналитически "сверху вниз". Но это - нездоровые фантазии наших движкописателей.
 

Страницы: 1 2 3 Следующая »
ФлеймФорумПрограммирование