Приводит ли ООП с одной парадигмой к инверсии абстракции?
Для тех из вас, кто не знаком с этой концепцией, инверсия абстракции - это реализация низкоуровневых конструкций поверх высокоуровневых конструкций и обычно считается плохой вещью, поскольку она добавляет как ненужную сложность, так и ненужные накладные расходы. Конечно, это несколько неточное, субъективное определение.
По вашему мнению, неизбежно ли приводит к инверсии абстракции программирование на языке ООП с одной парадигмой, где все должно быть частью класса, а такие вещи, как указатели, не отображаются, например, Java или C#? Если да, то в каких случаях?
Ответы 4
В Java и C# есть статические методы, которые эквивалентны функциям, поэтому язык ничего вам не навязывает.
Тем не менее, как только я действительно получил OO, у меня не было никакого желания переходить к другому стилю программирования.
Если ваш простой объектно-ориентированный слой покрывает что-то сложное, я предполагаю, что проблема, вероятно, связана с вашим кодом. Если объектно-ориентированный подход выполнен правильно, он должен быть простым, вплоть до металла.
Я не буду заходить так далеко, чтобы сказать, что слишком много OO - это плохо, но я с радостью признаю, что это довольно большой молоток, которым можно размахивать разными способами, и без раздумий большинство из них не очень полезны.
Статические методы рассматриваются только как «эквивалентные» простым функциям, потому что другого способа сделать это нет. Когда решается, что все отверстия должны быть круглыми, чтобы удовлетворить королевское чувство эстетики, вы в конечном итоге делаете некоторые действительно уродливые вещи со всеми квадратными колышками, которые продолжают выскакивать. Вскоре вы повсюду будете использовать уродливые статические методы, потому что существует так много концепций, которые просто не соответствуют «объектной» парадигме.
Или вы не знаете, как сопоставить свои концепции с объектной парадигмой. Все, что я сказал, это то, что у меня никогда не было проблем с кодированием как объектно-ориентированным, но если вы не можете найти способ сопоставить вашу конкретную проблему, возможно, вам больше подходит другой язык. Я также не предполагал, что статические методы - хорошее решение - я сказал, что они указывают на то, что вы не получаете объектно-ориентированного подхода - возможно, вы просто не думаете в объектно-ориентированном стиле, а думаете в функциональном. У меня противоположная проблема, я не знаю, как нарисовать достойную, понятную конструктивную схему большой функциональной системы.
настоящие программисты могут писать FORTRAN на любом языке
Другими словами, это не язык, это программист
Я не думаю, что язык, такой как Java или C#, страдает от этого хоть сколько-нибудь ощутимым образом, просто потому, что библиотеки, сопровождающие фреймворк, настолько богаты, что необходимость перехода в другую парадигму на самом деле не требуется для общего программирования.
Тем не менее, сами богатые библиотеки могут страдать от инверсии абстракции, однако, поскольку внутренние реализации часто скрыты или ключевые классы запечатаны, разработчики, пытающиеся расширить эти библиотеки, часто вынуждены повторно реализовывать / реплицировать функциональность, чтобы успешно использовать точки расширения. предоставляется библиотекой базовых классов - это не столько языковая проблема, сколько сознательный выбор, сделанный разработчиком библиотек базовых классов, чтобы избежать раскрытия функциональности, которая может быть хрупкой или часто изменяться с новыми выпусками .Net Framework / JDK.
Кроме того, поскольку .Net Framework / Java Runtime позволяют взаимодействовать с другими языками, находящимися поверх общей среды выполнения, возможность нацеливания на другие парадигмы (например, функциональное программирование, динамические языки и т. д.) Также может предоставить другой путь к отказу от единой парадигмы. ограничения.
Однопарадигма что-нибудь нарушает Первую заповедь абстракций, о которой, похоже, мало кто знает и о которой еще меньше заботятся.
Ты не должен делать себе никаких абстракций, которые нельзя будет преодолеть, если необходимо, чтобы твой код не содержал уродливых инверсий абстракций.
Независимо от вашей парадигмы, как только вы начнете писать нетривиальный код для решения реальных проблем, вы столкнетесь с некоторыми вещами, которые просто не очень хорошо соответствуют парадигме. Если вы заявляете, что одна парадигма - это все, что есть, тогда все становится некрасиво.
Чтобы смешать пару метафор, когда все, что у вас есть, это молоток, все начинает выглядеть как колышек, и если все ваши отверстия круглые, и вы внезапно получаете несколько квадратных колышков, а у вас нет пил (просто молотки ,) у вас есть проблема.
Бесплатного обеда нет. Все - компромисс. Чем легче становится писать код, тем труднее кому-то читать и поддерживать или вам или кому-либо еще отлаживать, когда проблемы возникают ниже того уровня абстракции, на котором вы работаете. (И они в конечном итоге сделают это, потому что нет идеальной абстракции.
Это фундаментальный недостаток «полезных» технологий и парадигм, таких как управляемый код, сборка мусора, JIT-компиляция и указание «все является объектом». Они навязывают базовый уровень абстракции, ниже которого вы не можете достичь, и когда что-то пойдет не так, ниже этого уровня, вы ничего не сможете с этим поделать. Вы застряли в работе с плохой абстракцией, потому что не можете ее исправить.
Я согласен с вашим утверждением "до металла". С другой стороны, меня беспокоит, что объектно-ориентированный подход стал почти самоцелью. Я видел слишком много красиво созданных, но слишком сложных, объектно-ориентированных приложений.