Приводит ли ООП с одной парадигмой к инверсии абстракции?

Question

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

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

Answer 1

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

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

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

Чтобы смешать пару метафор, когда все, что у вас есть, это молоток, все начинает выглядеть как колышек, и если все ваши отверстия круглые, и вы внезапно заканчиваете с некоторыми квадратными колышками, и у вас нет пил, (только молотки) У тебя проблема.

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

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

Answer 2

настоящие программисты могут писать на Фортране на любом языке

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

Answer 3

Java и C # имеют статические методы, которые эквивалентны функциям, поэтому язык ничего не навязывает вам.

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

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

Answer 4

Я не думаю, что язык , такой как Java или C #, страдает от этого каким-либо ощутимым образом, просто потому, что библиотеки, сопровождающие фреймворк, настолько богаты, что необходимость взломать другую парадигму требуется для общего программирования.

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

Кроме того, поскольку среда .Net Framework / Java Runtime позволяет взаимодействовать с другими языками, находящимися поверх общей среды выполнения, возможность нацеливаться на другие парадигмы (такие как функциональное программирование, динамические языки и т. Д.) Также может обеспечить другой путь к отказу из ограничений одной парадигмы.