Почему принцип программирования на уровне интерфейсов в большинстве случаев ошибочен и приводит к плохой архитектуре

Хотелось бы увидеть полноценную статью, раз пошло такое дело. Наглядно показать, как знание реализации может ускорить работу программы (например, перебор связного списка или списка на основе массива по индексам), как интерфейсы решают проблему (например, использование итератора для перебора, который гарантирует линейное время). Может ли "опускание" интерфейса значительно упростить архитектуру, бороться с оверинжинерингом?

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

То есть сначала писать на уровне реализации, а потом добавить интерфейс? И как это внедрять, расширять? Покажите примером.

Удобное отображение пустого списка

В дефолтной ситуации можно убирать все фрагменты из контейнера. Например, так:

default:
    for (Fragment fragment : fragmentManager.getFragments()) {
        fragmentManager.beginTransaction().remove(fragment).commit();
    }
    //transaction.replace(fragmentHostId, CodeFragment.newInstance("Default"));
    break;

Удобное отображение пустого списка

Для себя я выделил следующее:

• Выбор подсказки в зависимости от ситуации
• Возможность добавления сложной логики во фрагмент
• Быстрое добавление новых случаев
• Портянка проверок и логика выбора переданы отдельному объекту, в активности мало кода

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