Эта статья будет в большей степени полезна новичкам, только начинающим работать с абстракциями и построением архитектур ПО. Однако искренне надеюсь, что и более опытные специалисты смогут найти для себя что-то интересное в этом материале.
Абстракция — один из набивших оскомину столпов ООП. В любом курсе по программированию с вероятностью 99% можно найти урок-другой, посвященный теме абстракции. И практически всегда упускается более широкое, всеобъемлющее понятие «уровней абстракции» — на мой взгляд, критически важное, ключевое для понимания всех остальных принципов проектирования.
Модель объекта и ступень приближения
Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном приближении. И уровень абстракции — это и есть наша ступень приближения. Каждый человек способен строить абстракции — это отличительная способность homo sapiens. Но не каждый способен делать это достаточно качественно.
Чтобы не вдаваться в многоэтажную теорию, приведу наглядный пример. Итак, раскладываем по полочкам. Представьте себе, что вы решили испечь яблочный пирог. Вы берете толстую кулинарную книгу с полки (для любителей, все остальные — в сеть), открываете нужный вам рецепт и читаете нечто следующее:
«Чтобы испечь яблочный пирог, нам понадобится два килограмма непременно свежих яблок, румяных, как девичьи щёки на крещенском морозе. Помнится, видал я такие щёчки у моей ненаглядной Лизоньки, когда мы впервые с ней встретились, и она угощала меня яблочными пирогами, состряпанными на последние деньги, которые она выручила от продажи дедовских коллекционных монет 1819 года, выпущенных при императоре таком-то...» И т.д, и т.п.
Если вы осилили текст курсивом, то вы очевидно заметили, что он имеет весьма посредственное отношение к тому, что нам нужно. Собственно, к тому, как же печь эти чертовы пироги из яблок, не правда ли?
А теперь вспомните, как часто в коде нам приходится встречать логические конструкции типа if-if-if-else-if-else-if, содержащие тонны вложенных рассуждений. Приходится читать все эти адские нагромождения и держать в голове всю цепочку событий, для того, чтобы понять, что тут вообще происходит и какое отношение «вот это всё» имеет к заявленному содержанию (название класса/функции по аналогии с названием рецепта «яблочный пирог»).
А ведь что на самом деле нас интересовало в рецепте? Нам нужно было знать, сколько и каких продуктов нам понадобится и что затем с ними делать. Нас абсолютно не интересует в этом приближении (на данном уровне абстракции), каким образом эти продукты к нам попали (более низкие уровни абстракции) и что мы будем делать с этим пирогом потом (более высокие уровни абстракции). Это очевидно. Но тысячи программистов продолжают игнорировать эти принципы и пишут мозговыносные структуры if-if-else-if...
А бывает так, что в рецепте встречаются умные словечки типа «бланшировать» или «сделать бизе». В хороших кулинарных руководствах описание подобных практик выносят в отдельные главы, а в самих рецептах лишь ссылаются на страницы с подробным описанием техники (привет, Инкапсуляция).
Построение структуры
Конечно, бывают и обратные ситуации, когда за тоннами слоёв абстракций невозможно уловить нить повествования. Но в этом-то и состоит мастерство архитектора ПО — спроектировать достаточно простую для сопровождения, то есть понимания, структуру. «Не нужно быть умным — нужно быть понятным» ©.
В то же время, не терять в эффективности решения бизнес-задач. В некоторой мере, это искусство. Каждый конкретный архитектор (программист) будет рисовать эту картину, то есть создавать модель мира по-своему: «Я художник — я так вижу». Вот вам пища в топку холиваров на счет единых стандартов программирования в рамках команды и необходимости наличия исполнителя роли архитектора.
Абстракция и Реализация
Есть ещё один момент, о котором я хочу упомянуть: путешествие между слоями логик. Красиво изолированный уровень абстракции достаточно прост для понимания: у нас есть ряд объектов, очевидным образом взаимодействующих между собой, уровни вложенности маленькие (если они вообще есть — как в рецепте пирога). Однако, как нам уже стало понятно, самым трудозатратным для понимания является перемещение междууровнями абстракций.
Чтобы упростить этот процесс, стоит разобраться в природе дуальности понятий Абстракции и Реализации. В этом моменте обычно и фокусируются на различных курсах по программированию, перед этим упуская понятие уровня абстракции. Из-за чего у студентов формируется заблуждение, что ООП — это что-то запредельно сложное.
Возьмем для примера такую цепочку слоёв абстракций: нам нужен пирог для Дня рождения друга. Спускаемся ниже: пирог может быть фруктовый или мясной. А может, рыбный? В момент рассуждений о том, что нам нужен какой-то пирог в качестве подарка, он (пирог) выступает конечным элементом данного уровня абстракции. В этот момент пирог — это реализацияподарка (но он может быть любой: бритва, деньги, конструктор лего — это всё варианты подарка). Когда мы совершаем переход на более низкий уровень абстракции, наш объект (пирог) превращается из конечной реализации в абстракцию: уже нас не устраивает уровень детализации «какой-то пирог», мы начинаем искать его реализацию (привет, Полиморфизм).
Таким образом, считать объект абстрактным или реальным — зависит исключительно от степени детализации моделируемого «мира» и от бизнес-задач, поставленных перед архитектором. И, разумеется, от его чувства прекрасного.
С моей точки зрения, понимая явление уровней абстракций, можно легко разобраться во всех принципах и шаблонах проектирования.
P.S.Написать эту статью меня побудило энное предложение стать лектором на очередных курсах по программированию. И, хотя, у меня и есть желание испытать подобный опыт, в данный период моей жизни и в обозримом будущем это не представляется возможным. Я решила, что моё желание рассказывать о сложных вещах простым и понятным образом (надеюсь, это так) пусть лучше выльется в какое-то количество статей, нежели будет погребено под тоннами лет бездействия.
Если моя манера изъясняться была кому-то полезной в достижении состояния «дзен» и вообще «пишите, Шура», то в будущем, вероятно, напишу «о чём-то таком ещё».