Паттерн Flyweight | как экономить память и избегать дублирования кода

Flyweight («вес мухи») — один из структурных паттернов, предназначенный для оптимизации расходования памяти. Суть — разделять состояния объектов на:

➡️ Внутреннее (intrinsic): общие, неизменяемые компоненты, которые можно разделять между объектами;
➡️ Внешнее (extrinsic) — уникальные, изменяемые данные, передаваемые в объект лишь в контексте его использования.

Это позволяет хранить меньше объектов при одинаковом поведении. Стоит задуматься об этом паттерне, если требуется создать множество объектов с частично общими данными.

Пример
Представь, что у нас лес в игре из 100К деревьев. У каждого дерева есть:

— Внутреннее состояние: текстура, цвет листвы, форма кроны, высота модели. Это разделяемые каждым деревом в лесу свойства;
— Внешнее состояние: координаты на карте, текущее состояние (здорово/повалено). Такое уникально для каждого дерева.

Если бы мы для каждого дерева хранили копию текстуры и модели, мы бы потратили гигабайты памяти. Flyweight избавляет от проблемы:


Наивный вариант (без Flyweight)

class Tree:
    def __init__(self, texture, color, shape, x, y):
        self.texture = texture
        self.color = color
        self.shape = shape
        self.x = x
        self.y = y

    def draw(self):
        print(f"Drawing {self.color} {self.shape} at ({self.x}, {self.y})")
        

# создаём 100.000 деревьев, каждое хранит одинаковую текстуру и форму
forest = [
    Tree("oak_texture.png", "green", "oak", x, y)
    for x, y in zip(range(1000), range(1000))
]

Каждый объект Tree хранит одинаковые данные (oak_texture.png, "oak", "green"), хотя это лишнее.


С Flyweight

# Общие характеристики
class TreeType:
    def __init__(self, texture, color, shape):
        self.texture = texture
        self.color = color
        self.shape = shape

    def draw(self, x, y):
        # внешние данные передаются параметром
        print(f"Drawing {self.color} {self.shape} at ({x}, {y})")


# Фабрика для переиспользования типов деревьев
class TreeFactory:
    _tree_types = {}

    @classmethod
    def get_tree_type(cls, texture, color, shape):
        key = (texture, color, shape)
        if key not in cls._tree_types:
            cls._tree_types[key] = TreeType(texture, color, shape)
        return cls._tree_types[key]


# Контекст: хранит только уникальные данные (extrinsic)
class Tree:
    def __init__(self, x, y, tree_type):
        self.x = x
        self.y = y
        self.tree_type = tree_type

    def draw(self):
        self.tree_type.draw(self.x, self.y)


# создаём 100ю000 деревьев, но реально разных TreeType всего 2-3
forest = []
for i in range(100000):
    if i % 2 == 0:
        tree_type = TreeFactory.get_tree_type("oak_texture.png", "green", "oak")
    else:
        tree_type = TreeFactory.get_tree_type("pine_texture.png", "darkgreen", "pine")
    forest.append(Tree(i, i * 2, tree_type))

# Нарисуем первые пять
for tree in forest[:5]:
    tree.draw()

⚡️ У нас 100 000 объектов Tree, но всего 2 объекта `TreeType` (oak и pine). Экономия памяти огромная: вместо хранения 100.000 текстур хранится только 2.


Недостатки паттерна

— Усложнение структуры кода;
— Возможны сложности с сопровождением, особенно при неправильном управлении extrinsic;
— Повышен риск связности — общие объекты могут влиять на многие части системы .

#основы
@zen_of_python

Mixins | Что это и как использовать

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

В отличие от других ЯП (Ruby, Dart и проч.), которые поддерживают этот паттерн явно через специализированный синтаксис, Python полагается на множественное наследование как на механизм для реализации этой концепции.

Представьте, что вы создаете классы Animal и Vehicle с различными форматами данных. Реализация одной и той же функции serialize() приводит к дублированию кода:

# Плохо: Дублирование кода
class Animal:
    def __init__(self, name, species):
        self.name = name
        self.species = species
    
    def serialize(self) -> dict:
        return vars(self)

class Vehicle:
    def __init__(self, make, model, year):
        self.make = make
        self.model = model
        self.year = year
    
    def serialize(self) -> dict:  # Дублирование!
        return vars(self)

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age
    
    def serialize(self) -> dict:  # Дублирование!
        return vars(self)

Решение через примеси:

# Миксин обычно предоставляет одну конкретную функцию
class SerializableMixin:
    def serialize(self) -> dict:
        if hasattr(self, "__slots__"):
            return {
                name: getattr(self, name)
                for name in self.__slots__
            }
        else:
            return vars(self)

# Классы используют mixin без странной иерархии
class Animal:
    def __init__(self, name, species):
        self.name = name
        self.species = species

class Vehicle:
    def __init__(self, make, model, year):
        self.make = make
        self.model = model
        self.year = year

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

# Применяем mixin к нужным классам
class SerializableAnimal(Animal, SerializableMixin):
    pass

class SerializableVehicle(Vehicle, SerializableMixin):
    pass

class SerializablePerson(Person, SerializableMixin):
    pass

Когда использовать Mixins

1️⃣ Когда нужно переиспользовать функциональность между несвязанными классами
2️⃣ Когда нужно создать модульный и композируемый код
3️⃣ Когда нужно расширить функциональность сторонних библиотек


Когда НЕ стоит использовать Mixins

1️⃣ Когда функциональность специфична для одного класса
2️⃣ Когда создается слишком сложная иерархия наследования

#основы
@zen_of_python
🤓 — Если изучил досконально