Он прост в устройстве, но сложен в использовании.

Я вот сейчас скажу нет. А ты потом нескажешь нет ДА и т.д. ) Без какой-либо аргументации это будет очень странно

мне мобх больше импонирует, но я взял редакс когда ебаная магия сломалась

?

и разобраться без пузыря стало невозможно

почему

мне мобх больше импонирует, но я взял редакс когда ебаная магия сломалась

Я отказался от mst когда посмотрел в профайлер

Проблема mobx кстати не в магии, а в том, что она вылезает из него и торчит во все стороны.

Поэтому она ломается

наблюдатели не наблюдают за наблюдаемыми

угу

могу ещё типичных примеров ООП скинуть

Проблема mobx кстати не в магии, а в том, что она вылезает из него и торчит во все стороны.

уроки ангуляра первой версии не учат ничему

Я вот сейчас скажу нет. А ты потом нескажешь нет ДА и т.д. ) Без какой-либо аргументации это будет очень странно

Попробуй форму сделать на redux-form и на чистом redux. И скажи, где у тебя пальцы больше устают.

https://github.com/ValveSoftware/source-sdk-2013/blob/master/sp/src/game/server/baseanimating.h где здесь похожесть на реальный мир???

Нигде. Ведь этот объект описывает сущность, которой нет в реальном мире.

сука

Policy Factory

ООП нихуя не похож на реальность

даже отдаленно

он наебывает нас

поэтому у меня подгорает, когда кто-то пишет что похож

почитай названия функций в рамде и по каждой расскажи что делает, не открывая описание ?

Попробуй форму сделать на redux-form и на чистом redux. И скажи, где у тебя пальцы больше устают.

А зачем форме редукс? У меня вся логика формы в форме, а вредукс данные попадают только догда прошел сабмит и валидация

почитай названия функций в рамде и по каждой расскажи что делает, не открывая описание ?

читал норм

ООП нихуя не похож на реальность

В реальности объекты не могут совершать действия? Или у них нет свойств? Или они не могут совершать действия над другими объектами?

почитай названия функций в рамде и по каждой расскажи что делает, не открывая описание ?

но понимаешь в чем прикол? тут есть ОПИСАНИЕ

Но м.б. у меня и нет каких-то супер сложных форм.

почитай названия функций в рамде и по каждой расскажи что делает, не открывая описание ?

?

но понимаешь в чем прикол? тут есть ОПИСАНИЕ

так это либа. а ты кидаешь проект

В реальности объекты не могут совершать действия? Или у них нет свойств? Или они не могут совершать действия над другими объектами?

man glass drink/drain у кого должен быть метод?

И это кстати вообще статический метод, а не метод объекта.

стакан может опустошаться

man glass drink/drain у кого должен быть метод?

У обоих. Почему бы и нет?

И это кстати вообще статический метод, а не метод объекта.

ок лови следующее

Метод меняет состояние объекта. Что тут нехорошего? Это как заливать бензин в автомобиль.

У обоих. Почему бы и нет?

ну дык)

для совершения одного действия нужно 2 метода у каждого

потом модель раздувается до размеров галактики

man glass drink/drain у кого должен быть метод?

у неявного глобального состояния этой вселенной

для совершения одного действия нужно 2 метода у каждого

И?

Метод меняет состояние объекта. Что тут нехорошего? Это как заливать бензин в автомобиль.

количество параметров тебя не смущает?

потом модель раздувается до размеров галактики

SRP никто не отменял

SRP никто не отменял

ты о чем

количество параметров тебя не смущает?

Смущает и const у функции тоже. Но это не недостаток ООП.

Смущает и const у функции тоже. Но это не недостаток ООП.

это не функция

ты о чем

Здрасте, приехали. https://ru.wikipedia.org/wiki/SOLID_(%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

это не функция

Простите, у метода.

Здрасте, приехали. https://ru.wikipedia.org/wiki/SOLID_(%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

бля

Здрасте, приехали. https://ru.wikipedia.org/wiki/SOLID_(%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

так и у кого должен быть метод?!

Или ты думаешь, что в ФП нельзя написать уродливую функцию, которая принимает 10 000 аргументов?

у неявного глобального состояния этой вселенной

drink(glass, man)

да

все просто

го лучше в ооп чат)

оп гоп

Или ты думаешь, что в ФП нельзя написать уродливую функцию, которая принимает 10 000 аргументов?

фп пропагандирует каррирование) ну так

го лучше в ооп чат)

так реакт же и есть ооп

а есть чат для RN?

так и у кого должен быть метод?!

У человека drink, который вызывает drain у стакана и выполняет ещё действия (открыть рот, поднести стакан и так далее)

а есть чат для RN?

@reactnative_ru

фп пропагандирует каррирование) ну так

А ООП пропагандирует SOLID. И если следовать пропаганде, то не будет таких ужасов.

У человека drink, который вызывает drain у стакана и выполняет ещё действия (открыть рот, поднести стакан и так далее)

а стакан должен быть отнаследован от ПредметИзСтекла, СосудИзКоторогоМожноПитьДержаВРуке

а стакан должен быть отнаследован от ПредметИзСтекла, СосудИзКоторогоМожноПитьДержаВРуке

А кто сказал, что он должен, обязан быть унаследованным от кого-то?

а стакан должен быть отнаследован от ПредметИзСтекла, СосудИзКоторогоМожноПитьДержаВРуке

в ооп отказались от наследования)

ага

ERROR: S client not available

Может он не хочет быть унаследованым?

конечно

появлется кружка

что делать?

а стакан должен быть отнаследован от ПредметИзСтекла, СосудИзКоторогоМожноПитьДержаВРуке

вообще когда кодовая база большая и сущностей много, это удобно и позволяет от ошибок избавляться многих

Может он интерфейсы хочет имплементировать?

чтобы можно было пить и из того и того

что делать?

Интерфейсы

вообще когда кодовая база большая и сущностей много, это удобно и позволяет от ошибок избавляться многих

чет опыт показывает наоборот

только ты не путай наследование и имплементацию

интерфейсы рулят

наследование сосет

Интерфейсы

для каждого класса реализовывать заново или же просто написать класс который будет в себе хранить имплементацию питья из емкости?

и на каждую операцию проводимую над предметом появляется класс который можно к нему применить

для каждого класса реализовывать заново или же просто написать класс который будет в себе хранить имплементацию питья из емкости?

трейты

трейты

в плюсах, ага

в плюсах, ага

не пиши на плюсах, пиши на расте или шарпах)

в плюсах, ага

Мы плюсы обсуждаем, или ООП?

ты видел как этот паттерн там выглядит?

Мы плюсы обсуждаем, или ООП?

окок)) трейты)) то есть у нас появляется ещё одна концепция которой нет в реальности

для каждого класса реализовывать заново или же просто написать класс который будет в себе хранить имплементацию питья из емкости?

Можно вынеси в отдельную независимую функцию

Можно вынеси в отдельную независимую функцию

вооот

осталось избавиться от методов на объектах

вооот

Только не надо путать функции и ФП.

никто не путает)

окок)) трейты)) то есть у нас появляется ещё одна концепция которой нет в реальности

ну это грубо говоря интерфейс с частичной реализацией себя же

осталось избавиться от методов на объектах

Нет. Не надо. Надо избавится от мутабельности. Тогда ФП будет.

@oop_ru

@oop_ru

Но мы же ещё ФП обсуждаем.

Но мы же ещё ФП обсуждаем.

@it_holywars

Эх, ну ладно

Структура — это не объекты