# Как балансировать краткость и абстракцию

Абстракция - это основа программирования. Следует тщательно выбирать, насколько абстрактным вам следует быть. Начинающие программисты в своем энтузиазме часто создают больше абстракций, чем в действительности необходимо. Один из признаков такой ситуации: вы создаете классы, которые почти не содержат код и служат только для абстрактного представления чего-то. Привлекательность этого подхода понятна, но ценность краткости кода надо соизмерять с ценностью абстракции. Иногда можно видеть ошибку, совершаемую восторженными идеалистами: на старте проекта создается множество классов, которые кажутся восхитительно абстрактными, и кажется, что они справятся со всеми ситуациями, которые только могут возникнуть. По мере продвижения проекта и наступления усталости код становится беспорядочным. Тела функций становятся больше, чем они должны быть. Пустые классы это еще и бремя документирования, которое часто игнорируется под давлением. Итоговый результат был бы лучше, если бы энергия, потраченная на абстракцию, была бы потрачена на то, чтобы сохранить код кратким и простым. Это разновидность *спекулятивного программирования*. На эту тему я очень рекомендую прочесть статью Пола Грэхема ['Succinctness is Power'](http://www.paulgraham.com/power.html).

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

Портируемость создает похожую проблему. Должен ли код быть портируемым на другой компьютер, компилятор, систему или платформу, или его стоит просто переписать под них? Я думаю, что непортируемый, короткий и легко переписываемый код лучше, чем длинный портируемый. Относительно легкая и обычно хорошая идея - ограничить непортируемый код в определенных областях, таких как класс, который выполняет запросы к базе данных, специфичные для данной СУБД.

Следующее: [Как осваивать новые навыки](/how-to-be-a-programmer/ru/2-intermediate/personal-skills/06-how-to-learn-new-skills.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://braydie.gitbook.io/how-to-be-a-programmer/ru/2-intermediate/personal-skills/05-how-to-balance-brevity-and-abstraction.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.