Ну да он удалил много пробелов + то что вы вообще даже и не писали, так что, без разницы.
Если нужно раздать доступ к какой либо части состояния на все приложение, всегда можно экспортировать соответствующую функцию getState.
Ну супер, а потом сопостовлять стэйт и функции которые нужны? А учитывая что нет никакой типобезопасности то теоретически любой стейт может подойти любому тулу. Оч надёжно, как швейцарские часы.
Вообще ни разу, я удалил тк понял что мне в целом не интересно пытать ООП-шника на проблемы ООП тк уже целая статья расписана, но если вы готовы - то ок, предоставьте решение, хотя мне оно не особо нужно. И там вообще никаких проблем с типабезопасностью нет - instancer использует состояние намеренно, в этом и есть задача.
Нуда ну да, и вообще вы белый и пушистый, нет вы облажались, потому что исходный инстансер работал со строками и в принципе у него другая логика работы была, collect.processPick(state) влияет на работу instancer.processPick(state) а не должен ибо у них нет пересекающихся отношений, то что вы сделали как раз и показывает отсутствие типобезопасности.
Код на с++ проще читать и писать )))
Конкретно в данном случае, да. Что забавно )
можно прочитать статью еще раз и убедиться что если код без классов как минимум не хуже даже на примерах, специально сделанных ООП-шником, чем код с классами, то использовать классы это говнокод.
Так в том то и дело что он хуже, помимо типа вам нужно таскать стэйт, да и ещё и контролировать что стейты таскаются именно те что нужно, вы в своём же примере накосячили. Писать кода у вас больше нужно, и это с примитивным примером, в реальности полей у классов гораздо, гораздо больше, да и методов. И что вы все поля будете прокидывать через аргументы и инициализировать в каждом конструкторе? И это пример с минимальным наследованием. Вы же не тупой как 90% программистов, подумайте о сложности скалирования вашего решения. Да и стэйт вы по сути передаёте как this только явно и не типобезопасно.
Это вообще ограничение языка, были бы функции - использовал бы их. К этому придираться - это уже видимо совсем не к чему.
Ну так напишите решение на С где нет богомерзких методов, или выберите чисто функциональный язык типа хаскеля, зачем вам этот мерзкий тайпскрипт у которого есть классы и методы. Или с тем же успехом возьмите С++ и перепишите код на ++ без использования классов, ну это уже будет С.
Кстати это будет идеально, покажите что ваш подход лучше работает чем ООП подход в рамках одного языка. Можете любой язык взять. А то сравниваем компилируемый язык с интерпретируемым как-то неправильно.
А вот это ещё один минус вашего подхода, как потом использовать тул из других файлов? Как мне получить активный тул? Представте например что функция updateTool находится в другом файле. Ну и это получается своего рода инкапсуляция против которой вы так выступали.
ну так вы попробуйте использовать registerTool и узнаете что все в порядке.
да что вы, а не потому ли вы удалили код, который просили написать в ооп напомню:
А теперь внесем пару небольших правок (Playground):
потому что вы облажались и instancer использовал items от collect? код. Очень типобезопасно лол.
Код меньше и проще?) Сам себя не похвалишь, как говорится..
так вы сами так делаете постоянно, лол или в своём глазу бревна не видите?
И еще - мне не нужно описывать доп класс или структуру, я создал инструмент прямо в рантайме без дополнительных типов. Ну это так, к слову.
Забавно но бесполезно. Мой класс также можно впихнуть в main (что я собственно и сделал) и получить приватный тип.
По поводу задачи - вы доказывали что мол в ПП/ФП нельзя сделать так, как в ООП - я вам доказал что можно.
Компиль упаси, я не собирался доказывать что так нельзя сделать, это можно сделать в любой парадигме. Вопрос был в том где это будет сделать удобнее, быстрее, и проще поддерживать и расширять. И как мне кажется мой вариант получше вашего будет, ибо меньше возможностей накосячить (забавно что именно вы это продемонстрировали), меньше писать приходится (сравните по символам а не по строчкам если сомневаетесь) и проще читать. Ну и стоит учитывать что вы активно используете методы, против которых воюете (log, push, join). Как по мне я выиграл этот спор, ну по голосам за коменты тоже.
Да кстати, забыл добавить, что произойдёт с вашей системой если сделать например так
state.activeTool = 'some_invalid_name'
В моём случае просто вернётся фолз и активным останется тот тул что был, это к вопросу что у вас меньше кода, вы просто не весь функционал реализовали )) ну и форматирование у нас отличается чутка.
А теперь представьте себя на месте пользователя который хочет добавить свой тул (ведь вся эта ветка комментов была про это). Посмотрим у кого получится больше кода чтобы новый тул добавить.
Напоминаю, вам нельзя менять код редактора, то есть то что вы выше написали, менять нельзя. Это к вопросу о переиспользуемости кода. Как думаете сработает? Я вот сильно сомневаюсь.
В результате вы написали код который нельзя переиспользовать, вы дублируете объявление items: [], radius: 0 и передаёте их напрямую в collectItems (а представьте если бы там было намного больше параметров, ведь в реальности это именно так и происходит, какой-нибудь наследник от QPushButton).
Дополнительно помимо того что вы должны каким-то образом узнать какие функции нужно перегружать (в случае С++ сам компилятор подскажет) вы ещё должны и структуры правильно объявить, где тут DRY и простота?
По поводу больше\меньше кода. Ваши две функции:
const updateTool = (i: number) => {
if (!state.activeTool) return
const toolState = state.toolStates[state.activeTool]
switch (toolState.type) {
case 'align':
return align.update(toolState, i)
case 'collect':
return collect.update(toolState, i)
case 'instancer':
return instancer.update(toolState, i)
}
}
const processClick = () => {
if (!state.activeTool) return
const toolState = state.toolStates[state.activeTool]
switch (toolState.type) {
case 'align':
return align.processPick(toolState)
case 'collect':
return collect.processPick(toolState)
case 'instancer':
return instancer.processPick(toolState)
}
}
против моих
void processClick(int x, int y)
{
if (auto active_tool = ToolManager::instance().getActiveTool())
active_tool->processPick(x, y);
}
void update_tool(int i)
{
if (auto active_tool = ToolManager::instance().getActiveTool())
active_tool->update(i);
}
Не вижу чтобы было меньше, у меня больше кода только в том месте которое нужно чтобы потом писать в разы меньше кода.
Ну и вишенка на торте, вы точно также храните данные рядом с функциями, по сути повторяя ООП но при этом не получая никаких бонусов, а лишь геморрой.
Ну почему чепухой? Я так не считаю, просто из-за того что это совершенно другая сфера в которой у меня нет опыта я и не могу понять этот код, однако чепухой не считаю.
Не везде и не всегда, dod работает быстро и полезно для массовой обработки, но плох для узких вещей где нужна больше выразительность, большинство компаний используют либо смесь либо ооп подход. Хотя ecs конечно крутая тема.
Нет, этот код не является эквивалентным, у collectInRadius есть состояние радиуса, которое для каждого тула который унаследован от него может быть разным, align использует результат collectInRadius который является локальным только для этой тулы. Я думал это очевидно что состояния у каждой тулы своё и хотел увидеть как именно это вы решаете видимо вам явно надо это показать.
Ну и ваш код сразу же проспится если в тулы добавить больше методов, особенно если учитывать, например что часть методов нужно переопределять а часть нет. То бишь явно проблема скалирования.
Ну видимо наш теоретик решил слиться, что странно он ведь так рьяно просил код, а когда дело дошло до действий, то код уже не так уж и нужен, да @gen1lee?
Ну поднимать микросервисы ради такого, это мощно, и конечно же это будет работать быстрее и это будет проще поддерживать, правда ведь, правда?
Я не спорю с тем что любую систему можно написать в любой парадигме, вопрос в цене, цена продумывания, цена расширения возможностей, цена поддержки, цена производительности. Я не считаю что фп плохое (в случае автора конечно очевидно что это не фп а пп) как и любая другая парадигма, и думаю что все они полезны в своих сферах, я лишь спорю с автором что ООП это плохо.
Выше по ссылке я накидал пример минут за 10-15 сколько вам придётся потратить времени чтобы сделать тоже самое на микросервисах?
Насколько удобней будет пользователю расширять это? В моём решении всего лишь унаследоваться от интерфейса и переопределить метод.
Микросервисы мощный и очень полезный инструмент, но нужен ли он тут? Я ещё не видел 3D редакторов которые использовали бы микросервисы для плагинов.
По прежнему не увидел содержимого processPick, а customProcessPick как будет вызываться? Выше у вас processPick зовётся, каким образом он вызовет customProcessPick? а внутри у вас снова вызывается processPick бесконечная рекурсия?
Откуда мне знать что внутри кода из вашей головы? Возвращает какой то текущий тул? Вы мне расскажите.
У меня очевидно возвращается указатель на какой-нибудь ITool который является интерфейсом.
Ограничений в ФП нет вообще, любой ООП код можно без проблем переписать на ФП, и статья говорит о том, что он будет только лучше (на хорошем языке разумеется).
Но вы так и не написали, ну точнее написали но непонятно как оно работает.
Так объект выделяет сам тул по своей логике, и более того может выделить множество объектов, а может вообще не выделять а создавать. Если объект не выделен то что делать?
Вы просто, не понимаете, 90% разработчиков тупые и не понимают что используют, профессоры CS тоже 90% тупые и не понимают что пишут.
Мне вот интересно, а те кто выезжает на встречку тоже ведь наверно думают что вокруг все идиоты и едут не в ту сторону.
Ну вы же не тупой, должны были заметить единственную ссылку от michael_v89 https://www.mycompiler.io/view/LZT9EFBmlWr
Ну да он удалил много пробелов + то что вы вообще даже и не писали, так что, без разницы.
Ну супер, а потом сопостовлять стэйт и функции которые нужны? А учитывая что нет никакой типобезопасности то теоретически любой стейт может подойти любому тулу. Оч надёжно, как швейцарские часы.
Нуда ну да, и вообще вы белый и пушистый, нет вы облажались, потому что исходный инстансер работал со строками и в принципе у него другая логика работы была, collect.processPick(state) влияет на работу instancer.processPick(state) а не должен ибо у них нет пересекающихся отношений, то что вы сделали как раз и показывает отсутствие типобезопасности.
Конкретно в данном случае, да. Что забавно )
Так в том то и дело что он хуже, помимо типа вам нужно таскать стэйт, да и ещё и контролировать что стейты таскаются именно те что нужно, вы в своём же примере накосячили. Писать кода у вас больше нужно, и это с примитивным примером, в реальности полей у классов гораздо, гораздо больше, да и методов. И что вы все поля будете прокидывать через аргументы и инициализировать в каждом конструкторе? И это пример с минимальным наследованием. Вы же не тупой как 90% программистов, подумайте о сложности скалирования вашего решения. Да и стэйт вы по сути передаёте как this только явно и не типобезопасно.
Ну так напишите решение на С где нет богомерзких методов, или выберите чисто функциональный язык типа хаскеля, зачем вам этот мерзкий тайпскрипт у которого есть классы и методы. Или с тем же успехом возьмите С++ и перепишите код на ++ без использования классов, ну это уже будет С.
Кстати это будет идеально, покажите что ваш подход лучше работает чем ООП подход в рамках одного языка. Можете любой язык взять. А то сравниваем компилируемый язык с интерпретируемым как-то неправильно.
ну вашем коде выше этого всего нет.
ниже michael_v89 привёл код к вашему стилю.
А вот это ещё один минус вашего подхода, как потом использовать тул из других файлов? Как мне получить активный тул? Представте например что функция updateTool находится в другом файле. Ну и это получается своего рода инкапсуляция против которой вы так выступали.
да что вы, а не потому ли вы удалили код, который просили написать в ооп напомню:
потому что вы облажались и instancer использовал items от collect? код. Очень типобезопасно лол.
так вы сами так делаете постоянно, лол или в своём глазу бревна не видите?
Забавно но бесполезно. Мой класс также можно впихнуть в main (что я собственно и сделал) и получить приватный тип.
Компиль упаси, я не собирался доказывать что так нельзя сделать, это можно сделать в любой парадигме. Вопрос был в том где это будет сделать удобнее, быстрее, и проще поддерживать и расширять. И как мне кажется мой вариант получше вашего будет, ибо меньше возможностей накосячить (забавно что именно вы это продемонстрировали), меньше писать приходится (сравните по символам а не по строчкам если сомневаетесь) и проще читать. Ну и стоит учитывать что вы активно используете методы, против которых воюете (log, push, join). Как по мне я выиграл этот спор, ну по голосам за коменты тоже.
Ну вы же не тупой в отличии от 90% программистов должны же понимать что код написан для потенциального использования другим человеком и как концепт.
Так у вас не фп у вас вполне процедурный код, в нём я разбираюсь потому что с него и начинал, а вы никак не поймёте что ваш код не фп.
ну теперь то да.
Всё ещё больше моего варианта в вашем стиле. Ну и более чем уверен что больше по количеству символов.
А я уверен что ваше хуже. потому что по-прежнему никак не мешает сделать так
И всё сломать. Ну и в принципе играть с чужими стейтами и всё поломать.
А ещё у вас any имеется и как там с типобезопасностью?
Изи
И даже меньше строчек чем у вас, да и код меньше и проще.
Да кстати, забыл добавить, что произойдёт с вашей системой если сделать например так
В моём случае просто вернётся фолз и активным останется тот тул что был, это к вопросу что у вас меньше кода, вы просто не весь функционал реализовали )) ну и форматирование у нас отличается чутка.
О супер! Вы я надеюсь уверенны в своём коде.
А теперь представьте себя на месте пользователя который хочет добавить свой тул (ведь вся эта ветка комментов была про это). Посмотрим у кого получится больше кода чтобы новый тул добавить.
Вот что напишет пользователь моей системы:
Что должен написать пользователь вашей системы?
Напоминаю, вам нельзя менять код редактора, то есть то что вы выше написали, менять нельзя. Это к вопросу о переиспользуемости кода. Как думаете сработает? Я вот сильно сомневаюсь.
В результате вы написали код который нельзя переиспользовать, вы дублируете объявление items: [], radius: 0 и передаёте их напрямую в collectItems (а представьте если бы там было намного больше параметров, ведь в реальности это именно так и происходит, какой-нибудь наследник от QPushButton).
Дополнительно помимо того что вы должны каким-то образом узнать какие функции нужно перегружать (в случае С++ сам компилятор подскажет) вы ещё должны и структуры правильно объявить, где тут DRY и простота?
По поводу больше\меньше кода. Ваши две функции:
против моих
Не вижу чтобы было меньше, у меня больше кода только в том месте которое нужно чтобы потом писать в разы меньше кода.
Ну и вишенка на торте, вы точно также храните данные рядом с функциями, по сути повторяя ООП но при этом не получая никаких бонусов, а лишь геморрой.
Вы правда думаете что ваше решение лучше?
Ну почему чепухой? Я так не считаю, просто из-за того что это совершенно другая сфера в которой у меня нет опыта я и не могу понять этот код, однако чепухой не считаю.
Я так понимаю вы слились? Я так и думал.
Вот я ему тоже самое написал, но видимо человек который считает большинство людей тупыми, сам не очень то прозорлив.
Не везде и не всегда, dod работает быстро и полезно для массовой обработки, но плох для узких вещей где нужна больше выразительность, большинство компаний используют либо смесь либо ооп подход. Хотя ecs конечно крутая тема.
Хорошо, вот модифицированный вариант https://tinyurl.com/3yt8an7k
Нет, этот код не является эквивалентным, у collectInRadius есть состояние радиуса, которое для каждого тула который унаследован от него может быть разным, align использует результат collectInRadius который является локальным только для этой тулы. Я думал это очевидно что состояния у каждой тулы своё и хотел увидеть как именно это вы решаете видимо вам явно надо это показать.
Ну и ваш код сразу же проспится если в тулы добавить больше методов, особенно если учитывать, например что часть методов нужно переопределять а часть нет. То бишь явно проблема скалирования.
Ну видимо наш теоретик решил слиться, что странно он ведь так рьяно просил код, а когда дело дошло до действий, то код уже не так уж и нужен, да @gen1lee?
Ну поднимать микросервисы ради такого, это мощно, и конечно же это будет работать быстрее и это будет проще поддерживать, правда ведь, правда?
Я не спорю с тем что любую систему можно написать в любой парадигме, вопрос в цене, цена продумывания, цена расширения возможностей, цена поддержки, цена производительности. Я не считаю что фп плохое (в случае автора конечно очевидно что это не фп а пп) как и любая другая парадигма, и думаю что все они полезны в своих сферах, я лишь спорю с автором что ООП это плохо.
Выше по ссылке я накидал пример минут за 10-15 сколько вам придётся потратить времени чтобы сделать тоже самое на микросервисах?
Насколько удобней будет пользователю расширять это? В моём решении всего лишь унаследоваться от интерфейса и переопределить метод.
Микросервисы мощный и очень полезный инструмент, но нужен ли он тут? Я ещё не видел 3D редакторов которые использовали бы микросервисы для плагинов.
Хотите реальный челендж? Вот довольно простой легко читаемый код, в котором легко разобраться, легко добавить новый тул, легко использовать тул
https://tinyurl.com/2xkh2tvv
Напишите ваше решение в вашем стиле без ООП
Talk is cheap, show me the code.
Простите но всё равно не могу осилить код, слишком инопланетный для меня.
По прежнему не увидел содержимого processPick, а customProcessPick как будет вызываться? Выше у вас processPick зовётся, каким образом он вызовет customProcessPick? а внутри у вас снова вызывается processPick бесконечная рекурсия?
У меня очевидно возвращается указатель на какой-нибудь ITool который является интерфейсом.
Но вы так и не написали, ну точнее написали но непонятно как оно работает.
Честно говоря ничего не понял, можно комментарии написать? (в фп языках вообще не силён) это клиентский код или код редактора, или и то и то?
Так объект выделяет сам тул по своей логике, и более того может выделить множество объектов, а может вообще не выделять а создавать. Если объект не выделен то что делать?