Это точно поможет тебе в проектировании API

— Если ты только начинаешь, советую стартовать с этого интерактивного роадмапа: Он удобен и на каждом этапе содержит ссылки для изучения подтем.

— 6 самых популярных стилей архитектуры API: которые вам нужно знать (с плюсами, минусами и примерами использования)

— Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)

— Руководство по проектированию сетевых API от Google: Его использовали внутри компании с 2014 года, и оно служит основой при разработке облачных и других API.

— Книга «Паттерны проектирования API: Сотрудник того же Google Джей Гивакс рассказывает о том, как в компании создают масштабируемые и гибкие сервисы. Вы узнаете, как улучшить дизайн самых распространённых API и как действовать в сложных пограничных случаях. Сопровождается иллюстрациями и примеры кода.

С вас лойс 👍

#api

Old but gold: подборка статей, которые простым языком объяснят 3 вида паттернов

С примерами из жизни, кейсами для использования и кодом.

Порождающие: https://tprg.ru/patterns-1
Структурные: https://tprg.ru/patterns-2
Поведенческие: https://tprg.ru/patterns-3

#паттерны

Что почитать программисту: «Паттерны объектно-ориентированного проектирования»

Изначально паттерны появились потому, что разработчики искали пути повышения гибкости и степени повторного использования своих программ. В книге максимально простым и доступным языком дают принципы использования шаблонов проектирования для вашего кода.

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

#книги #ооп #паттерны

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

from __future__ import annotations
from abc import ABC, abstractmethod


class Creator(ABC):
    """
    Класс Создатель объявляет фабричный метод, который должен возвращать объект
    класса Продукт. Подклассы Создателя обычно предоставляют реализацию этого
    метода.
    """

    @abstractmethod
    def factory_method(self):
        """
        Обратите внимание, что Создатель может также обеспечить реализацию
        фабричного метода по умолчанию.
        """
        pass

    def some_operation(self) -> str:
        """
        Также заметьте, что, несмотря на название, основная обязанность
        Создателя не заключается в создании продуктов. Обычно он содержит
        некоторую базовую бизнес-логику, которая основана на объектах Продуктов,
        возвращаемых фабричным методом. Подклассы могут косвенно изменять эту
        бизнес-логику, переопределяя фабричный метод и возвращая из него другой
        тип продукта.
        """

        # Вызываем фабричный метод, чтобы получить объект-продукт.
        product = self.factory_method()

        # Далее, работаем с этим продуктом.
        result = f"Creator: The same creator's code has just worked with {product.operation()}"

        return result


"""
Конкретные Создатели переопределяют фабричный метод для того, чтобы изменить тип
результирующего продукта.
"""


class ConcreteCreator1(Creator):
    """
    Обратите внимание, что сигнатура метода по-прежнему использует тип
    абстрактного продукта, хотя фактически из метода возвращается конкретный
    продукт. Таким образом, Создатель может оставаться независимым от конкретных
    классов продуктов.
    """

    def factory_method(self) -> Product:
        return ConcreteProduct1()


class ConcreteCreator2(Creator):
    def factory_method(self) -> Product:
        return ConcreteProduct2()


class Product(ABC):
    """
    Интерфейс Продукта объявляет операции, которые должны выполнять все
    конкретные продукты.
    """

    @abstractmethod
    def operation(self) -> str:
        pass


"""
Конкретные Продукты предоставляют различные реализации интерфейса Продукта.
"""


class ConcreteProduct1(Product):
    def operation(self) -> str:
        return "{Result of the ConcreteProduct1}"


class ConcreteProduct2(Product):
    def operation(self) -> str:
        return "{Result of the ConcreteProduct2}"


def client_code(creator: Creator) -> None:
    """
    Клиентский код работает с экземпляром конкретного создателя, хотя и через
    его базовый интерфейс. Пока клиент продолжает работать с создателем через
    базовый интерфейс, вы можете передать ему любой подкласс создателя.
    """

    print(f"Client: I'm not aware of the creator's class, but it still works.\n"
          f"{creator.some_operation()}", end="")


if __name__ == "__main__":
    print("App: Launched with the ConcreteCreator1.")
    client_code(ConcreteCreator1())
    print("\n")

    print("App: Launched with the ConcreteCreator2.")
    client_code(ConcreteCreator2())

Вопрос с собеседования

Для чего нужен Decorator паттерн в Javascript? Приведите пример.

Ответ:

Javascript предоставляет удивительно гибкие возможности по работе с функциями: их можно передавать, в них можно записывать данные как в объекты, у них есть свои встроенные методы.

Шаблон декоратора динамически расширяет (украшает) поведение объекта. Возможность добавления нового поведения во время выполнения достигается с помощью объекта Decorator, который «оборачивается» вокруг исходного объекта. Несколько декораторов могут добавлять или переопределять функциональность исходного объекта.

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

Декораторы обеспечивают гибкость статически типизированных языков, позволяя вносить изменения во время выполнения, а не наследование, которое происходит во время компиляции. Однако JavaScript - это динамический язык, и возможность расширения объекта во время выполнения встроена в сам язык.

Пример использования декоратора в JavaScript:

function User(name) {
    this.name = name,
    this.print = () => console.log(this.name)
}

const jane = new User ('Jane Doe')
jane.print() // 'Jane Doe'

function DecorateWithCity(user, city) {
    user.city = city
    user.print = function() {
        console.log (${this.name} from ${this.city})
    }
}

DecorateWithCity(jane, 'NewYork')
jane.print(); //'Jane Doe from New York'


#interview

#паттерны

Введение

Сегодня мы рассмотрим паттерн проектирования "Адаптер".

Классификация

Тип: Структурный

Определение: Адаптер — это структурный паттерн проектирования, который позволяет объектам с несовместимыми интерфейсами работать вместе.
Адаптер выступает прослойкой между объектами превращая вызовы одного в понятные для другого.

Очень удобно понять адаптер на примере из жизни. Представим человеку который говорит только на французском нужно рассказать историю человеку который понимает только немецкий. Сами понять они друг друга не смогут, поэтому им понадобится переводчик, который переведёт французкий на немецкий. В данном случае переводчик выступит адаптером.

Из чего состоит и как работает паттерн адаптер

1. Клиент. Описывает бизнес логику программы. Работает с адаптером и другими объектами.


adapter = Adapter()
result = adapter.do() + "5"


2. Интерфейс с которым может работать клиентский код.


class Test1:
def do(self) -> str:
return "3"


3. Класс, который имеет нужную клиенту логику, однако клиент не может с ним общаться, так как интерфейс данного класса ему не понятен.


class Test2:
def specific_do(self) -> float:
return 3.4


4. Адаптер - класс который помогает клиенту использовать функционал незнакомого ему сервиса в правильном формате. Реализует клиентский интерфейс. Содержит ссылку на незнакомый сервис. Адаптер при получении вызовов от клиента через клиентский интерфейс и переводит их в вызовы незнакомого сервиса в правильном формате.


class Adapter(Test1, Test2):
def do(self) -> str:
return f"Translated: {round(self.specific_do())}"


Уточнение: Приложение должно использовать объект адаптера только через клиентский интерфейс. Это позволит легко создавать и изменять адаптеры в будущем.

Плюсы данного паттерна

1. Скрывает все "низкоуровневые" преобразования интерфейсов от клиента. Реализует принцип абстракция.

Минусы данного паттерна

Таковых я не обнаружил

Пример и задача

В качестве примера возьмём класс с методом do который возвращает небольшой текст. Также есть класс с методом secret_do который возвращает другую строку, зашифрованную шифром Цезаря со сдвигом 5, которая ещё и полностью развёрнута.

В виде клиента выступает функция которая постит текст в ваш блог.(Можете просто создать функцию которая выводит переданный в неё текст). Естественно она должна принимать только расшифрованный текст.

Реализуйте адаптер для второго класса, который спасёт ваш блог от зашифрованных постов.

Пример из реального кода

https://github.com/aiogram/aiogram/blob/b190bbba1915ed3b7f311a780f34723ebd6b5acd/aiogram/contrib/fsm_storage/redis.py#L280

Вот его объяснение какую задачу решает адаптер в данном случае:

Здесь адаптер дает возможность контроллеру хранилища (RedisStorage) работать с первой версией редиса, т.е. адаптирует aioredis-v1, там еще есть адаптер для aioredis-v2, но он в отличие от первой версии адаптирует только создание клиента редиса

Дополнительные материалы

https://habr.com/ru/post/85095/