При написании не тривиальных приложений возникает вопрос: над какими библиотеками делать еще один абстрактный слой, а над какими — нет? Какие абстракции делать?

Стоит ли делать прослойку над, например, SQLAlchemy? Это же и так прослойка над SQL и DBAPI. Имеет ли смысл делать уровни абстракций над такими достаточно хорошими и отточенными в смысле интерфейсов библиотеками?

Ответ очень простой — библиотеки представляют API который должен быть применим для широкого спектра приложений. Они отображают низкоуровневые (с точки зрения их API ) вызовы на более высокоуровневый, но абстрактный интерфейс. Характерный пример — библиотеки передачи сообщений. Они позволяют не думать о сокетах, упаковке/распаковке float/int и т.п., а просто передавать структуры данных.

Типичный API системы пересылки сообщений выглядит как:

class Messaging(object):
    def send_message_async(self, dest, message_tp, message_data):
        # some code

    def send_message_sync(self, dest, message_tp, message_data):
        # some code

    def get_message(self):
        # some code

Но программе не нужно посылать никакие сообщения! Ей нужно выполнить действия — показать пользователю GUI, узнать завершился ли удаленный процесс, etc. API сообщений, которое было-бы идеально для некоторой программы выглядит примерно так:

class MyAPI(object):

    @exception_on_false
    def show_ui_message(self, level, text):
        return self.messanger.send_message_async(self.UI_PROC_ID,
                                SHOW_DIALOG, 
                                dict(level=level, text=text))

    @exception_on_false
    def reboot_vm(self, ip):
        return self.messanger.send_message_async(
                                self.get_remote_agent_id(ip),
                                REBOOT_VM, 
                                None)

    def ls_remote(self, ip, remote_path):
        tp, res = self.messanger.send_message_sync(
                                self.get_remote_agent_id(ip),
                                EXEC_CMD, 
                                'ls -l {0}'.format(remote_path))
        if tp == EXECUTION_FINISHED_OK:
            return res
        else:
            raise RuntimeError("Cmd ... finished with error code {0}".
                                    format(res))

Очень принципиальный момент — конечный API должен отражать задачи, стоящие перед программой. Четкое отделение основной логики программы от деталей реализации имеет минимум два очень важных плюса — позволяет сделать главный код легче для чтения (убирает лишние абстракции) и максимально отвязать программу от API библиотек (локализовать привязку).

Это особенная прослойка, это «последняя линия». Если остальные API предоставляют нам абстракции, то эта прослойка не должна добавлять ничего лишнего, она избавляет нас от более не нужных абстракций и говорит языком предметной области программы.

Вам нужно хранить в базе список фруктов? Сделайте функцию store_fruits. Такая функция позволить вам перейти от PostgreSQL к Cassandra, а потом к текстовым файлам (маловероятная ситуация, но не суть) без влияния на остальную программу. Потому что программе все равно где лежат данные. Программу интересует только что они сохраняются и восстанавливаются.

Мы никак не может защититься от изменения требований к программе и вместе с изменениями требований нужно будет меняться и API, который предоставляет наш слой абстракции. Но вот изменения в типе базы/структуре базы/ORM не будет приводить к изменению кода. Если смена БД или ORM — маловероятная ситуация, то вот добавление нового поля вида deleted, означающего, что запись вроде как удалена и почти нигде не должна использоваться — весьма частый случай.

# почти реальный запрос прямо из функции, отвечающей за логики программы 

services = session.query(Service).
                    filter(Service.zone_id == zone_id).
                        filter(Service.service_id == service_id).
                            with_lockmode('update').
                                limit(10).all()
# Чего-чего????? 
# комментарий к запросу немного бы спас ситуацию
# но вместо решения проблем с помощью комментирования их лучше не создавать 
# Этот код не требует комментариев

for service in db.get_10_services(zone_id, service_id):
    # some code


# в файле db.py
def get_10_services(self, zone_id, service_id):
    return self.session.query(Service).
                    filter(Service.zone_id == zone_id).
                        filter(Service.service_id == service_id).
                            with_lockmode('update').
                                limit(10).all()

Еще одна ошибка — попытка сэкономить на таком API и сделать в этом духе:

import sqlalchemy as sa

# one Function to rule them all!!
def get_user(session, *opts):
    return session.query(User).filter(sa.and_(*opts)).all()

# этот код уже требует знания что там у нас за sqlalchemy такая
# и на mongo его уже не переписать так-же легко

# тут "торчат уши" sqlalchemy. Да, мы съекономили 10-20 нажатий клавишь
# на каждый вызов, но это не "the very last API"

for user in get_user(User.name == 'vasya', User.age > datetime.now()):
    pass

Безусловно у любого абстрагирования есть минимум один существенный минус — пользуясь им люди хуже понимают что происходит на уровнях ниже. При возникновении проблем внутри абстракций или еще ниже (например могут быть проблемы с сетью) на их решение может уйти много времени — а проблемы возникают постоянно. Во-вторых исчезает контроль над ситуацией. Любая сложная библиотека несет свои неожиданности в добавок к особенностям нижнего уровня. В итоге вопрос «почему функция выборки из базы зависает» может стать не решаемым.

Я за последнее время видел некоторое количество достаточно опытных программистов, которые почти ничего не знают про сокеты и TCP, потому что RabbitMQ и про потоки, потому что фреймфорк подставьтет-тут-свой-фреймфорк. Нет, это не проявления вселенского зла. Отлично что программирование упрощается, но эта категория программистов — клиенты обеих проблем сверху.

Впрочем это уже другой вопрос. А наш вопрос — абстракции :).

Уровни абстракции должны быть Надежными и легкими для изучения. А ваши абстракции
«последнего рубежа» должны отражать проблемную область программы и закрывать ими я бы стал почти все нетривиальные внешние зависимости, которые используются в значительной части кода программы и привносят свои абстракции.

P.S. Обычно такой подход хорошо работает, но как и все обобщенные рассуждения эти мысли стоит материализовывать без фанатизма — случаи то разные бывают.

Ссылки:
          www.sqlalchemy.org/
          www.python.org/dev/peps/pep-0249/
Исходники этого и других постов со скриптами лежат тут — github.com/koder-ua.При использовании их, пожалуйста, ссылайтесь на koder-ua.blogspot.com.

Автор: konstantin danilov