генеалогия как сушилка для мозгов
Jul. 6th, 2022 01:13 pmЯ, только что понял, что меня больше всего бесит в ООП (вне зависимости от языка). Это _генеалогия_. Рассказы о том, кто кому является родителем и кто потомок. Существуют редчайшие случаи, когда онтология предметной области хорошо ложится на концепцию предок-потомок (в смысле ООП).
Чаще всего это набор риторических упражнений, не имеющий отношения ни к коду, ни к предметной области.
(рандомный пример: Если я работаю с API двух разных провайдеров, то у меня нет "предка" этих API, у меня есть два разных API к которым я хочу иметь одинаковый интерфейс - и рассказы про "предка" GenericApi, из которого пояются FooApi и BarApi - херня и натягивание задачи на генеалогию).
Вот любой рассказ про "обобщённую генеалогию" в ООП вызывает у меня мгновенное иссушение мозга. Я не понимаю зачем я должен использовать эту модель, почему именно эту модель и почему эта модель должна занимать у меня в голове больше места, чем предметная область, которую я пытаюсь охватить.
Я бы даже сказал, польза от ООП заканчивается на концепции класс/инстанс. Это разумное деление, хотя, например, Rust прекрасно без этого обошёлся с помощью понятия "структура" и "методы на структуре". В этом месте, кстати, класс, рассыпается на две более разумные конструкции: структура (тип данных); инстансы этой стурктуры (значения типа) и методы, которые связаны со структурой. Это деление автоматом устраняет "кашу" из данных и методов в обычных классах, и любой код в котором "метод - это элемент структуры" начинают выглядеть ровно так, как выглядят - странно и привлекая к себе внимание.
Есть одна область, в которой я очень люблю наследование и считаю его разумным. Это исключения. Хорошо сделанная система наследований исключений позволяет перехватывать исключения на нужном уровне общности. Это как раз пример ситуации, когда иерархия наследований хорошо ложится на предметную область.
И то! Комфортнее всего с ними работать, когда все эти "наследуемые" исключения или 'pass' (т.е. не имеют ничего своего, кроме типа), или имеют доп. методы, которые никаким образом старые не ломают.
В большинстве же случаев в Питоне классы и наследование используется не для передачи смысла, а как странный метод композции; и чаще всего от безысходности.
Чаще всего это набор риторических упражнений, не имеющий отношения ни к коду, ни к предметной области.
(рандомный пример: Если я работаю с API двух разных провайдеров, то у меня нет "предка" этих API, у меня есть два разных API к которым я хочу иметь одинаковый интерфейс - и рассказы про "предка" GenericApi, из которого пояются FooApi и BarApi - херня и натягивание задачи на генеалогию).
Вот любой рассказ про "обобщённую генеалогию" в ООП вызывает у меня мгновенное иссушение мозга. Я не понимаю зачем я должен использовать эту модель, почему именно эту модель и почему эта модель должна занимать у меня в голове больше места, чем предметная область, которую я пытаюсь охватить.
Я бы даже сказал, польза от ООП заканчивается на концепции класс/инстанс. Это разумное деление, хотя, например, Rust прекрасно без этого обошёлся с помощью понятия "структура" и "методы на структуре". В этом месте, кстати, класс, рассыпается на две более разумные конструкции: структура (тип данных); инстансы этой стурктуры (значения типа) и методы, которые связаны со структурой. Это деление автоматом устраняет "кашу" из данных и методов в обычных классах, и любой код в котором "метод - это элемент структуры" начинают выглядеть ровно так, как выглядят - странно и привлекая к себе внимание.
Есть одна область, в которой я очень люблю наследование и считаю его разумным. Это исключения. Хорошо сделанная система наследований исключений позволяет перехватывать исключения на нужном уровне общности. Это как раз пример ситуации, когда иерархия наследований хорошо ложится на предметную область.
И то! Комфортнее всего с ними работать, когда все эти "наследуемые" исключения или 'pass' (т.е. не имеют ничего своего, кроме типа), или имеют доп. методы, которые никаким образом старые не ломают.
В большинстве же случаев в Питоне классы и наследование используется не для передачи смысла, а как странный метод композции; и чаще всего от безысходности.
no subject
Date: 2022-07-06 12:53 pm (UTC)no subject
Date: 2022-07-06 01:00 pm (UTC)Нет. В силу того, что хаскель не способен отслеживать lifetimes и не реализует ownership/borrow модель управления объектами, он вынужен реализовывать GC, и таким образом попадает в кучу "старых GC языков". И даже монадки его не спасают.
Язык с обязательным рантаймом - язык песочниц.
no subject
Date: 2022-07-06 01:34 pm (UTC)Вот интересно, сколько кода на моей машине написано без рантайма? тысяча строк-то наберется?
no subject
Date: 2022-07-06 02:00 pm (UTC)Зависит что у тебя за машина. Если Лада Калина - может быть. А если линукс (или любая другая ОС с ядром), то догадайся, сколько у тебя миллионов строк без рантайма.
no subject
Date: 2022-07-06 02:38 pm (UTC)no subject
Date: 2022-07-07 09:12 am (UTC)Является ли рантаймом то, что написано в самой программе? Мне кажется, что нет.
no subject
Date: 2022-07-07 09:16 am (UTC)Когда кажется - креститься надо. Авось перестанет.
no subject
Date: 2022-07-07 09:27 am (UTC)Перекрестился. Фея вежливости всё равно осталась.
no subject
Date: 2022-07-06 01:13 pm (UTC)ООП нормально работает только в рамках одного сервиса. Если мы общаемся с другими сервисами, то там уже никакого ООП не может быть. Там, скорее, или TLA+ применять нужно, или что-нибудь в таком духе.
no subject
Date: 2022-07-06 01:14 pm (UTC)Я бы даже сказал, что в пределах одного проекта - это чаще всего натягивание совы на глобус. Собственно, про это и пост.
no subject
Date: 2022-07-06 01:50 pm (UTC)Ага. Демонстрирует непонимание (сути вещей). Карго-культ.
no subject
Date: 2022-07-06 03:05 pm (UTC)Ну сколько-нибудь продвинутый ООП оперирует не отношением «предок/потомок», а отношением «надтип/подтип». Граница проходит по тому месту, где объясняют LSP (не тот, который протокол между редактором и языковым сервером, а принцип подставляемости имени Варвары Ивановны Лисковой).
Дальше мы имеем ту же самую решётку типов от
typing.NoReturnдоobjectчерезCallable,Hashable,Reversible,Iterable,Sized,Collection,Container,Mapping,MutableMapping,Sequence,MutableSequence,AbstractSet,MutableSet,Iterator,Generatorи всё такое прочее. Только где-то отношения «я подтип вон того» требуется указывать явно на определении класса/интерфейса (Java, C++), а где-то они выводятся компилятором (TypeScript).А наследование реализации много где объявлено не лучшим способом композиции.
no subject
Date: 2022-07-06 03:16 pm (UTC)Отсутствие явных классов как в Го наоборот создает кашу из непонятно куда привязанных методов.
Ну, и если есть классы разных провайдеров, то для общности там очевидным образом идет не наследование от них, а обертка. Каковую обертку уже можно сделать через наследование, где каждый подкласс обертки будет вызывать свои нутря.