Абстракция - это основа программирования. Следует тщательно выбирать, насколько абстрактным вам следует быть. Начинающие программисты в своем энтузиазме часто создают больше абстракций, чем в действительности необходимо. Один из признаков такой ситуации: вы создаете классы, которые почти не содержат код и служат только для абстрактного представления чего-то. Привлекательность этого подхода понятна, но ценность краткости кода надо соизмерять с ценностью абстракции. Иногда можно видеть ошибку, совершаемую восторженными идеалистами: на старте проекта создается множество классов, которые кажутся восхитительно абстрактными, и кажется, что они справятся со всеми ситуациями, которые только могут возникнуть. По мере продвижения проекта и наступления усталости код становится беспорядочным. Тела функций становятся больше, чем они должны быть. Пустые классы это еще и бремя документирования, которое часто игнорируется под давлением. Итоговый результат был бы лучше, если бы энергия, потраченная на абстракцию, была бы потрачена на то, чтобы сохранить код кратким и простым. Это разновидность спекулятивного программирования. На эту тему я очень рекомендую прочесть статью Пола Грэхема 'Succinctness is Power'.
Существует определенные догмы, связанные с такими полезными техниками как сокрытие информации и объектно-ориентированное программирование, применение которых иногда заходит слишком далеко. Они позволяют писать код более абстрактно и предвидеть возможные в нем изменения. Однако, я лично считаю, что не следует писать слишком много спекулятивного кода. Например, принято прятать целочисленные переменные в объектах за публичными методами класса, так что сама переменная не видна, а доступен только интерфейс к ней. Это позволяет изменить реализацию этой переменной без изменения вызывающего эти методы кода. Возможно, это подходит для разработки библиотек, где необходимо предоставить устойчивый API. Но я не думаю, что преимущества этого подхода перевешивают избыток кода, потраченного на него, особенно, когда моя команда владеет вызывающим кодом и может переписать как его, так и вызываемый код. Четыре или пять строк кода - это большая цена за такое умозрительное преимущество.
Портируемость создает похожую проблему. Должен ли код быть портируемым на другой компьютер, компилятор, систему или платформу, или его стоит просто переписать под них? Я думаю, что непортируемый, короткий и легко переписываемый код лучше, чем длинный портируемый. Относительно легкая и обычно хорошая идея - ограничить непортируемый код в определенных областях, таких как класс, который выполняет запросы к базе данных, специфичные для данной СУБД.
Следующее: Как осваивать новые навыки