A
Через дженерики?
Size: a a a
2021 April 10
g
ооп почти всегда плохой вариант, кроме гуя
A
Да вот я о том же. Не то что он плохой, но года когда всё делали через она уже прошли - имхо
g
а я как раз хочу попробовать переписать чтонибудь мелко гуевое с валы на ним чтоб попрактиковаться, выбрал вот это https://github.com/lainsce/khronos
A
Ты выше про гуй? Если так, то просто чтобы не сбивать советами без ооп обойтись ... Ясно
A
Не могу открывать ссылки где Ява - это психическое, после 10-15 лет на Яве мне кажется что оттуда на меня вылезут логи с npe
g
ахах, но етот видос про ооп, и в основном в плохом ключе
g
и ява как популизовавшая его
G
Концепты 🤔
З/
ecs, ddd...
Они сложные на старте, но по итогу дают куда больше контроля и комфорта.
Они сложные на старте, но по итогу дают куда больше контроля и комфорта.
g
дада, параметризированные дженерики, наверное через них
A
Собственно ооп в гуйне, если я правильно понимаю проблему, именно что требует наследования
g
так точно
g
и то и другое было придумано в xerox park с Аланом Кейем, тогда ооп было немного другое, главным была посылка сообщений
A
И это есть в ниме object inhiretanse , но я сам не крутил глубоко
A
https://nim-lang.org/docs/tut2.html тут прямо после заголовка про ооп
g
тут2
A
Но, если про наследование, то тут важно про наследование методов, а вот насколько это надо в гуе я не знаю с ходу, наверное надо
g
и все таки без методов внутри объектов прям непривычно, это получается внутри методов объекта у нас нет так сказать неявного доступа к полям, и поля нужно брать у первого аргумента, чем то напоминает композицию над наследованием