Худшая инверсия абстракции

Это походит на довольно мертвую тему. Я отвечу на свой собственный вопрос только для запуска некоторого обсуждения. Я сказал бы, что худшая инверсия абстракции, которую я видел, использует классы/интерфейсы краткого обзора стиля ООП для тиражирования указателей функции. Например:

interface foo {
    int bar();
}

class myClass1 implements foo {
    // No member variables.

    int bar() {
        // Implementation
    }

    // No other methods.
}

class myClass2 implements foo {
    // No member variables.

    int bar() {
        // Implementation
    }

    // No other methods.
}

Класс, как предполагается, является мощной абстракцией для того, когда необходимо инкапсулировать и состояние и поведение. Указатель функции является чем-то относительно простым, которое используется для содержания поведения только. Виртуальные функции реализованы с помощью массивов указателей функции, но много языков OO не выставляют указатели функции или что-либо непосредственно эквивалентное. Вы поэтому заканчиваете тем, что использовали интерфейсы и классы для реализации функциональности, эквивалентной указателям функции, и эти классы и интерфейсы самостоятельно реализованы с точки зрения указателей функции. Это приводит и к ненужной сложности и к уменьшенной производительности.

Я не уверен, отвечает ли это на Ваш вопрос, но я видел это (и я был виновен в нем), где хороший высокоуровневый язык как Lisp привыкает, как будто это был Фортран или даже Ассемблер, потому что это - уровень, в котором был программист.

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

Другой ответ или вопрос, если Вы не возражаете. Слово "абстракция" на самом деле имеет определение? Действительно ли абстракции на самом деле хороши, или плохо или нейтральны? Я имею в виду, я понимаю, что номер 2 абстрактен, потому что он обозначает то, что распространено приблизительно 2 ботинка, 2 глаза, 2 цикла, и т.д. Интерфейс IStack может быть абстрактным, потому что он относится к вещам то действие как стеки. Но если подпрограмма подпрограмма вызовов B, который означает это, более абстрактна? Почему мы так очарованы из этого слова?

EDT: я только спрашиваю, потому что я видел, что люди задирают носы перед "конкретными" проблемами, думая, что лес более важен, чем деревья.

Я не уверен, квалифицирует ли это действительно, но это кажется связанным. Когда SQL Server, 2005 выпустил возможности CLR, я слышал набор разработчиков, говорящих вещи как "хорошо, теперь мы можем исчерпать вызовы веб-сервиса непосредственно из наших хранимых процедур!" Я также видел несколько учебных руководств при выполнении этого. Это - некоторые конфликтующие уровни абстракции.

Какой наихудший (из-за распространенности или серьезности) пример инверсии абстракции , который вы видите сегодня в программировании?

Я не знаю, есть ли это имеет значение, но меня обычно раздражает, когда я вижу классы, названные в честь их реализации вместо того, для чего они . Это действительно своего рода венгерская нотация, обратите внимание:

• CustomerFactory
• DecisionTreeVisitor
• AbstractWindowDecorator
• JsonDataAdapter
• TabbedDocumentImpl
• ConcreteListHandler

«Factory», «Visitor», «Decorator», » Adapter »,« Impl »,« Concrete »- кого волнует, как он реализован, для чего он используется?

Использование библиотек процедурных коллекций на стороне клиента для обработки результивных наборов SQL.