Почему боятся ООП?

Потому что современное ООП это говно для идиотов.

И ООП-программисты до уровня CLOS или даже Smalltalk до сих пор так и не дошли.

Чего на шарпе тогда сидишь и всем советуешь?

Полиморфизм прекрасно работает и без ООП

Можно примеры? Вы наверное про трейты в ржавом?

Мультиметоды?

Можно примеры? Вы наверное про трейты в ржавом?

Пожалуйста: https://clojure.org/reference/multimethods

Что там в ржавом творится, не знаю и знать не хочу %)

В этом был мой поинт

Просто твоё ООП - говно. Сурьёзное ООП сейчас - это не ООП 20 годков назад, когжда можно было залезть на коня, назваться дядюшкой и штамповать брошуры с пометкой «чистый код».

Сейчас ООП поднимает пласт сдувает пыль и клеит новые названия, с других подходов, ЯП и т.д. И чтобы это было нормальное ООП, надо много знать.

Вот тебе пример:

public IGenericRepository<TEntity> Repository<TEntity>() where TEntity : BaseEntity
    {
        var type = typeof(TEntity).Name;

        return (IGenericRepository<TEntity>)_repositories.GetOrAdd(type, t => 
        {
            var repositoryType = typeof(GenericRepository<>).MakeGenericType(typeof(TEntity));

            return Activator.CreateInstance(repositoryType, context)
                ?? throw new InvalidOperationException($"Could not create repository instance for {t}");
        });
    }

Чего на шарпе тогда сидишь

Не сишарпом единым славен дотнет. Вот, скажем, F# там есть — про ООП он, конечно, в курсе, но акцент там не на ООП делается.

что некорректно в этой фразе, если без маркетоидной шелухи.

всё.

При этом доступен инструментарий Dotnet, что, эээ, даёт невероятные плюсы.

доступен инструментарий Dotnet, что, эээ, даёт невероятные плюсы

Отож. Шикарно же, когда есть возможность экспериментировать с интересными язычками и подходами, не изобретая каждый раз заново всю платформу и всю экосистему библиотек и инструментов. Это позволяет новым язычкам быть не только интересными, но и практичными.

Но это в любом случае не то, что сделали в Go и Rust, и авторы данных фич вряд ли говорят, что это не ООП.

Он не новый. Но его отличает готовая экосистема, что у других в той или иной мере не так. Здесь разве что CL может похвастаться. Но опять же, кто будет учить абстракции?

Яркий пример - это масса докладов на говно по фронту «с придыханием» RxJS или монорепа… Нет, чтобы версионировать (мозга то нет), давайте забьём на основы и сделаем свалку. Так удобнее (кому?). Мы же используем во всех наших недопроектах набор инструменов, стилей etc?

наследование - экзотическая фигня нигде практически не нужная

Передаю привет из геймдева, тут на наследовании половина игры строится

Ну, это типичный ООП. По вашей ссылке вижу наследование (иерархию) и полиморфизм.

Особо ржачно наблюдать, когда на ржавом пытаются делать игры ) Там даже целый фреймворк изобрели, чтобы хоть какой-то ООП иметь в рантайме.

Почему боятся ООП?

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

Куда не надо сувать ООП? Полный идиотизм не сувать везде ООП, потому что мы банально живём в мире объектов/сущностей со своими свойствами и функциями. То, что ЯП 90-х реализовали кривой ООП это отдельная сторона вопроса. Но у них тогда опыта не было. Реализовывать ЯП без ООП в 21 веке верх идиотизма.

ОПП - это набор абстракций и правил. Сложных. То, что в FP мире делается с пол-пинка тут выглядит непонятной НЁХ. Но решает сурьёзные проблемы: берём «что-то» и работаем с ним, и нам плевать, как и куда и зачем. И повторю, ЭТО НЕ ПРОСТО!

Никто не говорит, что FP спасёт отца, как предсказывали Гуру, так и происходит, просто медленно и с понтами. «Мы вам покушать принесли! Смотрите, как эта конструкция ускоряет, улучшает и т.д.»!

Зоцени, мой недалёкий ТС такую байду: https://javascript.info/currying-partials и вот это - https://medium.com/javascript-scene/reduce-composing-software-fe22f0c39a1d

Для Ъ:

// pipe 
const pipe = (...fns) => x => fns.reduce((v, f) => f(v), x);

// carrying

```function curry(f) { // curry(f) does the currying transform
  return function(a) {
    return function(b) {
      return f(a, b);
    };
  };
}

// usage
function sum(a, b) {
  return a + b;
}

let curriedSum = curry(sum);

alert( curriedSum(1)(2) ); // 3

Кто, кто блина на JS раньше слышал про Хаскела Карри? А теперь это вопросы на синьёра-помидора! Смешно? Грустно!
И это чёткий показатель, что мир меняется в строну объединения FP и старого OOP!

меняется в строну объединения FP и старого OOP

Почему нет, если это удобно?

Куда не надо сувать ООП?

Туда, где оно совершенно неуместно.

мы банально живём в мире объектов/сущностей со своими свойствами и функциями.

Ну и живите в этом своём мире, фигли, кто вам не даёт-то? Просто не надо своими проблемами тыкать в морду нормальным людям.

Так никто и не против, ты, видимо, забыл, как тут и не только тут пенились? «Функциональщина на проде? Фуууу!» И «ООП - это наследование (множественное)», ага-ага!

[мультиметоды] … это типичный ООП

Фейспалм. И где же там объекты, инкапсулирующие изменяемое состояние и обменивающиеся сообщениями? Мультиметоды позволяют определять полиморфные функции над любыми значениями (наборами значений) — им не обязательно даже обладать идентичностью.

вижу наследование (иерархию)

Это и называется — слышал звон, да не знаю, где он. Значения можно организовать в (ad-hoc) иерархии, это иногда удобно — но это совершенно не обязательно для того, чтобы мультиметоды работали.

и полиморфизм

Вот так неожиданность, правда? %) Это именно он — в чистом виде, без всяких левых наслоений.

Туда, где оно совершенно неуместно.

Для особо одаренных, где оно неуместно?

Свойства элементов гуя?

И где же там объекты, инкапсулирующие изменяемое состояние и обменивающиеся сообщениями?

Кто вам не даёт создать иммутабельные объекты?

Мультиметоды позволяют определять полиморфные функции над любыми значениями (наборами значений)

Ну, под капотом это и есть ООП. Вы просто увидели Джаву/Кресты и пытаетесь мыслить, что это и есть ООП. Но это просто одна из реализаций.

Значения можно организовать в (ad-hoc) иерархии, это иногда удобно — но это совершенно не обязательно для того, чтобы мультиметоды работали

Так и в ООП вас не заставляют всё наследовать и классы могут существовать без иерархии с полиморфизмом через общий интерфейс.

Что там в ржавом творится, не знаю и знать не хочу %)

Зря, о «Ржавом» реальные пацаны заряжают тему, что на данный момент - высшая форма жизни.

Опять же реальные пацаны заряжают, что «Ржавый» не для старпёров, которые не хотят учить новое. Ну и страшноват, да.

И это чёткий показатель, что мир меняется в строну объединения FP и старого OOP!

Нет, мой тролляшный друг, это просто кто-то прочитал о ФП и решил подрочить на используемом им языке.

Не, никто тут не троллит. Spread оператор внесли на руках в JS?

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

А потом расскажешь о «прочитал про ФП»…

pipe же применяется на async выхлоп, чтобы не промисом единым…

Там не нужны какие-то свойства. Вот исходники - https://github.com/vbcnthfkmnth123/xdmshutdown

под капотом это и есть ООП

Нет там никакого ООП, только обычные значения и функции, которые ими оперируют. Кстати, функции — это тоже значения.

Ну, да это обрезанный ООП, его подмножество.

обрезанный ООП

Ой-вей.

Кстати, сам мультиметод таки да можно рассматривать как объект с изменяемым состоянием, принимающий сообщения %)

Он сООПился за наши грехи, чтобы нам не приходилось, так сказатб.

И где же там объекты, инкапсулирующие изменяемое состояние и обменивающиеся сообщениями?

В Clojure кривые мультиметоды, слабенькие. Не CLOS, конечно.

Но обмен сообщениями - как раз устаревшая концепция, с кучей нерешенных проблем, потому что главное это всегда на самом деле взаимодействие объектов. Которое и инкапсулируют обобщенные функции.

inb4 в жабе и подобном говне и обмена сообщениями то нет. Это уже уровень выше - это Smalltalk, или Erlang там.

MIT не родило SICP для ООП (или родило?)

без академичности все эти SOLID творчество дворца пионеров. какие нибудь Django с DRF не позволяют художникам творить (больше похоже на труд 1Сника), а попытка создать что-то вроде своего DRF превращается в реверс-инжениринг исходников.

В Clojure кривые мультиметоды, слабенькие. Не CLOS, конечно.

Мультиметоды как раз нормальные — максимально простые, общие и гибкие (диспетчеризация по произвольной функции от всех аргументов), без лишнего овна, как в CLOS — что там наворотили, это же смотреть страшно, не то, что пользоваться.

То, что делает из обобщённых функций CL хтоническую хрень, в Clojure вынесено отдельно — в протоколы и нативный жабий ООП. Для тех, кто хочет немного побыстрее и согласен на урезанную функциональность (и не боится ковыряться в овне, конечно — если речь про жабий ООП).

Design is taking things apart (tm).

Родило.

Все эти творчества были на бумаге в девяностых, сейчас это чистая практика. Тот же DI ужо везде с пометкой «какие мы молодцы и как мы придумали». И да, молодцы и придумали. При этом ещё и происходит в рантайме, что добавляет ишшо один слой абстракций.

и тут ты такой с ссылкой на академический курс вроде SICP. 3..2..1..слив. надеюсь понятно чем академический курс отличается от книги для домохозяек или разработчика CRUD-систем. пока академического курса нет, все это ооп не более чем творение гениев вроде троллтехов или психов с GTK, а не инженерия.

например, есть книга по SCALA которая вполне академична, а вот что сишника - не понять, не исходники же MFC Qt

мир меняется в строну объединения FP и старого OOP

Скорее оба подхода затыкают дыры в своей логике адаптируя подходы от конкурента.

В CLOS все как раз сделано нормально, хикки просто банально неосилил реализацию CLOS. Как и многие другие вещи из CL.

Зря, о «Ржавом» реальные пацаны заряжают тему, что на данный момент - высшая форма жизни.

И вы говорите что в 65 можете каждый день…

Зоцени атвет гопоты: (типо минимум)

*«Design Patterns: Elements of Reusable Object-Oriented Software» by Gamma, Helm, Johnson, and Vlissides (often called the «Gang of Four» book) *«Patterns of Enterprise Application Architecture» by Martin Fowler *«Clean Architecture: A Craftsman’s Guide to Software Structure and Design» by Robert C. Martin

*«Domain Modeling Made Functional» by Scott Wlaschin (book) *«F# for Fun and Profit» (website and YouTube channel by Scott Wlaschin)

В CLOS все как раз сделано нормально

Кому и кобыла невеста.

хикки просто банально неосилил реализацию CLOS

У него не было цели реализовать CLOS — у него была цель сделать то, чем можно пользоваться, не вырывая себе все волосы на жопе. Пользоваться на практике, для создания реальных систем и зарабатывания реальных денег, а не только для академических статей и самолюбования.

И у него получилось.

Ну, их мнение для меня имеет вес. А своего на Rust у меня пока не сложилось. А раньше тоже говорил «могу» :)

Скорее оба подхода затыкают дыры в своей логике адаптируя подходы от конкурента.

Всё так.

Да ты, парниша, туповат. Открой Angular или Fullstack Nextjs. Потом приходи и пиши «надеюсь понятно чем академический курс отличается от книги для домохозяек или разработчика CRUD-систем»

Ну про паттерны GoF я бы пропустил, пожалуй (здоровым людям костыли ни к чему), а остальное вполне уважаемое чтиво.

Собственно, поэтому гопота его тебе и выдала %)

Открой Angular или Fullstack Nextjs

совет уровня пользователя фреймворка

ты туп

/0

«с придыханием» … монорепа

А чё монорепа, монорепа тащит. Очень удобно — если знать, как пользоваться.

когда ты принесешь академический курс, позволяющий написать проект уровня Angular (lol, он ООП?), можешь выйти из зобана. или вы советуте мне забросить науку и устроиться писать на php?)