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

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

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


java c# abstraction anti-patterns
person dsimcha    schedule 18.11.2008    source источник

Ответы (4)


arrow_upward
4
arrow_downward

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

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

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

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

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

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

person Mason Wheeler    schedule 29.04.2009

arrow_upward
4
arrow_downward

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

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

person Steven A. Lowe    schedule 18.11.2008

arrow_upward
1
arrow_downward

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

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

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

person Bill K    schedule 18.11.2008
comment
Я согласен с вашим заявлением о металле. С другой стороны, я обеспокоен тем, что объектно-ориентированное программирования стало почти самоцелью. Я видел слишком много красивых, но слишком сложных объектно-ориентированных приложений. - person Mike Dunlavey; 20.11.2008
comment
Я не зайду так далеко, чтобы сказать, что слишком много объектно-ориентированного программирования — это плохо, но я с радостью признаю, что это довольно большой молот, которым можно махать по-разному, и, если не думать, большинство из них не очень полезно. - person Bill K; 20.11.2008
comment
Статические методы считаются эквивалентными простым функциям только потому, что нет другого способа сделать это. Когда решено, что все отверстия должны быть круглыми, чтобы удовлетворить эстетическое чувство короля, вы в конечном итоге делаете действительно уродливые вещи со всеми квадратными штифтами, которые продолжают появляться. Вскоре вы в конечном итоге столкнетесь с уродливыми статическими методами повсюду, потому что существует так много концепций, которые просто не соответствуют объектной парадигме. - person Mason Wheeler; 29.04.2009
comment
Или вы не знаете, как сопоставить свои концепции с объектной парадигмой. Все, что я сказал, это то, что у меня никогда не было проблем с кодированием как объектно-ориентированным, но если вы не можете найти способ отобразить вашу конкретную проблему, возможно, вам лучше подойдет другой язык. Я также не предполагал, что статические методы являются хорошим решением — я сказал, что они являются признаком того, что вы не понимаете объектно-ориентированного подхода — возможно, вы просто не мыслите в объектно-ориентированном подходе, а думаете в функциональном. У меня обратная проблема, я не умею рисовать приличную, понятную схему конструкции большой функциональной системы. - person Bill K; 29.04.2009

arrow_upward
0
arrow_downward

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

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

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

person Bittercoder    schedule 18.11.2008