генеалогия как сушилка для мозгов
Jul. 6th, 2022 01:13 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoЯ, только что понял, что меня больше всего бесит в ООП (вне зависимости от языка). Это _генеалогия_. Рассказы о том, кто кому является родителем и кто потомок. Существуют редчайшие случаи, когда онтология предметной области хорошо ложится на концепцию предок-потомок (в смысле ООП).
Чаще всего это набор риторических упражнений, не имеющий отношения ни к коду, ни к предметной области.
(рандомный пример: Если я работаю с API двух разных провайдеров, то у меня нет "предка" этих API, у меня есть два разных API к которым я хочу иметь одинаковый интерфейс - и рассказы про "предка" GenericApi, из которого пояются FooApi и BarApi - херня и натягивание задачи на генеалогию).
Вот любой рассказ про "обобщённую генеалогию" в ООП вызывает у меня мгновенное иссушение мозга. Я не понимаю зачем я должен использовать эту модель, почему именно эту модель и почему эта модель должна занимать у меня в голове больше места, чем предметная область, которую я пытаюсь охватить.
Я бы даже сказал, польза от ООП заканчивается на концепции класс/инстанс. Это разумное деление, хотя, например, Rust прекрасно без этого обошёлся с помощью понятия "структура" и "методы на структуре". В этом месте, кстати, класс, рассыпается на две более разумные конструкции: структура (тип данных); инстансы этой стурктуры (значения типа) и методы, которые связаны со структурой. Это деление автоматом устраняет "кашу" из данных и методов в обычных классах, и любой код в котором "метод - это элемент структуры" начинают выглядеть ровно так, как выглядят - странно и привлекая к себе внимание.
Есть одна область, в которой я очень люблю наследование и считаю его разумным. Это исключения. Хорошо сделанная система наследований исключений позволяет перехватывать исключения на нужном уровне общности. Это как раз пример ситуации, когда иерархия наследований хорошо ложится на предметную область.
И то! Комфортнее всего с ними работать, когда все эти "наследуемые" исключения или 'pass' (т.е. не имеют ничего своего, кроме типа), или имеют доп. методы, которые никаким образом старые не ломают.
В большинстве же случаев в Питоне классы и наследование используется не для передачи смысла, а как странный метод композции; и чаще всего от безысходности.
Чаще всего это набор риторических упражнений, не имеющий отношения ни к коду, ни к предметной области.
(рандомный пример: Если я работаю с API двух разных провайдеров, то у меня нет "предка" этих API, у меня есть два разных API к которым я хочу иметь одинаковый интерфейс - и рассказы про "предка" GenericApi, из которого пояются FooApi и BarApi - херня и натягивание задачи на генеалогию).
Вот любой рассказ про "обобщённую генеалогию" в ООП вызывает у меня мгновенное иссушение мозга. Я не понимаю зачем я должен использовать эту модель, почему именно эту модель и почему эта модель должна занимать у меня в голове больше места, чем предметная область, которую я пытаюсь охватить.
Я бы даже сказал, польза от ООП заканчивается на концепции класс/инстанс. Это разумное деление, хотя, например, Rust прекрасно без этого обошёлся с помощью понятия "структура" и "методы на структуре". В этом месте, кстати, класс, рассыпается на две более разумные конструкции: структура (тип данных); инстансы этой стурктуры (значения типа) и методы, которые связаны со структурой. Это деление автоматом устраняет "кашу" из данных и методов в обычных классах, и любой код в котором "метод - это элемент структуры" начинают выглядеть ровно так, как выглядят - странно и привлекая к себе внимание.
Есть одна область, в которой я очень люблю наследование и считаю его разумным. Это исключения. Хорошо сделанная система наследований исключений позволяет перехватывать исключения на нужном уровне общности. Это как раз пример ситуации, когда иерархия наследований хорошо ложится на предметную область.
И то! Комфортнее всего с ними работать, когда все эти "наследуемые" исключения или 'pass' (т.е. не имеют ничего своего, кроме типа), или имеют доп. методы, которые никаким образом старые не ломают.
В большинстве же случаев в Питоне классы и наследование используется не для передачи смысла, а как странный метод композции; и чаще всего от безысходности.
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)Перекрестился. Фея вежливости всё равно осталась.