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

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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