стэйт это плохо, пнятненько?

а эт какой принцип SOLID/etc или че-то другое?

а эт какой принцип SOLID/etc или че-то другое?

ну тут можно про goto considered harmful почитать на тему того как плохо наши мозги могут справляться с побочными эффектами и зависимостью от времени

ну тут можно про goto considered harmful почитать на тему того как плохо наши мозги могут справляться с побочными эффектами и зависимостью от времени

>зависимостью от времени стримы не нужны получается)

>зависимостью от времени стримы не нужны получается)

слабенько накидываешь

почитай если хочешь)

океей

Я ооп целенаправленно не изучал, фоново, есть ли какие-то ошибки в рассуждениях и выводах?

Вообще такая тема

Недавно я посмотрел джавовский код

И увидел, что там нет жесткой практики писать this.

И в общем пришла ко мне мысль, что люди там пишут так, будто класс - это просто какая-то отдельная подпрограмма с функциями

То есть как раньше тупо объявляли глобальные переменные и функции для работы с ними, то так они пишут и сейчас, только глобальные - свойства классов, а так все один в один

Особенно это видно, когда нет this

То есть ооп в джаве - тупо способ масштабировать тот говнокод с глобальными переменными

Так в хаскелле как будто нельзя натыкать IORef'ов везде

Ну так и тыкают)

(

Но с большой неохотой

Потом ещё в ридер кидают

Поэтому тру-ооп и то, что в джавах практикуют - абсолютно разные вещи

И когда массы говорят, что они за ооп, они говорят не про тру-ооп, а про говнокод

А так, SOLID это имхо реально крутая тема

осталось смержить чаты

А всякие паттерны дизайна - это от дъявола

Я после этого видоса сильно угорел по солиду https://vk.com/wall-135720595_408

Этот мужик еще вот это написал в моем посте, что мол дизайн паттерны нужно заменить на абстракции из теорката

Так это же очевидно

Это первая мысль которая пришла мне в голову при перечитывании книжки про паттерны для джавы (осталась с давних времён?)

То что шаблоны описанные там перекладываются один к одному, авторы ещё так мол по секрету добавляют, что самая мощь — в их композиции

(а мужики то и не знали)

Ладно, пофиг про рекламу своей группы, которую я уже почти забросил из-за лива с вк, еслм я скину видос напрямую, его больше людей посмотрят https://youtu.be/CmCEdVrZQAE

видос норм да

Ладно, пофиг про рекламу своей группы, которую я уже почти забросил из-за лива с вк, еслм я скину видос напрямую, его больше людей посмотрят https://youtu.be/CmCEdVrZQAE

Видос посмотрел и да, солид можно объяснить математикой...но так то по сути, сквозь математику и теоремы доказательств можно объяснять все что угодно в нашем мире. Одно верно - с помощью математики мы можем доказать принципы солид и увидеть их сквозь призму математической точности.

Ладно, пофиг про рекламу своей группы, которую я уже почти забросил из-за лива с вк, еслм я скину видос напрямую, его больше людей посмотрят https://youtu.be/CmCEdVrZQAE

Полезный материал, спасибо большое!

Ещё бы что нибудь посмотреть про ioc di и dip

Ещё бы что нибудь посмотреть про ioc di и dip

про IOC у дяди Боба есть тут https://youtu.be/TMuno5RZNeE?t=3035

Вопрос: Есть метод у класса. Этот метод является запросом т.е. функция. Считается верным что данный метод должен только возвращать данные не изменяя состояния класса (инвариант реализации). Почему тогда все базовые структуры типа стек и прочие контейнеры имеют метод возвращающий элемент и при этом удаляя его в контейнере т.е. меняя состояние ?

Вопрос: Есть метод у класса. Этот метод является запросом т.е. функция. Считается верным что данный метод должен только возвращать данные не изменяя состояния класса (инвариант реализации). Почему тогда все базовые структуры типа стек и прочие контейнеры имеют метод возвращающий элемент и при этом удаляя его в контейнере т.е. меняя состояние ?

Потому что так работает классический стек?) Не очень cqs да

потому, что они создавались без учета cqs

опередил)

> Все эти шины - это реализация CQRS. Поправка, это один из вариантов реализации CQRS. > Сторонники CQRS утверждают, что команды не должны ничего возвращать. Это скорее про CQS, где все операции записи (методы) по хорошему должны быть void, но есть скажем pop у стэка. Он одновременно пишет и возвращает. Если тебе надо атомарно что-то такое сделать у тебя будут проблемы. В CQRS команды не должны отвечать за "запросы". То есть это нормально когда команда возвращает скажем идентификатор созданной сущности, но не нормально когда команда возвращает результат какой-то выборки из базы. codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/ - вот например мнение Грэга Янга на этот счет (а он типа главный апологет CQRS/ES). > Приведи простенький пример, если не сложно. любой кейс когда идентификатор извне команды нельзя получить, потому что формирование этого идентификатора требует какиз-то бизнес штук до которых ты не можешь добраться из-за шины.

Но я говорю про запрос, а не команду. Ну ок. Я представил себе аппарат с кока колой, я нажал кнопку и получил колу. Я сделал запрос и состояние аппарата изменилось. Может быть это нормально? Может так и должно быть?

нет. ты сделал запрос на панели. и дал туда монетку

это команда

а потом сделал запрос в лотке. и там получил бутылку

Тогда ещё вариант: ввел сумму в банкомате и нажал кнопку выдать. Запрос? Деньги автоматом выдаст и счёт изменит. Или я не так вижу, поправьте.

он сделает все операции. за транзакцию. изменит счет. положит деньги в лоток. Оно не возвращает деньги. Оно просто кладет в лоток. все одной командой.

из лотка может взять кто угодно :)

по большому счету

ребят, а вы видео смотрели, которое pinned message?

чувак умными словами вводит студентов в заблуждение, имхо)

я гляну попозже

чувак умными словами вводит студентов в заблуждение, имхо)

Почему в заблуждение?)

Я смотрел этот, правда пару месяцев назад

я досмотрю и сформулирую

ребят, а вы видео смотрели, которое pinned message?

смотрел когда-то и еще раз пересмотрел, интересно почему в заблуждение тоже)

Что я сам считаю про этот видос: так писать стоит, но не всегда. То есть во многих случаях реально заменить ифы на диспатчинг лучше (популярный пример реализации Maybe/Optional через два класса вместо одного с ифами внутри каждого метода). Вводит в заблуждение он потому имхо, что говорит, что писать нужно только так.

хух, досмотрел.... однажды мне один знакомый академик сказал, что суть вот этого всего - сохранение инвестиций т.е. рассматривать расширяемость и ре-использование стоит только с одной стороны - как можно меньше потерять при разработке и модификации софта но это палка о двух концах: предвидеть все случаи расширения невозможно, разработка универсальной программы требует бесконечных инвестиций

Что я сам считаю про этот видос: так писать стоит, но не всегда. То есть во многих случаях реально заменить ифы на диспатчинг лучше (популярный пример реализации Maybe/Optional через два класса вместо одного с ифами внутри каждого метода). Вводит в заблуждение он потому имхо, что говорит, что писать нужно только так.

получается любая книга о погромировании вводит в заблуждение

получается любая книга о погромировании вводит в заблуждение

большинство из них)

хух, досмотрел.... однажды мне один знакомый академик сказал, что суть вот этого всего - сохранение инвестиций т.е. рассматривать расширяемость и ре-использование стоит только с одной стороны - как можно меньше потерять при разработке и модификации софта но это палка о двух концах: предвидеть все случаи расширения невозможно, разработка универсальной программы требует бесконечных инвестиций

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

а солид никогда не дает перспектив тут и сразу, а только в долгосрочной перспективе

тут надо вспомнить hello-world в пару тыщ строк чтоб показать эффективность солида в долгосрочной перспективе ;)

тут надо вспомнить hello-world в пару тыщ строк чтоб показать эффективность солида в долгосрочной перспективе ;)

нет, hello world это ничето иное как hello world. говорять об абстрактных вещах и то, что в погоню за расширяемостью люди иной раз заходят в крайность

на то и дана золотая середина

на то и дана золотая середина

это и есть принцип сохранения инвестиций

соблюсти балланс

кто там одмин? забаньте плиз

кто там одмин? забаньте плиз

готово

т.е. математика математикой, но она должна быть применима к реальным задачам. А это вопрос целой отдельной дискуссии

каждый день любая тема о великом сводится к одному: рентабельности всего этого. И каждый день всё равно все рассуждают за идеальный мир, но вот глупый вопрос: а кто всё это использует в реальности?)

ну используют

каждый программист в той или иной мере

т.е. никто)

почему никто?

все используют

но не в полной мере

потому что Гёдель не велел)

не надо подменять понятия) рест апи тоже все используют) толку с этого не много

что значит "толку не много"? как раз толку с простых тупых вещей сколько угодно много

они работают, приносят деньги, а если их не трогать - то вообще нет никаких проблем

доказано деньгами, а не этой вашей математикой)

программы, которые работаю и приносят деньги, как раз чаще всего написано без оглядок на всякие солиды, мвц, опп, ресты и т.д. (нужное подставить) :)

в том то и речь.... и в этом первая причина, почему тот товарищ вводит людей в заблуждение

сложно различать кто с кем общается, зрение аж проседает

вторая причина - более глубокая и более мерзкая

изменение предметной области часто ломает солид само по себе

и код можно выбрасывать

пример: есть пол, мужской и женский

и тут суд автралии постановляет: пол - не корректное понятие, его вообще нельзя употреблять, выпиливайте

досвидания мой любимый код

еще есть несколько причин... из них: - читаемость кода в солиде часто страдает сильнее, чем у простого говнокода - лютая сложность проектирования "чтоб сразу по солиду" - фон-неймановская модель и ограничения современных компютеров нарушают солид - практически все языки программирования нарушают солид сами по себе