О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

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

Т.е. я вот не задумываюсь, почему я подхожу к задаче так или иначе, но опосля объяснение почти всегда сводится к простому – начинаю с самого понятного и/или ключевого компонента задачи, который могу сделать и далее по списку.

Если так подумать, выглядит это как wave function collapse по всей задаче разбитой на кусочки с backtracking в случае факапа (который у меня бывает часто)

которой там скорее всего нет.

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

Этот процесс «выжимки» из полной сети причинно-следственных связей некоего минимума, вмещающегося в символизированную модель процесса, подобен сжатию с потерями. И эти потери могут иметь интересные психологические манифестации. Например, дефицит детальности представления каузальных моделей собственного поведения приводит к появлению устойчивого феномена свободы воли. Выпадающие из модели каузальные связи выглядят как будто субъект ничем не обусловлен, но всё обуславливает (downward causation).

Или, например, дефицит «процессной интроспекции», или способности видеть (в той или иной детальности) себя как машину, выглядит как будто субъект схлопывается в точку: он как бы не имеет внутренней структуры.

И в этом контексте ООП — это тоже продукт «wave function collapse» (как ты сказал ниже) или проекция полной каузальной модели предметной области на некоторую языковую объяснительную схему, которую мы и называем ООП.

И вопрос о том «как ты программируешь» здесь нацелен на то, чтобы посмотреть, как много промежуточного когнитивного материала субъект может регистрировать. Ну и, соответственно, что из этого попадает у него в зону произвольной регуляции.

Если так подумать, выглядит это как wave function collapse по всей задаче разбитой на кусочки с backtracking в случае факапа (который у меня бывает часто)

Ты не мог бы сопоставить, насколько то, что ты здесь аппроксимируешь как wave function collapse, похоже на это.

у нас в компании его идеи ввели, увеличилось КПД почти в двое, и читабельность кода, и производительность программистов.

Подробнее с этого места и в примерах. А то всё это выглядит, как очередная секта со своим гуру.

В квотезы!

Тут между прочим человек, начал доказывать, что с ритуально чистым ооп трудозатраты снижаются в 2+ раза!

Это автоматом создаст FizzBuzz Enterprise Edition или чёрную дыру или вызовет сатану?

Я как-то сменил в таком классе тип id и это вызвало сотону.

То есть у тебя в результате есть regularHours1 и regularHours2 одна для бухгалтера вторая для HR.

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

Не возникает ситуации когда нам в рамках одной таски нужно поменять обе эти функции одновременно. По этому это не кейс для DRY.

Например, сменилась структура хранения часов: теперь вместо часов на каждый день по сотруднику пишется дата начала, дата окончания, количество за период. Теперь нам надо в пяти местах сделать почти идентичный исправления. Причём делать их будут 5 команд независимо друг от друга. Или в законе появился новый вид часов, который не сверхурочный, опять надо менять во всех 5 местах.

P.S. Для функций должны работать те же принципы устойчивости, что и для компонентов. Найти, где используется функция не сложнее, чем найти, где используется класс (как правило, проще, функция не может внезапно появиться из фабрики).

P.P.S. Иллюстрация к принципу закрытости/открытости - это как раз то, от чего я страдаю в 1С.

Представьте, что у нас есть финансовая сводка. Содержимое
страницы прокручивается, и отрицательные значения выводятся
красным цветом.

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

Очевидно, что для этого придется написать новый код. Но как много
старого кода придется изменить

И далее схема «правильной архитектуры». Если в колонтитуле нужна информация, которой не было в предыдущем представлении отчёта, то новое поле придётся добавить почти в каждый класс от базы данных до печатного презентатора включительно (в экранный тоже может быть придётся для унификации интерфейса презентатора финансового отчёта).

В то время, как в отчёте без SRP печатная форма просто вытащит нужные данные из БД и их не придётся тащить через, как минимум, 5 границ классов.

В малых дозах полезно для сосудов.

Вот, за подобное меня с первой работы уволили,

Пили пост.

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

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

Например, сменилась структура хранения часов: теперь вместо часов на каждый день по сотруднику пишется дата начала, дата окончания, количество за период. Теперь нам надо в пяти местах сделать почти идентичный исправления. Причём делать их будут 5 команд независимо друг от друга.

Если база меняется то вероятно актор это админ, он ставит таску и в рамках этой таски ты все это делаешь, это не 5 независимых команд. Это одна таска от админа. Тут речь не о том что каждый в команде работает над своим кусочком системы, а о том как расходятся по системе изменения спровоцированные задачей от актора. Они должны расходиться так то бы не мешать другим акторам. В случае с форматом часов проблема не в том что их нужно поменять в 5 функциях, а в том что одновременно с этим бухгалтер или HR могут поставить таску на изменение формулы расчета. И если админ будет каждый день менять формат часов это эти изменения в любом случае придется как то изолировать, прятать за интерфейсом например, иначе он парализует работу с тасками от всех остальных.

Или в законе появился новый вид часов, который не сверхурочный, опять надо менять во всех 5 местах.

Нет, у тебя есть акторы, каждый из них поставит свою таску, и по этим таскам будут внесены изменения в этии 5 методов. 1 таска - 1 метод.

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

Кстати с сторонними библиотеками ситуация такая же, каждая библиотека подключаемая в проект это +1 актор.

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

просто вытащит нужные данные из БД и их не придётся тащить через, как минимум, 5 границ классов.

Что значит просто вытащит нужные данные из БД? То есть у нас была база, был модуль который собирает из базы данные и подготавливает их для вьюшек, и были сами вьюшки которые их отображают. Нам понадобились новые данные и мы прямо из вьюхи лезем в базу?

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

Ну да. Одну и ту же задачу реализовываем с нуля пять раз. Я в 1С перед тем как сделать любой отчёт сначала делаю поиск по всей базе, вдруг нужный алгоритм уже готов (и протестирован программистами 1С). Копипаста быстрее написания.

Это одна таска от админа.

Ты только что написал, что у нас даже не копипаста, а 5 разных версий. Кто будет эти 5 версий обновлять по таске от админа?

Нет, у тебя есть акторы, каждый из них поставит свою таску, и по этим таскам будут внесены изменения в этии 5 методов. 1 таска - 1 метод.

И из одного внешнего факта получаем 5 задач. И пять разных человек делают одно и то же в одной организации. Это не бред? Не нарушение DRY?

Если тебе как программисту явно скажут что вот это нужно считать по формуле из закона, покажут где ее брать и как следить за обновлениями

А если в заявке указано, что формула из закона, но не указано «как следить за обновлениями», то обновлять не надо, пока пользователь не попросит?

Что значит просто вытащит нужные данные из БД? То есть у нас была база, был модуль который собирает из базы данные и подгатавливает их для вьюшек, и были сами вьюшки которые их отображают. Нам понадобились новые данные и мы прямо из вьюхи лезем в базу?

Да. В 1С 7.7 так было. Можно было прямо в макете печатной формы написать что-то вроде [Справочник.Пользователи.НайтиПоЭлементу(ТекущийПользователь()).ФизическоеЛицо]. и получить полное ФИО текущего пользователя для колонтитула из БД. А в 1С 8 теперь надо прописать соответствующее поле в структурах на границе каждого класса. Работы стало в 10 раз больше (место внесения изменений ещё и найти не сразу получается).

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

А ты читал «Майкл Газзанига: Кто за главного? Свобода воли с точки зрения нейробиологии» ?

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

Понятно, что людям не нравится, когда ты их хоть как-то оцениваешь, не нравится, когда говоришь «от себя». Людям, вообще, много чего не нравится. Если пытаться действовать в полностью «позитивном» ключе, то вообще ничего сделать не сможешь.

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

Все зависит проектировщика на сколько вкусным будет это ваше ООП в проекте и на сколько его тяжело или легко будет саппортить потом.

Вот с этим в массе - беда и, отчасти, про это ОП. Кодерки начитаются книжок умных и лепят кал. И с каким кодом не приходится работать - кроме кала ничего не видно, а про б-жестевнную архитектуру слышно только на формуах вот в таком вот ключе. Она где-то конечно есть, но это как поиски Священного Грааля. ООП от Егора на словах красиво, а на деле «иммутабельность» => копирование структур => тормоза. Жду историю успеха короче.

А ты читал «Майкл Газзанига: Кто за главного? Свобода воли с точки зрения нейробиологии» ?

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

А твои действия в случае с русскоязычным языком программирования были эффективны?

Ты излишне углубляешься в детали)) Я, в общем-то, о том, что нельзя рассказывать людям, что их субъективная реальность на самом деле очень далека от реальности, и не вызвать при этом раздражения со всеми вытекающими. Тут начинает компенсаторный рефлекс работать, который удерживает «картину мира» в целостности при наличии её критики.

Кстати, «мягкие методы» обхода компенсаторного рефлекса существуют, и они могут быть весьма и весьма незаметны даже для специалистов. И я вполне их применяю наравне с такими вот «жесткими» методами. Но не тут.

Но не тут.

ЛОР. Безжалостно шатаем манямирки с 1998 года.

Надо бы уже бережно шатать, наверное. Не?)

а на деле «иммутабельность» => копирование структур => тормоза.

Я в другой теме тут писал про это. Легковесность классических объектов кажущаяся. Как только динамический объект начинает разделяться между потоками, возникают вопросы синхронизации, и оверхед персистентных/функциональных структур данных — нормальная такая плата за wait-free доступ к снимкам состояний объектов. Можно и без них (структур), но будут блокировки, что, в итоге, еще большие тормоза.

Самое главное, как только мы вылезаем из RAM и у нас уже нет связного адресного пространства, персистентная (в смысле, версионированная) модель данных становится вполне себе естественной с точки зрения физики.

«иммутабельность» => копирование структур => тормоза

Во-первых, копировать все полностью не нужно, есть structural sharing. Во-вторых, как выше уже заметили, ты можешь потерять больше на одних только блокировках. Не говоря уже об отладке.

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

Гм… у меня это раздражения не вызывает. Хотя это, может быть, потому что я квантовую физику изучал до философии.

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

Хрен с ней со свободой воли) Там другое интересное было, он нейробиолог и работал с людьми с разрезанным мозолистым телом, раньше так эпилепсию лечили. То есть у человека 2 полушария мозга не связанные между собою. С ними можно общаться по отдельности через левую руку и левые половины поля зрения глаз с правым полушарием и обычным разговором с левым полушарием.

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

Ну, справедливости ради, есть еще акторная модель, которая позиционируется именно как возможность гонять легковесные несинхронизированные объекты в конкурентной среде. Но там есть свои заморочки, связанные с message passing. Далеко не всё будет легко выразить в акторной модели, даже синхронной, и далеко не всегда разделяемое состояние можно свести к нулю. БД обычно всё равно есть, да еще и распределенная какая-нибудь, и вот она будет этими самыми «иммутабельными объектами».

А, про эти эксперименты я в курсе. Там, кроме мозолистого тела есть еще фиссуры, так что разрезания одного только мозолистого тела еще мало для полного split-brain. Кроме того, много синхронизации может идти через ствол мозга и, самое главное, через «след поведения», --- сенсорную обратную связь, так как оба полушария таки продолжают быть «подсоединены» к одному и тому же телу. Т.е. не стоит удивляться, что левополушарная личность хорошо предсказываетет поведение правополушарной линости и наоборот. Иначе такой человек даже ходить не мог бы.

Да, тут много интересного. Единственное, что я за нейронауками сейчас не сильно слежу. Я с этого начинал в начале нулевых, когда интернет у меня был еще модемный, а из доступного — сайты медицинских университетов. Которые, в плане «цифровизации» были тогда просто офигенны. Я сейчас «когнитивист» и работаю с «когнитивными кодами» — это то, как нейронные коды наблюдаются в субъективном отчете (переживаниях).

Ну да. Одну и ту же задачу реализовываем с нуля пять раз. Я в 1С перед тем как сделать любой отчёт сначала делаю поиск по всей базе, вдруг нужный алгоритм уже готов (и протестирован программистами 1С). Копипаста быстрее написания.

Так это не одна и та же задача, там разные алгоритмы, разные формулы расчета.

Ты только что написал, что у нас даже не копипаста, а 5 разных версий. Кто будет эти 5 версий обновлять по таске от админа?

Команда программистов работает со всем проектов в целом.

И из одного внешнего факта получаем 5 задач. И пять разных человек делают одно и то же в одной организации. Это не бред? Не нарушение DRY?

Нет это не нарушает, в рамках одной таски ты меняешь только один метод, по этому это не имеет отношения к DRY.

А если в заявке указано, что формула из закона, но не указано «как следить за обновлениями», то обновлять не надо, пока пользователь не попросит?

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

Да. В 1С 7.7 так было. Можно было прямо в макете печатной формы написать что-то вроде [Справочник.Пользователи.НайтиПоЭлементу(ТекущийПользователь()).ФизическоеЛицо]. и получить полное ФИО текущего пользователя для колонтитула из БД. А в 1С 8 теперь надо прописать соответствующее поле в структурах на границе каждого класса. Работы стало в 10 раз больше (место внесения изменений ещё и найти не сразу получается).

Я не очень понимаю че у тебя там за ситуация. Мартин предлагает сделать модуль для подготовки данных, в нем будет все общение с базой, может быть какие то доп расчеты. А вьюшки будут получать данные из этого модуля, а не из базы. В случае добавления новой вьюхи ты берешь уже готовые данные из модуля расчетов. Тебе даже не нужно думать о том как этот модуль собирает данные с базы. Добавление новой вьюхи требует минимум усилий.

В случае если у тебя каждая вьюха требует уникальных данных то такая схема будет не практична, нужно что то другое придумать.

Ты зачем то выдергиваешь примеры из контекста и пытаешься придумать в каких условиях этот пример не работает. Это не имеет смысла. Там нету ни одного примера который будет работать в 100% случаев, привет статья про Маркуса и Бориса. Примеры нужны для того что бы показать какую то конкретную проблему и как она решается в рамках текущей темы. Все. Это не является универсальными рецептами на все случаи жизни. Но понимая проблему можно выбрать для решения нужный инструмент.

Т.е. не стоит удивляться, что левополушарная личность хорошо предсказываетет поведение правополушарной линости и наоборот.

В том то и дело что там левое полушарие лажает со страшной силой но на серьезных щах и человек этого даже не замечает.

Правому полушарию мозга показывают картинку с бананом, испытуемого просят что нибудь нарисовать левой рукой, он рисует банан, у него спрашивают: «почему вы нарисовали банан?» левое полушарие отвечает: «Его удобнее всего нарисовать»

Интроспекция не имеющая ничего общего с реальностью. Просто фантазии. Вот такие там эксперименты.

Гм… у меня это раздражения не вызывает.

К тебе просто нужен «особый подход», и трудоемкость будет несколько выше. Я и профессиональных философов доводил «тупыми вопросами» (вопросами, которые очевидно идут вразрез с реальностью, данной им непосредственно в ощущениях).

Но и твою реальность можно «жестко шатнуть», так что ты не расслабляйся))

Есть хороший фильм — «Изобретение лжи», который в игровой форме показывает, как в нашей жизни много различной лжи и на сколько важную роль она играет в том, что мы привыкли называть реальностью. (в остальном фильм «так себе»)

И если иметь возможность «визуализировать паутину лжи» ( TDrive, это к вопросу «зачем оно всё может быть нужно»), которая конституирует субъективную реальность человека, можно вызвать у него эпичный персистирующий баттхерт (потроллить, то есть). Только это совсем не интересно, если это обычный человек. А если необычный, то может оказаться и небезопасно, гы, так что нет :)

Вот, например, про квантовых физиков. Почему квантовые физики в массе своей отвергают возражение супердетерминизма к уравнениям Белла? Потому что это возражение противоречит их непосредственно данной в ощущениях реальности? Отказываются жить в супердетерминированном мире? Выводить «свободу воли» из квантового индетерминизма, существующего в первую очередь из-за того, что физики изначально отвергают супердетерминизм? Мюнхгаузен.жпг

И такого полным-полно. У нас нет ничего, кроме иллюзий. Которые не совсем иллюзии, а аппроксимации (если по-нашему). Но не суть. И вопрос про то «как ты программируешь» это вопрос о том, на сколько такой программист может «переключать реальности» в своей голове. Это требуется для решения некоторых задач. Так что ты можешь даже считать это вопросом на собеседовании :)

Так это не одна и та же задача, там разные алгоритмы, разные формулы расчета.

Изначально одинаковый. Но ты пишешь, что надо делать копии. Так как меняться они (потенциально) могут независимо. Напоминаю:

Прочитал, да regularHours нужно скопировать, она не является случаем для DRY.

Нет это не нарушает, в рамках одной таски ты меняешь только один метод, по этому это не имеет отношения к DRY.

Так я и пишу, что у нас вместо одной таски «изменить расчёт сверхурочных по ФЗ 123 на алгоритм из ФЗ 234» получаем 5 независимых таск, которые ещё и выполняться могут разными людьми. В лучшем случае, после первого решения они найдут и скопипастят, в худшем сделают всё заново.

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

Ясно. У меня обычно почти все формулы из закона, но уведомляют или бухгалтера или юристы.

Я не очень понимаю че у тебя там за ситуация. Мартин предлагает сделать модуль для подготовки данных, в нем будет все общение с базой, может быть какие то доп расчеты. А вьюшки будут получать данные из этого модуля, а не из базы. В случае добавления новой вьюхи ты берешь уже готовые данные из модуля расчетов. Тебе даже не нужно думать о том как этот модуль собирает данные с базы. Добавление новой вьюхи требует минимум усилий.

Вот и возвращаемся к тому, что ты писал: «ООП нужно уметь использовать правильно, так что бы оно упрощало работу а не усложняло». И выдаёшь книгу, действуя по которой, разработчики 1С повысили трудоёмкость внесения любого изменения от 2 до 10 раз.

Добавление новой вьюхи требует минимум усилий.

Добавление новой вьюхи всегда требует минимум усилий, так как можно скопировать существующую и внести нужные изменения. Код, получающий данные, неизменен, берёт ли он данные из базы или из презентатора. Но вот если в презентаторе данных недостаточно, то получаем необходимые лишние действия.

Ты зачем то выдергиваешь примеры из контекста и пытаешься придумать в каких условиях этот пример не работает.

Я разгребаю последствия после тех, кто начитался таких книжек. Поэтому меня интересует, как «ООП нужно уметь использовать правильно, так что бы оно упрощало работу а не усложняло».

Вот и возвращаемся к тому, что ты писал: «ООП нужно уметь использовать правильно, так что бы оно упрощало работу а не усложняло». И выдаёшь книгу, действуя по которой, разработчики 1С повысили трудоёмкость внесения любого изменения от 2 до 10 раз.

В книге все примеры о том как упростить жизнь, каким образом это приводит к усложнению?))

Добавление новой вьюхи всегда требует минимум усилий, так как можно скопировать существующую и внести нужные изменения. Код, получающий данные, неизменен, берёт ли он данные из базы или из презентатора. Но вот если в презентаторе данных недостаточно, то получаем необходимые лишние действия.

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

Я разгребаю последствия после тех, кто начитался таких книжек.

Новички в программировании любят экспериментировать, могу только по сочувствовать, книжка в этом не виновата.

Просто фантазии. Вот такие там эксперименты.

Ок, понятно, о чем ты)

Я про эти вещи, конечно же, в курсе. И это всё можно обсуждать, но есть концептуальная проблема, которая такому обсуждению очень сильно препятствует. Дело в том, что наш концептуальный язык очень сильно дуалистичен (в смысле дуализма свойств из философии разума). Он насквозь пронизан «позицией от первого лица», возникновение которой в логических рассуждениях быстро приводит к или к различного рода логическим парадоксам, или просто к бесконечному хождению по кругу типа Проблемы Гомункулюса. Которую участники не видят в упор, даже если формально о ней осведомлены. Как половинки мозга в упор не видят того, что же именно происходит внутри соседа, хотя и могут иногда догадываться (ходить-то такой человек может).

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

Тут, кстати, есть еще один похожий вопрос продвинутым программистам. «Напиши мне объект, который видит красный цвет».

Я про эти вещи, конечно же, в курсе. И это всё можно обсуждать, но есть концептуальная проблема, которая такому обсуждению очень сильно препятствует.

Ну ок.

Тут, кстати, есть еще один похожий вопрос продвинутым программистам. «Напиши мне объект, который видит красный цвет».

https://youtu.be/UoKlKx-3FcA

Во-первых, копировать все полностью не нужно, есть structural sharing.

Где такое есть?

Это точно мне вопрос?)

https://youtu.be/UoKlKx-3FcA

Да, это то, как мы втроем тут звучим для остальной части аудитории))

Легковесность классических объектов кажущаяся. Как только динамический объект начинает разделяться между потоками, возникают вопросы синхронизации, и оверхед персистентных/функциональных структур данных — нормальная такая плата за wait-free доступ к снимкам состояний объектов.

Так это половые проблемы тех, кто шарит объекты между тредами, нет?

Нет. Хз, как так вышло:)

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

В ней, например, широковещательные рассылки хорошо работают.

Широковащательные рассылки и фин/банко/бухошлак, который является ЦА жаба ооп, находятся в маленько разных вселенных.

Ладно, скажу менее наукообразно. Вот есть задачи, типа баз данных, в которых есть разделяемое состояние, к которому имеется конкурентный внешний доступ. То, что ты говоришь, это то же самое, что такая база данных не может быть объектной.

Godot

А что с ним не так? Он весит 74 мб в виде редактора, а исполняемая часть 11 мб или около того:

du -h /bin/godot
74M     /bin/godot

В книге все примеры о том как упростить жизнь

Вот я их с тобой и разбираю (уже второй). Для меня они выглядят резким усложнением.

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

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

Новички в программировании любят экспериментировать, могу только по сочувствовать, книжка в этом не виновата.

Пока ты поддерживаешь изменения, внесённые на основании книги (типа отделения печатной формы документа от данных документа или отчёта от БД, дублирования одинаковых функций в разных подсистемах).

Как это бывает, если ты заглядываешь в бездну, и бездна в ответ заглядывает в тебя

Концовка неверная. Поправлю. На самом деле Дима увидел в бездне четвёртый уровень, в котором сама бездна, несмотря на всю её колмогоровскую сложность, схлопнулась в три кнопки. На первую нажмёшь - получишь денег сколько захочешь, на вторую нажмёшь - любая баба даст, на третью нажмёшь - вернёшься обратно на первый уровень к даннингам-крюгерам. Подумал Дима, подумал, да и нажал на третью кнопку.

Или можно более реальный вариант. Смотрел Дима в бездну, смотрел, а потом понял понял, что кушать хочет. Пошёл к Васе с Петей торговать бездной по кусочкам. А они ему говорят: не, друг, ты когда про дианетику задвигал - забористее было. И когда бизнес-тренером был - тоже было неплохо. А в этот раз денег не дадим. Ну вот есть у нас просроченный собачий корм, хочешь? - А давайте.

Вот я их с тобой и разбираю (уже второй). Для меня они выглядят резким усложнением.

Потому что нужно начинать с того какую проблему они решают.

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

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

Пока ты поддерживаешь изменения, внесённые на основании книги

Я их поддерживаю для решения конкретных проблем, а ты воспринимаешь их как бест практис которыми они не являются.

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

Вот есть задачи, типа баз данных, в которых есть разделяемое состояние, к которому имеется конкурентный внешний доступ.

Игорь? Какие еще у этого кейсы?

Я и профессиональных философов доводил «тупыми вопросами» (вопросами, которые очевидно идут вразрез с реальностью, данной им непосредственно в ощущениях).

Солипсистов получалось?

Но и твою реальность можно «жестко шатнуть», так что ты не расслабляйся))

Её шатнуть несложно, но бесполезно. Существенное для меня к реальности не привязано, а то, что видимая реальность является лишь иллюзией поверх почти пустого пространства, я и так осознаю.

Почему квантовые физики в массе своей отвергают возражение супердетерминизма к уравнениям Белла? Потому что это возражение противоречит их непосредственно данной в ощущениях реальности? Отказываются жить в супердетерминированном мире?

Квантовые физики тоже люди. И ничто человеческое им не чуждо.

Которые не совсем иллюзии, а аппроксимации (если по-нашему).

Именно так. Трактовка сигналов пришедших из окружающего мира.

И вопрос про то «как ты программируешь» это вопрос о том, на сколько такой программист может «переключать реальности» в своей голове.

Неосторожным вопросом можно разрушить рамки морали человека. Научный подход создал из традиционного ислама радикальный. И возможно нам очень повезло, что аналогичное преобразование (пока) не произошло с буддизмом. Не зря есть табу на некоторые вопросы и понятие окон Овертона. Как нельзя что-то «развидеть», так тем более нельзя «размыслить».

зависит от того на сколько разные данные требуют разные вьюхи, почему в этом случае ты не вспоминаешь про DRY?

Верно. Общий код после создания второй вьюхи становится отдельной функцией. Но не полудюжиной классов, которые нельзя обойти.

Я их поддерживаю для решения конкретных проблем, а ты воспринимаешь их как бест практис которыми они не являются.

Гм… «ООП нужно уметь использовать правильно, так что бы оно упрощало работу а не усложняло» подразумевает, что бест практис таки существуют. Тогда ты мне дал неправильную книжку.

если бы у вас было ФП ты бы вообще повесился

Не думаю. Я писал на Haskell. Там для любого изменения почти всегда ровно одна точка. И мода на многослойную изоляцию БД от отчётов туда не дошла. И даже при изоляции то, что в ООП выглядит как

   данные = презентаторПечати.получитьДанные();

в ФП выглядит как

   данные = фильтроватьДляПечати . сформироватьОтчет . получитьИзБД

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

подразумевает, что бест практис таки существуют.

Нет не подразумевает.

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

Если тебе не нравятся решения которые предлагает книга то придумывай свои, какие проблемы то?

Но тебе стоит осознать что до тех пор пока ты не научишься нормально программировать люди которые будут поддерживать твой код будут точно так же хуесосить тебя за твои неудачные эксперименты. Вот как у тебя сейчас бомбит от кода прошлых прогеров так же и у тех кто будет поддерживать твой код будет бомбить. Но это конечно же не точно, от очередного эксперимента тебя ни кто не остановит) вдруг у тебя получится лучше чем у остальных, почему бы и нет…

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

Эта часть приводит к логическому выводу отказаться от ООП где возможно.

Я объяснил для чего нужно все о чем написано в книге - для выявления проблем приводящих к лишним трудозатратам и их решения.

И для создания этих самых проблем, чтобы было что выявлять. И на решение тоже потребовать дополнительные трудозатраты.

В книге есть и полезные мысли (про устойчивость и про зависимость от интерфейса, а не реализации), но к ООП они отношения не имеют.

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

На github’е лежит. Критики нет :-). Дополнительные функции после меня добавляли.

Эта часть приводит к логическому выводу отказаться от ООП где возможно.

Почему ты думаешь что меня волнует будешь ты юзать ООП или нет?)

И для создания этих самых проблем, чтобы было что выявлять. И на решение тоже потребовать дополнительные трудозатраты.

Нет проблемы объективны, они ни куда не денутся даже если ты будешь на ассемблере писать.

В книге есть и полезные мысли (про устойчивость и про зависимость от интерфейса, а не реализации), но к ООП они отношения не имеют.

Клятое ООП, чужие заслуги присваивает себе.

На github’е лежит. Критики нет :-). Дополнительные функции после меня добавляли.

Ну все пиши книгу о том как этого достигнуть.

Почему ты думаешь что меня волнует будешь ты юзать ООП или нет?)

Мы в теме про ООП. Ты защищал ООП. Так как обсуждение публичное, то можно предположить, что тебя волнует чтобы люди использовали ООП, также как ТСа волнует, чтобы не использовали.

Нет проблемы объективны, они ни куда не денутся даже если ты будешь на ассемблере писать.

Требования SOLID к ассемблеру сложно применить.

Клятое ООП, чужие заслуги присваивает себе.

???

Я к тому, что книга не плоха, но как «ООП использовать правильно, так что бы оно упрощало работу а не усложняло» не описывает.

Ну все пиши книгу о том как этого достигнуть.

Сразу после того, как допишу свой язык программирования.

Мы в теме про ООП. Ты защищал ООП. Так как обсуждение публичное, то можно предположить, что тебя волнует чтобы люди использовали ООП, также как ТСа волнует, чтобы не использовали.

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

Требования SOLID к ассемблеру сложно применить.

Я тебе о проблемах с поддержкой кода, а ты о том как применить принципы) Улавливаешь?)

Я тебе о проблемах с поддержкой кода, а ты о том как применить принципы) Улавливаешь?)

Твой тезис был, что переход на ООП решает проблемы с поддержкой кода. Мой — что писанины больше, а проблемы остаются те же. И любой метод решения проблем с поддержкой при ООП работает и без ООП даже лучше.