Телеграмм чат группы fprog

мне пофиг на красоту. я не вижу, как это решается в принципе

01:26пожаловаться #1

Вл

В ладу in fprog_spb

то есть у тебя есть некоторая вторая пушка и в дальнейшем у тебя может возникнуть нужда использовать её там где первая пушка не появлется и это беда - ты будешь костыли сверху навешивать

01:26пожаловаться #2

ну у нас пока есть, оружие, пульки, отрисовываемые объекты минимум

01:26пожаловаться #3

из типов

01:26пожаловаться #4

В ладу

нужно самый первое повдение вынести в отдельный не наследумый класс и брать его там где 1я пушка появляется

т.е. вкладывать поведение внутрь каждого нового типа в виде делегата?

01:27пожаловаться #5

ещё и связаны данные и поведение, что конечно удобно для ооп, но не приводит к подобным проблемам

Вл

мб делегата

ещё одно кривое решение на х-е - это создание динамических пропертей. но это уже жалкоскрипт какой-то получается

01:28пожаловаться #8

Вл

В ладу in fprog_spb

слабо в этих словах разбираюсь (да я профнепригоден)

01:28пожаловаться #9

ООП иерархии с одним наследником - перестают налезать достаточно быстро, тут спору нету

01:28пожаловаться #10

В ладу

мб делегата

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

01:29пожаловаться #11

куда оно растет без наследования то?

01:30пожаловаться #12

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

01:30пожаловаться #13

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

01:31пожаловаться #14

ну ооп-иерархии это отдельный разговор, там все действительно не прекрасно

01:31пожаловаться #15