Понял.

Короче буду пробовать методом научного тыка. Для начала форкну процесс 800 раз, потом форкну 400 но каждый будет обрабатывать 2 задачи. И так далее. А там может и решение найду.

А яка природа ваших задач, які мають виконуватись?

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

ну тут уже можно в букву S упереться, но можно пока не обращать внимание на это

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

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

а по поводу четырёх способов - неожиданные эффекты в потомке входят в них?

да, side effects это четвертый способ: потомок не должен менять проперти которые в родителе обьявлены immutable

Форкати процес більше разів, ніж є в харда - немає сенсу.
Та і заводити під паралельне виконання цілий процес - тоже безсмислено. Тут треба шось максимально легковісне, де можна виконувати обчислення.
Підходить воркрер-тред.
І теж в тій кількості, скільки є фактично ядер (в т.ч. віртуальних).
Далі можна створити пул воркерів, асинхронну чергу задач, і закидати задачі в воркери по доступності.
Це буде оптимальний варіант.
Но якщо в програмі паралельно ще має щось робитися (слухатись сокети і тд), то є сенс створити ще додатковий воркер для цих цілей.

решил погуглить обсуждения (канонический же пример, значит я его где-то уже встречал) и нашёл вот что
https://web.archive.org/web/20151128004108/http://www.objectmentor.com/resources/articles/lsp.pdf

и вот habr.com/ru/company/tinkoff/blog/490738/

Согласен с @murzilka17 Наследование должно быть вширь а не вглубь.
Один интерфейс - много реализаций.
Более сложный пример когда один интерфейс -> много абстракных классов -> у каждого абстрактого класса множество конкретных классов.
Глубокая цепочка наследования - это плохо т.к. создается сильная связность и оверхед на необходимость поддерживать LSP и прочее.
Поэтому по сути глубокое наследование противоречит GRASP - Низкая связанность (Low Coupling)
И решение этой проблемы - композиция, нужно избегать связности в т.ч. и по возможности в виде наследования.
Потому и одно из правил OOD - предпочитайте композицию наследованию https://it.wikireading.ru/27507

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

Вентилятор еще работает? 🙂 ООП подъехало на скорой.  Биологический человек (для медицины важно) с руками, головой,  женщина  с титьками и 3-мя абортами,  персона с ФИО, пациент с состоянием: тяжелое/удовлетварительное, но не простой,  а сотрудница этой же больницы с зарплатой, доктор с категорией,  анестезилог с методом колитБольно(), инвалид с группой (это важно и для лечения,  и для бухгалтерии) и...  пока хватит.  Отказываемся ли от наследования в пользу композиции или больной так вычухается? @murzilka17, пример или ничего.

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

да, есть такие - взяли в JS пронаследовали почти все от Object и от Function, неучи

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

Согласен. Я бы, например, все бы отнаследовал от undefined. Получился бы довольно философский язык. Всё - есть ничто. А что-то это ничто и с боку бантик.

а ты хорош

так и есть тащем-та, Любой обьект может быть ничем в той же джаве

Но не любое ничто может стать объектом.
Такой себе пассивно-аггресивный язык: вас создали никем и вы никто.

Это как?

{
   "success": true,
   "payload": "õÕßýõ"
}