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

Здравствуйте, ksandro, Вы писали:

K>Вообще ООП появился именно как механизм для борьбы со сложностью.

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

K>Но потом выяснилось, что все не так просто.

K>Во первых объекты не всегда легко классифицировать.

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

K>Во вторых, большое желание сделать все максимально абстрактно,

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

K>Чтобы бороться с этой проблемой придумали паттерны проектирования.

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

> Появилась рекомендация использовать наследование по минимуму.

Не по минимуму, а по назначению. Есть у тебя отношения вида is-a, subtype, бери, наследуйся, сколько влезет. Есть у тебя модули — расширяй, сколько влезет. Главное не смешивать два этих кейса.

K>Что касается модулей, то это не новая идея. Мне кажется она более старая чем ООП, хотя я точно не знаю. У меня есть большие сомнения, что это что-то поменяет. В любом слачае все дело в кривых руках, от которых никак не избавиться.

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

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

vaa>>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.

K>Честно говоря, тут вообще не понял о чем ты. То вроде говорил опарадигмах и концепциях типа ООП и модулей. А тут резко перешел на базы данных, что уже касается деталей реализации. Если для твоих задачь подходит база данных, тебе никто не запрещает ее использовать. Но базы данных подходят далеко не для всех задач, иногда базы просто нет, иногда производительность недостаточна, а иногда база просто нафиг не нужна. К ООП это вообще мало отношения имеет.

Каждая из парадигм так или иначе работает со временем и состоянием. Теоретически, они все об одном и том же. Штука в том, что всеобемлющей парадигмы не существует — человеку приходится абстрагироваться, классифицировать что бы работать с этим всеобъемлющим.
Потому семейства некоторых типовых задач естественным путём оформились в парадигмы.
Взаимодействие, поведение — ООП
Вычисления — ФП
Поток событий — реактивное
Многозадачность — модель актеров

Согласен. Я считаю, что ООП не нужен. Если брать Java, как пример, то нужны интерфейсы, наследование интерфейсов, реализация интерфейсов, и всё. Наследование классов не нужно.

Про базу не понял. Звучит сомнительно.

Здравствуйте, vaa, Вы писали:

vaa>И еще храните состояние в базе, если есть база.

Я как-то писал про нечто подобное — Катастрофа ООП

Автор: velkin
Дата: 21.10.21

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, vaa, Вы писали:

vaa>>ООП решения сложны для понимания.

НС>Любые?

Да

vaa>>Каждый раз для внесения изменений нужно заново пройти квест наследования,

НС>Абсолютно каждый раз?
Да

vaa>>Единственно верное решение сложной задачи без усложения — модули.

НС>ООП противоречит модулям?
Модуль — набор функций. Да, ООП решение это сложная лапша интерфейсов и реализаций.


vaa>>И еще храните состояние в базе, если есть база.

НС>Ага, а еще используйте протокол HTTP для работы в интернете.

не вдупляю.

vaa>>не нужно без необходимости использовать ООП.

НС>Я тебе больше скажу, не нужно без необходимости использовать Х, где Х — любая технология.
согласен.

vaa>>например очередь. зачем?

НС>Что зачем?

см. ниже.

vaa>>если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>>и в другом потоке доставай сущности по айдихи в транзакции, обработай и удали из таблицы.

НС>Для чего все это?

НС>Резюме: ты чего сказать то хотел?

что хотел, то и сказал.

Здравствуйте, vaa, Вы писали:

vaa>ООП решения сложны для понимания.
vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,
vaa>чтобы понять где находится суть действия над данными.
vaa>Единственно верное решение сложной задачи без усложения — модули.
Да нет серебряной пули — нет!!! Не нужно вообще для всего применять ООП! Ибо да, для крайне многих задач это неоправданное усложнение на ровном месте. Однако встречается задачи, для которых применение ООП — как раз способ борьбы со сложностью и способ уменьшения кода. Думать всегда нужно о границах применимости того или иного инструмента!

vaa>>>И еще храните состояние в базе, если есть база.
vaa>>>не нужно без необходимости использовать ООП.
G>>Убрать все нелокальные переменные и на каждое изменнение писать в БД ?
vaa>так точно.

vaa>>>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>>>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
G>>Вам не кажется что это усложнение на пустом песте?
vaa>по ситуации

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

Здравствуйте, vaa, Вы писали:

vaa>ООП решения сложны для понимания.
vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,
vaa>чтобы понять где находится суть действия над данными.
vaa>Единственно верное решение сложной задачи без усложения — модули.

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

Но потом выяснилось, что все не так просто.

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

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

Что касается модулей, то это не новая идея. Мне кажется она более старая чем ООП, хотя я точно не знаю. У меня есть большие сомнения, что это что-то поменяет. В любом слачае все дело в кривых руках, от которых никак не избавиться.


vaa>И еще храните состояние в базе, если есть база.
vaa>не нужно без необходимости использовать ООП.
vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.

Честно говоря, тут вообще не понял о чем ты. То вроде говорил опарадигмах и концепциях типа ООП и модулей. А тут резко перешел на базы данных, что уже касается деталей реализации. Если для твоих задачь подходит база данных, тебе никто не запрещает ее использовать. Но базы данных подходят далеко не для всех задач, иногда базы просто нет, иногда производительность недостаточна, а иногда база просто нафиг не нужна. К ООП это вообще мало отношения имеет.

Здравствуйте, vaa, Вы писали:

vaa>ООП решения сложны для понимания.
vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,

Это просто плохо написанный код в ООП-стиле. Я и на процедурах такой код видел, надцать вложений, логика размазана между всеми. Да мне кажется, в любой парадигме так можно запутать.

В хорошо написанном ООП-коде заранее понятно, на каком уровне искать. Это, кагбе, критерий правильности декомпозиции (которая и определяет «хорошесть» ООП-решения).

Здравствуйте, vaa, Вы писали:

vaa>ООП решения сложны для понимания.

Любые?

vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,

Абсолютно каждый раз?

vaa>Единственно верное решение сложной задачи без усложения — модули.

ООП противоречит модулям?

vaa>И еще храните состояние в базе, если есть база.

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

vaa>не нужно без необходимости использовать ООП.

Я тебе больше скажу, не нужно без необходимости использовать Х, где Х — любая технология.

vaa>например очередь. зачем?

Что зачем?

vaa>если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>и в другом потоке доставай сущности по айдихи в транзакции, обработай и удали из таблицы.

Для чего все это?

Резюме: ты чего сказать то хотел?

Здравствуйте, vaa, Вы писали:

vaa>ООП решения сложны для понимания.

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

vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,

Не надо

vaa>чтобы понять где находится суть действия над данными.

Потому, что у вас не ооп, а просто классы

vaa>Единственно верное решение сложной задачи без усложения — модули.

Правильно. В ооп все вертится как ни странно, вокруг модулей. Класс — модуль. Экземпляр — модуль. Итого — остается сорганизовать взаимодействие модулей.

vaa>И еще храните состояние в базе, если есть база.

что база, что её отсутствие, никакого отношения к ооп не имеет.

vaa>не нужно без необходимости использовать ООП.

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

vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.

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

Здравствуйте, vaa, Вы писали:

НС>>ООП противоречит модулям?
vaa>Модуль — набор функций. Да, ООП решение это сложная лапша интерфейсов и реализаций.

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

Здравствуйте, vaa, Вы писали:

vaa>ООП решения сложны для понимания.
vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,
vaa>чтобы понять где находится суть действия над данными.
Тогда видимо не ООП, а наследование реализации.


vaa>Единственно верное решение сложной задачи без усложения — модули.
Тут без примера крайне сложно сказать.

vaa>И еще храните состояние в базе, если есть база.
vaa>не нужно без необходимости использовать ООП.
Убрать все нелокальные переменные и на каждое изменнение писать в БД ?

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

Здравствуйте, vaa, Вы писали:

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

Независимо от того как вы попали в данное состояние, дальнейшее движение из него должно быть оптимальным.

А ООП, ФП, ПП и прочие П — фигня.

Здравствуйте, Pauel, Вы писали:

P>Здравствуйте, AWSVladimir, Вы писали:

P>>>А наследник будет мутабл. Гыгы. Получаем тот же приплызд, что и с наследованием реализации

AWS>>Не не, котов (интерфейсы) нужно варить в отдельной кастрюле от собак (объекты)

P>Надо то надо, только с интерфейсами все ровно то же, что и с классами. Причина в том, что интерфейс подразумевает вполне конкретную сементику — интерфейс без семантики никого не интересует. А проблема здесь такая, что никто не мешает унаследовать, скажем, иммутабл интерфейс и добавить мутабл методы или наоборот, т.е. подменить семантику.
P> метод add(item) должен добавить ровно один, и в конец списка, например. Если мы отнаследуемся, и переопределим этот add, то получим ровно то же, что и с наследованием реализации. Можно смеяться, но так действительно бывает, например, в целях оптимизации добавили, а потом приходится с этим жить.
P>Или так — построили иерархию интерфейсов, а потом взяли добавили в базовый интерфейс опциональный метод который ломает всё подряд.

P>С классами все ровно то же, только есть дополнительная проблема, т.к. класс инкапсулирует детали реализации. И если мы наследуемся налево-направо мы тем самым ломаем эту инкапсуляцию.
Да эт понятно.
Если начинает один, ведет второй, потом передают проект двоим.
Если так ведутся проекты, без архитектуры, то такой бардак не только в классах и интерфейсах, но и в базе, API, файловых хранилищах.
Но это же бардак от того что нет главного архитектора (или если он положил болт на свое детище)

Здравствуйте, Pauel, Вы писали:

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

Это даже не проблема, это свойство окружающего мира.

НС>>В дотнете — как минимум еще в атрибутах. С контролем в виде доптулов, например в виде аналайзеров.
P>Это и есть чудовищное усложнение.

А чудовищно сложная задача просто вряд ли решаема. Вся эволюция серьезных статических ЯП как раз двигается в сторону смещения границы контроля семантики все дальше. Сейчас в мейнтрим проникают NRT, дойдет когда нибудь дело и до r/o семантики.
А в некоторых случаях наоборот, Java попыталась контролировать компилятором исключения, но они оказались черезчур динамическими чтобы это было полезно на практике, в результате фичу по сути аккуратно замели под коврик. Не исключено что и с r/o получится тоже самое.

P> Например, на конкретный кейс частенько не хватает фичи в анализаторе. Что делать?5

Писать анализатор Если кейс удачный окажется — есть шанс получить его со временем в виде first class citizen в языках.

Здравствуйте, vsb, Вы писали:

vsb>Согласен. Я считаю, что ООП не нужен. Если брать Java, как пример, то нужны интерфейсы, наследование интерфейсов, реализация интерфейсов, и всё.

У тебя здесь противоречие — ООП не нужно, вместо него нужно ООП, и всё
ООП это не про три, четыре, пять, N китов. Для ооп не нужны ни классы, ни наследование, хоть какое.

Вот например, наследование интерфейсов — определяем иммутабл интерфейс. Всё ж круто?
И пронаследуем его. Всё ж класнно, можно наследовать интрерфейсы.
А наследник будет мутабл. Гыгы. Получаем тот же приплызд, что и с наследованием реализации

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

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

Для сравнения, ФП это управления сложностью вычислений. Здесь нам нужны по большому счету только функции. Всё остальное нужно исключительно для экономики проекта.

Здравствуйте, vaa, Вы писали:

vaa>>>ООП решения сложны для понимания.
НС>>Любые?
vaa>Да

Сможешь доказать?

vaa>>>Каждый раз для внесения изменений нужно заново пройти квест наследования,
НС>>Абсолютно каждый раз?
vaa>Да

Сможешь доказать?

НС>>ООП противоречит модулям?
vaa>Модуль — набор функций.
vaa>Да, ООП решение это сложная лапша интерфейсов и реализаций.

Или нет.

vaa>>>И еще храните состояние в базе, если есть база.
НС>>Ага, а еще используйте протокол HTTP для работы в интернете.
vaa>не вдупляю.

Вот и я тоже не вдупляю.

vaa>>>например очередь. зачем?
НС>>Что зачем?
vaa>см. ниже.

Смотрел. Непонятно.

НС>>Резюме: ты чего сказать то хотел?
vaa>что хотел, то и сказал.

Ты с какой целью вывалил это в публичный форум?

Здравствуйте, gandjustas, Вы писали:

vaa>>И еще храните состояние в базе, если есть база.
vaa>>не нужно без необходимости использовать ООП.
G>Убрать все нелокальные переменные и на каждое изменнение писать в БД ?
так точно.

vaa>>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
G>Вам не кажется что это усложнение на пустом песте?
по ситуации

vaa>ООП решения сложны для понимания.
ООП какого решения? Надо сравнивать решение 1 и той же задачи с ООП и без ООП. А не сферическое решение в воздухе.
Есть примеры чего-то вроде 1с УПП с ООП и без ООП?

Здравствуйте, vaa, Вы писали:

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

vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,
vaa>чтобы понять где находится суть действия над данными.
И вот это вы называете "сложно"? Это вообще рутина.

vaa>Единственно верное решение сложной задачи без усложения — модули.
Что есть модуль? Чем он отличается от слоя?

vaa>И еще храните состояние в базе, если есть база.
Если у вас есть состояние, значит у вас есть проблемы. А в базе это состояние или в памяти — не важно.

vaa>не нужно без необходимости использовать ООП.
Нет никакой "необходимости"! Некоторые умеют в ООП, а некоторые нет. Это от способа мышления программиста зависит.

vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
Это всё равно очередь.
У меня складывается впечатление, что кто-то не умеет в многопоточность...

vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
А! Точно! Кто-то не смог написать потокобезопасную очередь.

Здравствуйте, vaa, Вы писали:

vaa>Единственно верное решение сложной задачи без усложения — модули.

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

Здравствуйте, Serginio1, Вы писали:

S> Угу я как бывший 1С ник скажу, что херня. Ибо там сразу применяют утиную типизацию.
S>И уж хрен поймешь код.
S> ООП нужен. Прежде всего для уменьшения кода по сравнению с интерфейсами.
S>Да бывают проблемы с чтением виртуальных методов. Когда методы переопределены. Но всегда можно посмотреть реализацию наследников в студии.

Как тоже бывший — в 1С фактически-то ООП присутствует, хоть и в урезанном виде. Каждый новый документ — наследник общего «Документа», переопределяющий виртуальные методы. Всякие журналы — это интерфейсы, позволяющие однообразно работать с документами разных типов. Ну и т.п.

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

Здравствуйте, agp, Вы писали:

agp>Как тоже бывший — в 1С фактически-то ООП присутствует, хоть и в урезанном виде. Каждый новый документ — наследник общего «Документа», переопределяющий виртуальные методы. Всякие журналы — это интерфейсы, позволяющие однообразно работать с документами разных типов. Ну и т.п.

agp>Типизация динамическая, но это уже другой вопрос. И набор базовых классов ограничен. А так вполне себе ООП
Угу из наследование так себе. Захотел я сделать промежуточный базовый класс и все.
Мало того, там до сих пор нет замыканий! Они ввели аналог async/await но не ввели замыканий!
https://wonderland.v8.1c.ru/blog/uluchsheniya-v-sintaksise-yazyka-1s-dlya-raboty-s-asinkhronnymi-funktsiyami/?ysclid=l84dy7bmsz499514635

https://xn----1-bedvffifm4g.xn--p1ai/news/async-metods-article/?ysclid=l84e188i1z696880695#sozd-obr
Нет даже делегатов

&НаКлиенте
Процедура ЗагрузитьДанные()

    Ответ = Неопределено;


    ПоказатьВопрос(Новый ОписаниеОповещения("ЗагрузитьДанныеЗавершение", ЭтаФорма), "Выполнить загрузку?", РежимДиалогаВопрос.ДаНет);
    
КонецПроцедуры

&НаКлиенте
Процедура ЗагрузитьДанныеЗавершение(РезультатВопроса, ДополнительныеПараметры) Экспорт
    
    Ответ = РезультатВопроса;
    Если Ответ = КодВозвратаДиалога.Да Тогда
        
        //Логика загрузки
        
    КонецЕсли;
    
КонецПроцедуры

Здравствуйте, vaa, Вы писали:

vaa>Единственно верное решение сложной задачи без усложения — модули.

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

vaa>И еще храните состояние в базе, если есть база.
vaa>не нужно без необходимости использовать ООП.
vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.

Зачем база, если есть корутины и очереди (в некоторых языках каналы)?

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

Здравствуйте, Socrat, Вы писали:

S>Здравствуйте, vaa, Вы писали:

vaa>>Единственно верное решение сложной задачи без усложения — модули.

S>Интересно, как можно создать несколько экземпляров одного модуля?
Модуль это набор функций. Соответственно никак. ООП не должно содержать реализацию, пусть класс делегирует свои полномочия функциям метода.
vaa>>И еще храните состояние в базе, если есть база.
vaa>>не нужно без необходимости использовать ООП.
vaa>>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
vaa>>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.

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

Здравствуйте, Pauel, Вы писали:

P>Вот например, наследование интерфейсов — определяем иммутабл интерфейс. Всё ж круто?
P>И пронаследуем его. Всё ж класнно, можно наследовать интрерфейсы.
P>А наследник будет мутабл. Гыгы. Получаем тот же приплызд, что и с наследованием реализации

Не не, котов (интерфейсы) нужно варить в отдельной кастрюле от собак (объекты)
Наследование интерфейсов <> наследованию классов.
2 отдельные живности (интерфейсы и объекты) создающие 2 дерева наследования, которые строятся схожим образом.
Но это 2 параллельные сущности реализации функционала.

Если 1 чел или 1 группа что то создает, то можно (и лучше) использовать дерево объектов или дерево интерфесов, что однофуйственно.
А если несколько групп людей юзают какой то функционал, не знающие друг о друге, то реализовывать функционал нужно только на интерфейсах.

PS: По дебагу/модификации объекты удобнее, но интерфейсы можно юзать откуда угодно и куда угодно встраивать.

Здравствуйте, AWSVladimir, Вы писали:

P>>А наследник будет мутабл. Гыгы. Получаем тот же приплызд, что и с наследованием реализации

AWS>Не не, котов (интерфейсы) нужно варить в отдельной кастрюле от собак (объекты)

Надо то надо, только с интерфейсами все ровно то же, что и с классами. Причина в том, что интерфейс подразумевает вполне конкретную сементику — интерфейс без семантики никого не интересует. А проблема здесь такая, что никто не мешает унаследовать, скажем, иммутабл интерфейс и добавить мутабл методы или наоборот, т.е. подменить семантику.
метод add(item) должен добавить ровно один, и в конец списка, например. Если мы отнаследуемся, и переопределим этот add, то получим ровно то же, что и с наследованием реализации. Можно смеяться, но так действительно бывает, например, в целях оптимизации добавили, а потом приходится с этим жить.
Или так — построили иерархию интерфейсов, а потом взяли добавили в базовый интерфейс опциональный метод который ломает всё подряд.

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

Здравствуйте, Pauel, Вы писали:

P>А проблема здесь такая, что никто не мешает унаследовать, скажем, иммутабл интерфейс и добавить мутабл методы или наоборот, т.е. подменить семантику.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>А проблема здесь такая, что никто не мешает унаследовать, скажем, иммутабл интерфейс и добавить мутабл методы или наоборот, т.е. подменить семантику.

НС>Нет, проблема здесь в том, что иммутабельность никак не выражается системой типов мейнстрим языков, роэтому, по факту, сейчас признак readonly это нестатическая сущность.

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

Здравствуйте, Pauel, Вы писали:

P>Не только иммутабельность, а вообще семантический контракт никак не выражается системой типов.

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

P>Поэтому семантика в интерфейсе описывается в лучшем случае в каментах.

В дотнете — как минимум еще в атрибутах. С контролем в виде доптулов, например в виде аналайзеров.

Здравствуйте, Ночной Смотрящий, Вы писали:

P>>Не только иммутабельность, а вообще семантический контракт никак не выражается системой типов.

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

В этом и проблема.

НС>В дотнете — как минимум еще в атрибутах. С контролем в виде доптулов, например в виде аналайзеров.

Это и есть чудовищное усложнение. Например, на конкретный кейс частенько не хватает фичи в анализаторе. Что делать?5