Я привел аж три способа реализации полиморфизма (union type, обобщение и интерфейс), и даже указал в каких случаях их лучше использовать, и даже реализовал где то здесь в комментариях код на обобщениях, который якобы "нельзя реализовать на ФП".
Вот фраза из статьи, с дальнейшими примерами кода:
Далее в примере для этого будут использоваться union type, обобщение и интерфейс:
Я только и делаю, что пишу большие системы с абстракциями, и как я уже говорил, сейчас практически все сайты, в тч самые сложные и высоконагруженные, пишутся в парадигме ФП, если вы не знали.
Во-первых ООП в моем видении, описаном в статье, в приведенном коде отсутствует. Это просто псевдо-декларативное описание модели и поведения, на основе которой генерируется ООП код, а мог бы генерироваться и ФП с тем же "успехом".
Почему псевдо - потому что если слишком много логики запихнуть в декларативность, то как работает код поймет только его автор [и Майкл Джексон]. Так же он будет обладать большим количеством ограничений, на который наткнешься уже по факту, и чтоб от них избавиться придется все переписывать. И чтобы реализовать даже простейшую задачу, придется очень долго и нудно читать документацию этого фреймворка. Поэтому ваш фреймворк обречен, к сожалению.
Другими словами, вы не выполнили главное требование инженера - чем проще, тем лучше.
Вот как выглядит хороший, простой код (псевдокод) на функциях:
// Модель отделена от логики
type User = {
id: number
name?: string
description?: string
created_at?: number
avatarUrl?: string
hobbies?: string
}
// Хранение состояния отделено от UI и слоя доступа к данным.
// Здесь мог бы быть любой стор - мутабельный, иммутабельный, на прокси или евент емиттерах и тп.
type EntitiesState = {
users: User[]
userConfigs: UserConfig[]
}
const entitiesStore = create<EntitiesState>({
users: [],
userConfigs: [],
})
// Бизнес логика.
const changeUserConfig: (userConfig: Partial<UserConfig> & Pick<UserConfig, "id">) => {
// Меняем значение в entitiesStore.
}
// UI - любая библиотека на усмотрение.
const UserPage = ({id}: {id: string}) => {
const user = useEntitiesStore((state) => selectUser(state, id))
if (!user) return <Loader />
return (
<Html>
<Title value={user.name} />
<Description value={user.description} />
// ...
</Html>
)
}
Если приведете более конкретный пример кода, который надо реализовать, я вам напишу как. Главное только чтобы это было не ограничение заточенного под ООП языка.
Если хотелось реализовать мемоизированное вычисляемое состояние, то это делается элементарно в каком нибудь zustand / redux через reselect, если устраивает иммутабельный стор, если не устраивает есть и мутабельные сторы в парадигме ФП.
Более того, можно хоть на ивент еммитерах это реализовать если нужна супер произвотидельность.
Но самое смешное что даже RX из ваших примеров можно использовать в парадигме ФП, и первый кусок кода в ней и написан, если не считать создание BehaviorSubject через new, который мог бы создаваться через функцию make*.
Вот код что сгенерировал GPT, я не проверял но плюс минус то же самое но без классов - меньше, понятнее и без проблем из статьи:
Мойка воздуха + самая маленькая ультрафиолетовая лампа для аквариумов внутри, которую включаю раз в день на три часа (выключается автоматически). Стоит у батареи.
Бризер breeza 150 lux на максимуме на постоянке + иногда открываю окна (перед сном).
Монитор качества воздуха qingping.
В целом Питерской зимой справляется, чищу мойку в посудомойке может раз в 1-2 месяца, когда совсем пожелтеет.
Разве что воду два раза в день доливать неудобно, вот тут бы автоматизировал.
В вашем примере полиморфизма сердцем кода является свитч.
Вы точно не читали статью.
Просить показывать код, который собеседник писал в течение жизни
Любое утверждение можно доказать кодом. Если много писал в течение жизни и точно знаешь что ООП лучше, так уж тем более накидаешь примерчик, который лучше на ООП чем ФП. Но с этим проблема, тк правотой и не пахнет.
именно тем, для чего ООП предназначено, вы не занимались
Большинство современного кода - ФП, включая современные frontend фреймворки, менеджеры состояний, и даже ядро Linux. Так что даже бессмысленно еще что то приводить.
Вы кажется не очень внимательно читали статью, тк полиморфизм есть в ФП, и куда более удачный, и не только через switch. И мне тут даже примеры кода скидывали, которые якобы не реализовать по нормальному в ФП, и я реализовывал его на интерфейсах без проблем лучше чем в ООП.
Если внимательно изучить все доводы из статьи, станет ясно что у ООП нет ни одного преимущества, и никто в комментариях не смог внятно хоть одно указать и объяснить. Сложная система не может быть лучше, если построена на неудачных архитектурных принципах. И сложная система на ООП как раз таки станет еще хуже, чем простая.
Идея интересная, но хотелось бы больше примеров кода, например что с многопоточностью, как вы видите архитектуру gui приложения, на каких платформах уже можно их запускать, так же как и серверный код - можно ли заменить nodejs, с замерами производительности.
Я привел аж три способа реализации полиморфизма (union type, обобщение и интерфейс), и даже указал в каких случаях их лучше использовать, и даже реализовал где то здесь в комментариях код на обобщениях, который якобы "нельзя реализовать на ФП".
Вот фраза из статьи, с дальнейшими примерами кода:
Я только и делаю, что пишу большие системы с абстракциями, и как я уже говорил, сейчас практически все сайты, в тч самые сложные и высоконагруженные, пишутся в парадигме ФП, если вы не знали.
Вот пример мобильного приложения https://github.com/mattermost/mattermost-mobile. Там же есть и десктоп, и веб.
Вы не специалист, наконец то признали, тогда есть чему поучиться.
Во-первых ООП в моем видении, описаном в статье, в приведенном коде отсутствует. Это просто псевдо-декларативное описание модели и поведения, на основе которой генерируется ООП код, а мог бы генерироваться и ФП с тем же "успехом".
Почему псевдо - потому что если слишком много логики запихнуть в декларативность, то как работает код поймет только его автор [и Майкл Джексон]. Так же он будет обладать большим количеством ограничений, на который наткнешься уже по факту, и чтоб от них избавиться придется все переписывать. И чтобы реализовать даже простейшую задачу, придется очень долго и нудно читать документацию этого фреймворка. Поэтому ваш фреймворк обречен, к сожалению.
Другими словами, вы не выполнили главное требование инженера - чем проще, тем лучше.
Вот как выглядит хороший, простой код (псевдокод) на функциях:
Если приведете более конкретный пример кода, который надо реализовать, я вам напишу как. Главное только чтобы это было не ограничение заточенного под ООП языка.
Дождались наконец.
При чем тут процедурная?
Примеров все еще нет.
Если хотелось реализовать мемоизированное вычисляемое состояние, то это делается элементарно в каком нибудь zustand / redux через reselect, если устраивает иммутабельный стор, если не устраивает есть и мутабельные сторы в парадигме ФП.
Более того, можно хоть на ивент еммитерах это реализовать если нужна супер произвотидельность.
Но самое смешное что даже RX из ваших примеров можно использовать в парадигме ФП, и первый кусок кода в ней и написан, если не считать создание BehaviorSubject через new, который мог бы создаваться через функцию make*.
Вот код что сгенерировал GPT, я не проверял но плюс минус то же самое но без классов - меньше, понятнее и без проблем из статьи:
Поищите на маркетплейсах «мини-UV УФ стерилизатор для аквариума, С таймером Ультрафиолетовая аквариумная лампа, 3 Вт».
Если не пахнет значит часто моете)
У меня такая же, маленькая лампа влезла ровно под бак. Запах у воды с тех пор пропал.
Купите мойку, киньте ультрафиолетовую лампу для аквариумов - все.
Бактерии убиваются ультрафиолетовыми лампами для аквариумов.
Купите ультрафиолетовую лампу для аквариумов, самую маленькую, и забудьте про перекись.
А моется в посудомойке прекрасно.
Мой набор для спальни / рабочего места (25 м2).
Мойка воздуха + самая маленькая ультрафиолетовая лампа для аквариумов внутри, которую включаю раз в день на три часа (выключается автоматически). Стоит у батареи.
Бризер breeza 150 lux на максимуме на постоянке + иногда открываю окна (перед сном).
Монитор качества воздуха qingping.
В целом Питерской зимой справляется, чищу мойку в посудомойке может раз в 1-2 месяца, когда совсем пожелтеет.
Разве что воду два раза в день доливать неудобно, вот тут бы автоматизировал.
Элементарно с помощью любого современного менеджера состояний, который больше нравится.
Вы точно не читали статью.
Любое утверждение можно доказать кодом. Если много писал в течение жизни и точно знаешь что ООП лучше, так уж тем более накидаешь примерчик, который лучше на ООП чем ФП. Но с этим проблема, тк правотой и не пахнет.
Большинство современного кода - ФП, включая современные frontend фреймворки, менеджеры состояний, и даже ядро Linux. Так что даже бессмысленно еще что то приводить.
Вы кажется не очень внимательно читали статью, тк полиморфизм есть в ФП, и куда более удачный, и не только через switch. И мне тут даже примеры кода скидывали, которые якобы не реализовать по нормальному в ФП, и я реализовывал его на интерфейсах без проблем лучше чем в ООП.
Если внимательно изучить все доводы из статьи, станет ясно что у ООП нет ни одного преимущества, и никто в комментариях не смог внятно хоть одно указать и объяснить. Сложная система не может быть лучше, если построена на неудачных архитектурных принципах. И сложная система на ООП как раз таки станет еще хуже, чем простая.
Talk is cheap, show me the code (c)
Совет - присматриваться к будущим руководителям, выбирать крепких технарей.
Посредственные тянут посредственных, крутые крутых. Друг с другом они не уживаются.
Идея интересная, но хотелось бы больше примеров кода, например что с многопоточностью, как вы видите архитектуру gui приложения, на каких платформах уже можно их запускать, так же как и серверный код - можно ли заменить nodejs, с замерами производительности.
Во-первых, эту новость писал не сотрудник амазон в их блоге, и она может быть выдумана от и до.
Во-вторых, там нет речи про то, что сотрудник без опыта, опыт то у него есть.
Решил одну проблему, заменив С на С++.
Теперь у тебя 1000 проблем.