Паттерны проектирования — это проверенные временем решения типовых проблем разработки программного обеспечения. Их история берёт начало с книги "Приёмы объектно-ориентированного проектирования. Паттерны проектирования", написанной четырьмя авторами: Эрихом Гаммой, Ричардом Хелмом, Ральфом Джонсоном и Джоном Влиссидесом. Эта группа, известная как "Банда четырёх" (Gang of Four или GoF), систематизировала и описала 23 классических паттерна проектирования, разделив их на три категории: порождающие, структурные и поведенческие. Паттерны — это не готовые фрагменты кода, а скорее концептуальные решения, которые адаптируются под конкретные задачи. Они служат общим языком для разработчиков, позволяя описывать архитектурные решения в нескольких словах без необходимости подробных объяснений. "Слушай, давай тут применим наблюдателя" — и опытные члены команды сразу понимают предлагаемую структуру.
В Python, с его философией "есть один — и желательно только один — очевидный способ сделать это", паттерны проектирования приобретают особый характер. Динамическая типизация и гибкость языка иногда позволяют реализовать классические паттерны проще, чем в строго типизированных языках вроде Java или C++. Среди множества паттернов особого внимания заслуживают три: Singleton, Factory и Observer. Они часто встречаются в проектах и решают фундаментальные проблемы организации кода.
Singleton (Одиночка) гарантирует, что класс имеет только один экземпляр, и предоставляет глобальную точку доступа к нему. Этот паттерн полезен, когда нужно контролировать доступ к общим ресурсам: базам данных, файловым системам или пулам подключений. В Python реализация Singleton может быть удивительно лаконичной благодаря метаклассам и декораторам.
Factory (Фабрика) обеспечивает интерфейс для создания объектов, позволяя подклассам изменять тип создаваемых объектов. Этот порождающий паттерн отделяет реализацию объекта от его использования, что делает систему более гибкой и менее связанной. Когда код взаимодействует с фабрикой, а не напрямую с конкретными классами, его становится проще поддерживать и тестировать.
Observer (Наблюдатель) определяет зависимость "один-ко-многим" между объектами так, что при изменении состояния одного объекта все зависимые объекты автоматически уведомляются и обновляются. Этот поведенческий паттерн широко применяется в системах с GUI, обработке событий и для реализации механизмов реактивного программирования.
Динамическая природа Python влияет на реализацию этих паттернов. В отличие от языков со статической типизацией, где структура классов фиксирована на этапе компиляции, Python позволяет изменять классы и объекты во время выполнения. Это открывает новые возможности для реализации паттернов — иногда более элегантные, иногда просто иные. Например, благодаря концепции "утиной типизации" (duck typing) в Python, паттерн Factory может быть упрощен. Вместо создания сложных иерархий классов с общими интерфейсами, можна просто предоставить объекты с определёнными методами, и Python не будет возражать, пока объекты ведут себя как ожидается.
Для Singleton Python предлагает несколько подходов: от хранения экземпляра в классовой переменной до использования метаклассов или подхода Borg (который фокусируется на разделении состояния, а не на ограничении количества экземпляров).
Observer в Python может быть реализован с использованием встроенных механизмов, таких как декораторы или с применением стороних библиотек для реактивного программирования. С появлением asyncio появились новые возможности для асинхронных уведомлений наблюдателей.
Однако не все паттерны одинаково полезны в Python. Некоторые из них, разработаные для решения ограничений статически типизированных языков, теряют свою актуальность. Как метко заметил Алекс Мартелли: "В Python неоходимо меньше паттернов, потому что сам язык даёт вам больше возможностей". Паттерны проектирования не являются панацеей или шаблоном, которому нужно слепо следовать. Применение паттерна должно быть оправдано конкретной проблемой, а не желанием "использовать паттерн ради паттерна". Чрезмерное увлечение ими может привести к излишне усложнённому коду, который трудно понять и поддерживать. В следующих разделах мы детально рассмотрим реализацию Singleton, Factory и Observer в Python, обсудим их варианты, преимущества, недостатки и практические случаи применения.
Паттерн Singleton
Паттерн Singleton (Одиночка) — один из наиболее противоречивых паттернов проектирования. Одни его восхваляют за элегантность, другие критикуют за создание глобального состояния. Суть паттерна проста: гарантировать существование только одного экземпляра класса и предоставить глобальный доступ к нему. Эта концепция выглядит несложной, но за ней скрывается множество нюансов и подводных камней.
Представьте ситуацию: вам нужно управлять соединением с базой данных в приложении. Создание множества соединений нерационально и ресурсоёмко. Логичное решение — создать единый объект-менеджер подключения, доступный всем компонентам системы. Именно такие задачи и решает Singleton.
Основные случаи применения Singleton включают:- Управление доступом к общим ресурсам (файлам, базам данных).
- Централизованное хранение конфигурации приложения.
- Кэширование данных для повышения производительности.
- Реализация логгеров и систем мониторинга.
- Координация действий в системах, где должен быть только один "дирижёр".
Реализовать Singleton в Python можно несколькими способами, и выбор конкретного метода зависит от требований проекта и личных предпочтений разработчика. Самый простой вариант — использование класса с переменной-хранилищем и методом доступа:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
| class Singleton:
_instance = None
@classmethod
def instance(cls):
if cls._instance is None:
cls._instance = cls()
return cls._instance
# Использование
first = Singleton.instance()
second = Singleton.instance()
print(first is second) # Выведет: True |
|
__new__:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
| class Singleton:
_instance = None
def __new__(cls, *args, **kwargs):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
# Использование
first = Singleton()
second = Singleton()
print(first is second) # True |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class SingletonMeta(type):
_instances = {}
def __call__(cls, *args, **kwargs):
if cls not in cls._instances:
cls._instances[cls] = super().__call__(*args, **kwargs)
return cls._instances[cls]
class Singleton(metaclass=SingletonMeta):
pass # Любая реализация класса
# Использование
first = Singleton()
second = Singleton()
print(first is second) # True |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| class Borg:
_shared_state = {}
def __init__(self):
self.__dict__ = self._shared_state
class SingletonBorg(Borg):
def __init__(self):
Borg.__init__(self)
# Инициализация атрибутов класса
# Использование
first = SingletonBorg()
second = SingletonBorg()
first.value = 42
print(second.value) # 42
print(first is second) # False, но состояние общее! |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| def singleton(cls):
instances = {}
def get_instance(*args, **kwargs):
if cls not in instances:
instances[cls] = cls(*args, **kwargs)
return instances[cls]
return get_instance
@singleton
class Configuration:
def __init__(self, filename):
self.filename = filename
self.data = {}
# Загрузка конфигурации
# Использование
config = Configuration('settings.json') |
|
1. Создание глобального состояния. Как и глобальные переменные, Singleton может привести к неявным зависимостям между компонентами и усложнить отладку.
2. Нарушение принципа единственной ответственности (SRP). Singleton совмещает две функции: основную логику класса и контроль над количеством экземпляров.
3. Сложности с тестированием. Поскольку Singleton существует как глобальное состояние, тесты могут влиять друг на друга, что усложняет модульное тестирование.
4. Устаревание. Во многих случаях существуют более гибкие способы организации кода, например, через внедрение зависимостей (DI).
Мартин Фаулер, признанный эксперт в области проектирования ПО, заметил: "Singleton — это по сути элегантный способ получить глобальную переменную в языках с объектно-ориентированной парадигмой. И глобальные переменные — это почти всегда признак проблемного дизайна".
Особую осторожность следует проявлять при использовании Singleton в многопоточных приложениях. Базовая реализация не является потокобезопасной — при параллельном выполнении двух потоков оба могут обнаружить, что экземпляр ещё не создан, и каждый создаст свой экземпляр. Чтобы сделать Singleton безопасным в многопоточной среде, можно использовать блокировки или ленивую инициализацию:
| Python | 1
2
3
4
5
6
7
8
9
10
11
| import threading
class ThreadSafeSingleton:
_instance = None
_lock = threading.Lock()
def __new__(cls):
with cls._lock:
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance |
|
| Python | 1
2
3
4
5
6
7
8
9
10
| class ThreadSafeSingleton:
_instance = None
_lock = threading.Lock()
def __new__(cls):
if cls._instance is None:
with cls._lock:
if cls._instance is None: # Повторная проверка после получения блокировки
cls._instance = super().__new__(cls)
return cls._instance |
|
| Python | 1
2
3
4
5
6
7
8
9
| # Пример использования модуля как Singleton
# singleton_module.py
_config = None
def get_config():
global _config
if _config is None:
_config = {'debug': True, 'api_key': 'secret'}
return _config |
|
Отдельного внимания заслуживает сравнительный анализ производительности различных реализаций Singleton. На практике выбор реализации может существенно влиять на быстродействие в критичных участках кода. Проведём простой бенчмарк для сравнения трёх популярных реализаций:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| import time
# 1. Базовая реализация через __new__
class SingletonNew:
_instance = None
def __new__(cls):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
# 2. Метаклассовая реализация
class SingletonMeta(type):
_instances = {}
def __call__(cls, *args, **kwargs):
if cls not in cls._instances:
cls._instances[cls] = super().__call__(*args, **kwargs)
return cls._instances[cls]
class SingletonWithMeta(metaclass=SingletonMeta):
pass
# 3. Реализация Borg
class SingletonBorg:
_shared_state = {}
def __init__(self):
self.__dict__ = self._shared_state
# Бенчмарк
def benchmark(cls, n=1000000):
start = time.time()
for _ in range(n):
instance = cls()
end = time.time()
return end - start
print(f"__new__: {benchmark(SingletonNew)}")
print(f"Metaclass: {benchmark(SingletonWithMeta)}")
print(f"Borg: {benchmark(SingletonBorg)}") |
|
__new__ наиболее производителен, а метаклассовый подход немного медленнее. Паттерн Borg зачастую оказывается самым ресурсоёмким из-за копирования словаря __dict__ при каждом создании экземпляра. Однако на практике эти различия заметны только при создании тысяч экземпляров в секунду, что редко встречается для Singleton. Поэтому выбор обычно обусловлен не столько производительностью, сколько удобством и понятностью кода.
При работе над веб-приложениями Singleton часто используется для управления соединениями с базами данных или внешними API. Рассмотрим пример реализации менеджера подключения к Redis для веб-приложения:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| import redis
class RedisClient:
_instance = None
_is_initialized = False
def __new__(cls, *args, **kwargs):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
def __init__(self, host='localhost', port=6379, db=0):
if not self._is_initialized:
self._conn = redis.Redis(host=host, port=port, db=db)
self._is_initialized = True
def get(self, key):
return self._conn.get(key)
def set(self, key, value):
return self._conn.set(key, value)
# Использование в Flask-приложении
from flask import Flask, request
app = Flask(__name__)
redis_client = RedisClient()
@app.route('/cache/<key>')
def get_cache(key):
value = redis_client.get(key)
if value:
return value
return "No data found", 404 |
|
_is_initialized в методе __init__. Это важный момент, поскольку __init__ вызывается при каждом вызове конструктора, даже если __new__ возвращает существующий экземпляр. Без этой проверки соединение с Redis будет пересоздаваться при каждом вызове RedisClient(). Следует отметить, что использование Singleton для подобных задач — не всегда лучший подход. Современные фреймворки для веб-разработки, такие как Flask или Django, предоставляют механизмы внедрения зависимостей и управления ресурсами, которые могут быть более подходящими.
Ещё один интересный подход к реализации Singleton — использование дескрипторов. Дескрипторы контролируют доступ к атрибутам объекта и могут быть использованы для создания "ленивых" Singleton:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| class LazyProperty:
def __init__(self, func):
self.func = func
self.name = func.__name__
def __get__(self, instance, owner):
if instance is None:
return self
value = self.func(instance)
setattr(instance, self.name, value)
return value
class Config:
@LazyProperty
def database(self):
print("Initializing database connection...")
# Имитация дорогостоящей операции
import time
time.sleep(1)
return {"host": "localhost", "port": 5432}
# Использование
conf = Config()
# При первом обращении вызовется метод database
print(conf.database) # Выведет информацию и данные
# При повторном обращении используется сохранённое значение
print(conf.database) # Выведет только данные |
|
Ещё один нестандартный, но эффективный способ создания Singleton — использование перечислений (enum) из стандартной библиотеки Python:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| from enum import Enum
class Singleton(Enum):
INSTANCE = None
def __call__(self):
return self.value
@staticmethod
def configure(value):
Singleton.INSTANCE = value
# Использование
Singleton.configure({"api_key": "secret"})
config = Singleton.INSTANCE
print(config) # {'api_key': 'secret'} |
|
В заключении этого раздела стоит упомянуть, что выбор конкретной реализации Singleton должен основываться на особеностях проекта, ваших предпочтениях и требованиях к производительности. Несмотря на критику, правильно применённый Singleton может значительно упростить архитектуру приложения и сделать код более понятным. Главное помнить о потенциальных проблемах и использовать его только когда действительно необходима глобальная точка доступа к уникальному ресурсу.
паттерн Observer
Гуру программирования, просветите по данному сабжу (расскажите человеческим языком/направьте... паттерн Observer(непонятна строка кода)
Непонятный код в одном месте. Хотелось бы узнать смысл и для чего его тут написали.
class... паттерн наблюдатель (observer)
Помогите разобраться. Нашел в интернете несколько примеров но по ним я не могу понять как они... Реализация паттерна Observer от Microsoft
Совершенно случайно, нашел что интерфейс для данного паттерна создали за нас. Может кому-то...
Паттерн Factory
Паттерн Factory (Фабрика) — один из самых практичных и широко используемых порождающих паттернов. В отличие от Singleton, который часто подвергается критике, Factory гораздо меньше противоречий вызывает среди разработчиков. Его главная задача — создавать объекты без привязки к конкретным классам, что делает код более гибким и устойчивым к изменениям.
Представьте, что вы пишете графический редактор. Приложение должно создавать разные геометрические фигуры: круги, квадраты, треугольники. Без паттерна Factory код может выглядеть примерно так:
| Python | 1
2
3
4
5
6
7
8
| if shape_type == "круг":
shape = Circle()
elif shape_type == "квадрат":
shape = Square()
elif shape_type == "треугольник":
shape = Triangle()
else:
raise ValueError("Неизвестный тип фигуры") |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| class ShapeFactory:
def create_shape(self, shape_type):
if shape_type == "круг":
return Circle()
elif shape_type == "квадрат":
return Square()
elif shape_type == "треугольник":
return Triangle()
else:
raise ValueError("Неизвестный тип фигуры")
# Использование
factory = ShapeFactory()
my_circle = factory.create_shape("круг")
my_square = factory.create_shape("квадрат") |
|
Существует несколько вариаций паттерна Factory, каждая со своими особенностями и областями применения:
1. Simple Factory (Простая фабрика) — не является каноническим паттерном из книги GoF, но широко используется из-за своей простоты. Представляет собой класс с методом, который создаёт объекты на основе входных параметров, как в примере выше.
2. Factory Method (Фабричный метод) — определяет интерфейс для создания объектов, но позволяет подклассам решать, какие классы инстанцировать. Структура включает абстрактный создатель с абстрактным фабричным методом и конкретные создатели, реализующие этот метод.
3. Abstract Factory (Абстрактная фабрика) — предоставляет интерфейс для создания семейств взаимосвязанных объектов без указания их конкретных классов. Используется, когда система должна работать с разными наборами объектов.
Рассмотрим реализацию Factory Method в Python:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| from abc import ABC, abstractmethod
class Animal(ABC):
@abstractmethod
def speak(self):
pass
class Dog(Animal):
def speak(self):
return "Гав!"
class Cat(Animal):
def speak(self):
return "Мяу!"
class AnimalFactory(ABC):
@abstractmethod
def create_animal(self):
pass
class DogFactory(AnimalFactory):
def create_animal(self):
return Dog()
class CatFactory(AnimalFactory):
def create_animal(self):
return Cat()
# Использование
dog_factory = DogFactory()
dog = dog_factory.create_animal()
print(dog.speak()) # Гав!
cat_factory = CatFactory()
cat = cat_factory.create_animal()
print(cat.speak()) # Мяу! |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
| from abc import ABC, abstractmethod
# Абстрактные продукты
class Button(ABC):
@abstractmethod
def render(self):
pass
class Checkbox(ABC):
@abstractmethod
def render(self):
pass
# Конкретные продукты для Windows
class WindowsButton(Button):
def render(self):
return "Отрисовка кнопки в стиле Windows"
class WindowsCheckbox(Checkbox):
def render(self):
return "Отрисовка чекбокса в стиле Windows"
# Конкретные продукты для MacOS
class MacOSButton(Button):
def render(self):
return "Отрисовка кнопки в стиле MacOS"
class MacOSCheckbox(Checkbox):
def render(self):
return "Отрисовка чекбокса в стиле MacOS"
# Абстрактная фабрика
class GUIFactory(ABC):
@abstractmethod
def create_button(self):
pass
@abstractmethod
def create_checkbox(self):
pass
# Конкретные фабрики
class WindowsFactory(GUIFactory):
def create_button(self):
return WindowsButton()
def create_checkbox(self):
return WindowsCheckbox()
class MacOSFactory(GUIFactory):
def create_button(self):
return MacOSButton()
def create_checkbox(self):
return MacOSCheckbox()
# Клиентский код
def create_ui(factory):
button = factory.create_button()
checkbox = factory.create_checkbox()
return button.render(), checkbox.render()
# Использование
windows_ui = create_ui(WindowsFactory())
macos_ui = create_ui(MacOSFactory())
print(windows_ui[0]) # Отрисовка кнопки в стиле Windows |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| def create_dog():
return Dog()
def create_cat():
return Cat()
# Словарь фабричных функций
animal_factories = {
"dog": create_dog,
"cat": create_cat
}
# Использование
animal = animal_factories["dog"]()
print(animal.speak()) # Гав! |
|
| Python | 1
2
3
4
5
6
7
8
| animal_factories = {
"dog": Dog,
"cat": Cat
}
# Использование
animal = animal_factories["dog"]()
print(animal.speak()) # Гав! |
|
Factory часто используется в фреймворках и библиотеках. Например, в Django модуль django.forms использует Factory для создания различных типов полей формы. В SQLAlchemy, популярной ORM для Python, Factory применяется для создания соединений с разными базами данных.
Рассмотрим более практичный пример — систему платежей, где Factory используется для выбора платёжного метода:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| class PaymentProcessor(ABC):
@abstractmethod
def process_payment(self, amount):
pass
class CreditCardProcessor(PaymentProcessor):
def process_payment(self, amount):
print(f"Обработка платежа банковской картой на сумму {amount}")
# Логика обработки платежа картой
class PayPalProcessor(PaymentProcessor):
def process_payment(self, amount):
print(f"Обработка платежа через PayPal на сумму {amount}")
# Логика обработки платежа через PayPal
class BitcoinProcessor(PaymentProcessor):
def process_payment(self, amount):
print(f"Обработка платежа Bitcoin на сумму {amount}")
# Логика обработки платежа через Bitcoin
class PaymentProcessorFactory:
@staticmethod
def get_processor(payment_type):
if payment_type == "credit_card":
return CreditCardProcessor()
elif payment_type == "paypal":
return PayPalProcessor()
elif payment_type == "bitcoin":
return BitcoinProcessor()
else:
raise ValueError(f"Неподдерживаемый метод оплаты: {payment_type}")
# Клиентский код
def process_payment(payment_type, amount):
processor = PaymentProcessorFactory.get_processor(payment_type)
processor.process_payment(amount)
# Использование
process_payment("credit_card", 100)
process_payment("paypal", 50) |
|
Однако статический метод get_processor всё ещё содержит условные операторы, которые нужно будет изменять при добавлении новых процессоров. Улучшим дизайн, используя регистрацию обработчиков:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| class PaymentProcessorFactory:
_processors = {}
@classmethod
def register_processor(cls, payment_type, processor_class):
cls._processors[payment_type] = processor_class
@classmethod
def get_processor(cls, payment_type):
processor_class = cls._processors.get(payment_type)
if not processor_class:
raise ValueError(f"Неподдерживаемый метод оплаты: {payment_type}")
return processor_class()
# Регистрация обработчиков
PaymentProcessorFactory.register_processor("credit_card", CreditCardProcessor)
PaymentProcessorFactory.register_processor("paypal", PayPalProcessor)
PaymentProcessorFactory.register_processor("bitcoin", BitcoinProcessor)
# Использование
process_payment("credit_card", 100) |
|
Такой регистрационный механизм особенно удобен в плагинных системах, где новые компоненты могут добавляться без изменения основного кода. Например, фреймворк Flask использует похожий подход для регистрации обработчиков URL-путей.
Теперь более детально рассмотрим различия между Factory Method и Abstract Factory, которые часто вызывают путаницу. Главное отличие заключается в уровне абстракции:- Factory Method фокусируется на создании одного типа объектов через наследование. Конкретные создатели переопределяют фабричный метод для изменения типа создаваемого продукта.
- Abstract Factory предоставляет интерфейс для создания семейств взаимосвязанных объектов без привязки к конкретным классам.
Представим, что мы разрабатываем игру с разными типами персонажей и оружия:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
| # Factory Method для создания персонажей
class CharacterFactory(ABC):
@abstractmethod
def create_character(self):
pass
def equip_character(self):
character = self.create_character() # Вызов абстрактного метода
print(f"Экипировка персонажа {character.name}")
return character
class WarriorFactory(CharacterFactory):
def create_character(self):
return Warrior("Могучий воин")
class MageFactory(CharacterFactory):
def create_character(self):
return Mage("Мудрый маг")
# Abstract Factory для создания наборов предметов
class ItemFactory(ABC):
@abstractmethod
def create_weapon(self):
pass
@abstractmethod
def create_armor(self):
pass
class WarriorItemFactory(ItemFactory):
def create_weapon(self):
return Sword("Экскалибур")
def create_armor(self):
return HeavyArmor("Стальная броня")
class MageItemFactory(ItemFactory):
def create_weapon(self):
return Staff("Посох архимага")
def create_armor(self):
return Robe("Мантия мудреца") |
|
Паттерн Factory широко применяется в тестировании ПО, особенно в сочетании с mock-объектами. Он позволяет легко подменять реальные объекты их тестовыми аналогами. Рассмотрим пример использования фабрики для тестирования API-клиента:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| import unittest
from unittest import mock
class APIClient:
def __init__(self, api_key):
self.api_key = api_key
def get_data(self, endpoint):
# В реальности здесь был бы HTTP-запрос
pass
class APIClientFactory:
@staticmethod
def create(api_key=None, mock_data=None):
if mock_data is not None:
client = mock.Mock(spec=APIClient)
client.get_data.return_value = mock_data
return client
return APIClient(api_key)
class TestDataProcessor(unittest.TestCase):
def test_process_data(self):
# Создаём мок-клиент с предопределёнными данными
mock_data = {"status": "success", "data": [1, 2, 3]}
client = APIClientFactory.create(mock_data=mock_data)
processor = DataProcessor(client)
result = processor.process()
self.assertEqual(result, [2, 4, 6]) # Предполагаем, что процессор удваивает значения |
|
Фабрики играют важную роль в реализации принципа инверсии зависимостей (Dependency Inversion Principle) — одного из принципов SOLID. Согласно этому принципу, высокоуровневые модули не должны зависеть от низкоуровневых модулей, а оба типа модулей должны зависеть от абстракций. В крупных Python-проектах фабрики часто используются в контейнерах внедрения зависимостей (DI-контейнерах):
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| class DIContainer:
def __init__(self):
self._factories = {}
def register(self, interface, factory):
self._factories[interface] = factory
def resolve(self, interface):
factory = self._factories.get(interface)
if not factory:
raise ValueError(f"No factory registered for {interface}")
return factory()
# Использование
container = DIContainer()
container.register(Database, lambda: PostgreSQLDatabase("localhost", "user", "pass"))
container.register(Logger, lambda: FileLogger("/var/log/app.log"))
# В приложении
class UserService:
def __init__(self, container):
self.db = container.resolve(Database)
self.logger = container.resolve(Logger)
def create_user(self, user_data):
self.logger.log("Creating user")
self.db.insert("users", user_data) |
|
Паттерн Factory часто комбинируется с другими паттернами проектирования для решения более сложных задач. Одна из распространенных комбинаций — Factory + Strategy:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
| from abc import ABC, abstractmethod
# Strategy Pattern
class SortStrategy(ABC):
@abstractmethod
def sort(self, data):
pass
class QuickSort(SortStrategy):
def sort(self, data):
print("Сортировка данных алгоритмом быстрой сортировки")
return sorted(data) # На самом деле, это не quicksort, но для примера сойдёт
class MergeSort(SortStrategy):
def sort(self, data):
print("Сортировка данных алгоритмом сортировки слиянием")
return sorted(data)
# Factory Pattern
class SortStrategyFactory:
_strategies = {}
@classmethod
def register_strategy(cls, name, strategy_class):
cls._strategies[name] = strategy_class
@classmethod
def get_strategy(cls, name):
strategy_class = cls._strategies.get(name)
if not strategy_class:
raise ValueError(f"Unknown strategy: {name}")
return strategy_class()
# Регистрация стратегий
SortStrategyFactory.register_strategy("quick", QuickSort)
SortStrategyFactory.register_strategy("merge", MergeSort)
# Использование
class DataSorter:
def __init__(self, strategy_name):
self.strategy = SortStrategyFactory.get_strategy(strategy_name)
def sort(self, data):
return self.strategy.sort(data)
# Клиентский код
sorter = DataSorter("quick")
sorted_data = sorter.sort([3, 1, 4, 1, 5, 9, 2, 6]) |
|
DataSorter использует выбранную стратегию для выполнения работы.
Factory также хорошо сочетается с паттерном Builder, когда процесс создания объекта сложен и требует нескольких шагов:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| class Computer:
def __init__(self):
self.cpu = None
self.memory = None
self.storage = None
self.gpu = None
def __str__(self):
return f"Computer(cpu={self.cpu}, memory={self.memory}GB, storage={self.storage}GB, gpu={self.gpu})"
class ComputerBuilder:
def __init__(self):
self.computer = Computer()
def configure_cpu(self, cpu):
self.computer.cpu = cpu
return self
def configure_memory(self, memory):
self.computer.memory = memory
return self
def configure_storage(self, storage):
self.computer.storage = storage
return self
def configure_gpu(self, gpu):
self.computer.gpu = gpu
return self
def build(self):
return self.computer
class ComputerBuilderFactory:
@staticmethod
def create_gaming_builder():
return ComputerBuilder().configure_cpu("Intel i9").configure_memory(32).configure_storage(1000).configure_gpu("RTX 3080")
@staticmethod
def create_office_builder():
return ComputerBuilder().configure_cpu("Intel i5").configure_memory(16).configure_storage(512).configure_gpu("Integrated")
# Использование
gaming_pc = ComputerBuilderFactory.create_gaming_builder().build()
office_pc = ComputerBuilderFactory.create_office_builder().build()
print(gaming_pc) # Computer(cpu=Intel i9, memory=32GB, storage=1000GB, gpu=RTX 3080) |
|
Паттерн Observer
Паттерн Observer (Наблюдатель) относится к поведенческим паттернам проектирования и решает одну из фундаментальных проблем программной архитектуры — как установить зависимость "один-ко-многим" между объектами так, чтобы при изменении состояния одного объекта все зависимые от него объекты автоматически уведомлялись и обновлялись.
Представьте, что вы разрабатываете приложение для отображения биржевых данных. У вас есть источник котировок (субъект) и несколько компонентов пользовательского интерфейса: график, таблица сделок, лента новостей (наблюдатели). Все эти компоненты должны обновляться при поступлении новых котировок. Традиционное решение с постоянным опросом источника неэффективно. Вместо этого Observer позволяет установить механизм подписки, где источник уведомляет заинтересованные компоненты о каждом изменении.
Основные участники паттерна Observer:
Subject (Субъект) — объект, который содержит состояние и уведомляет наблюдателей об изменениях,
Observer (Наблюдатель) — интерфейс или абстрактный класс, определяющий метод обновления, который вызывается субъектом,
ConcreteSubject (Конкретный субъект) — реализация субъекта, которая отслеживает своё состояние и уведомляет наблюдателей,
ConcreteObserver (Конкретный наблюдатель) — реализация наблюдателя, которая получает уведомления от субъекта и реагирует на них.
Классическая реализация паттерна Observer в Python может выглядеть так:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
| from abc import ABC, abstractmethod
class Observer(ABC):
@abstractmethod
def update(self, subject):
pass
class Subject:
def __init__(self):
self._observers = []
self._state = None
def attach(self, observer):
if observer not in self._observers:
self._observers.append(observer)
def detach(self, observer):
self._observers.remove(observer)
def notify(self):
for observer in self._observers:
observer.update(self)
@property
def state(self):
return self._state
@state.setter
def state(self, state):
self._state = state
self.notify()
# Конкретные реализации
class ConcreteObserverA(Observer):
def update(self, subject):
print(f"ConcreteObserverA: Получено обновление - {subject.state}")
class ConcreteObserverB(Observer):
def update(self, subject):
print(f"ConcreteObserverB: Реагирую на новое значение: {subject.state}")
# Использование
subject = Subject()
observer_a = ConcreteObserverA()
observer_b = ConcreteObserverB()
subject.attach(observer_a)
subject.attach(observer_b)
subject.state = 123 # Автоматически уведомит всех наблюдателей |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| class Event:
def __init__(self):
self._handlers = []
def add_handler(self, handler):
self._handlers.append(handler)
return handler # Позволяет использовать как декоратор
def remove_handler(self, handler):
self._handlers.remove(handler)
def fire(self, *args, **kwargs):
for handler in self._handlers:
handler(*args, **kwargs)
# Пример использования
class StockPrice:
def __init__(self, symbol):
self.symbol = symbol
self._price = 0
self.price_changed = Event()
@property
def price(self):
return self._price
@price.setter
def price(self, new_price):
if self._price != new_price:
self._price = new_price
self.price_changed.fire(self.symbol, new_price)
# Наблюдатели как функции
def price_logger(symbol, price):
print(f"[LOG] Цена {symbol} изменилась на {price}")
def price_analyzer(symbol, price):
print(f"[ANALYSIS] Нужно купить {symbol}" if price < 50 else f"[ANALYSIS] Нужно продать {symbol}")
# Подписка наблюдателей
stock = StockPrice("AAPL")
stock.price_changed.add_handler(price_logger)
stock.price_changed.add_handler(price_analyzer)
# Изменение цены вызовет уведомление наблюдателей
stock.price = 45.5
stock.price = 75.2 |
|
Другой способ реализации Observer — использование callback-функций, что особенно удобно для обработки событий:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| class StockMarket:
def __init__(self):
self._callbacks = {}
self._stock_prices = {}
def register(self, symbol, callback):
if symbol not in self._callbacks:
self._callbacks[symbol] = []
self._callbacks[symbol].append(callback)
def unregister(self, symbol, callback):
self._callbacks[symbol].remove(callback)
def update_price(self, symbol, price):
self._stock_prices[symbol] = price
if symbol in self._callbacks:
for callback in self._callbacks[symbol]:
callback(symbol, price)
# Использование
market = StockMarket()
# Подписка на конкретные акции
market.register("AAPL", lambda s, p: print(f"Apple сейчас стоит {p}"))
market.register("GOOGL", lambda s, p: print(f"Google сейчас стоит {p}"))
# Один наблюдатель может следить за несколькими акциями
def universal_handler(symbol, price):
print(f"Обновление цены {symbol}: {price}")
market.register("AAPL", universal_handler)
market.register("GOOGL", universal_handler)
# Обновление цен вызовет все соответствующие обработчики
market.update_price("AAPL", 150.75)
market.update_price("GOOGL", 2850.30) |
|
Однако у паттерна Observer есть и недостатки. Основной из них — потенциальная проблема "забытых подписчиков". Если наблюдатель больше не нужен, но не был отписан от субъекта, это может привести к утечке памяти. Наблюдатель продолжает получать уведомления и занимать ресурсы системы. Для решения этой проблемы часто используются слабые ссылки (weak references) или автоматическая отписка в деструкторе. Другая потенциальная проблема — непредсказуемый порядок уведомлений. Если несколько наблюдателей зависят друг от друга или от определённого порядка обновлений, стандартная реализация Observer может не подойти, и потребуется дополнительная логика.
В Python есть ещё одна особенность, которая делает Observer более удобным — возможность использования генераторов и корутин для создания потоков событий:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| import asyncio
from collections import defaultdict
class AsyncEventEmitter:
def __init__(self):
self._subscribers = defaultdict(set)
def subscribe(self, event_name, callback):
self._subscribers[event_name].add(callback)
def unsubscribe(self, event_name, callback):
self._subscribers[event_name].discard(callback)
async def emit(self, event_name, *args, **kwargs):
for callback in list(self._subscribers[event_name]):
try:
result = callback(*args, **kwargs)
if asyncio.iscoroutine(result):
await result
except Exception as e:
print(f"Ошибка в обработчике {callback.__name__}: {e}") |
|
Интересный пример использования Observer можно увидеть в системах реактивного программирования. Библиотека RxPy (Reactive Extensions for Python) предлагает мощную реализацию паттерна, ориентированную на потоки данных:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| from rx import create
from rx.subject import Subject
import rx.operators as ops
# Создание потока событий с ценами акций
price_stream = Subject()
# Определение наблюдателей с разной логикой
price_stream.pipe(
ops.filter(lambda price: price > 100)
).subscribe(lambda price: print(f"Высокая цена: {price}"))
price_stream.pipe(
ops.map(lambda price: "Покупать" if price < 50 else "Продавать"),
ops.distinct_until_changed() # Реагировать только на изменения рекомендации
).subscribe(lambda action: print(f"Рекомендация: {action}"))
# Эмиляция изменений цен
for price in [45, 55, 120, 30, 110]:
price_stream.on_next(price) |
|
Subject действует как наблюдаемый объект, на который подписаны наблюдатели. Операторы трансформации (filter, map) позволяют гибко обрабатывать поток данных перед доставкой наблюдателям.
Реализация Observer особенно элегантна в GUI-приложениях, где компоненты интерфейса должны реагировать на изменения данных. Рассмотрим простой пример с использованием Tkinter:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
| import tkinter as tk
from tkinter import ttk
class TemperatureModel:
def __init__(self):
self._temp_celsius = 0
self._observers = []
def attach(self, observer):
self._observers.append(observer)
def notify(self):
for observer in self._observers:
observer.update(self)
@property
def temp_celsius(self):
return self._temp_celsius
@temp_celsius.setter
def temp_celsius(self, value):
self._temp_celsius = value
self.notify()
@property
def temp_fahrenheit(self):
return self._temp_celsius * 9/5 + 32
class TemperatureView:
def __init__(self, master, model):
self.model = model
self.model.attach(self)
self.frame = ttk.Frame(master, padding="10")
self.frame.pack(fill=tk.BOTH, expand=True)
self.celsius_var = tk.StringVar()
self.fahrenheit_var = tk.StringVar()
ttk.Label(self.frame, text="Цельсий:").grid(row=0, column=0)
celsius_entry = ttk.Entry(self.frame, textvariable=self.celsius_var)
celsius_entry.grid(row=0, column=1)
celsius_entry.bind("<Return>", self.celsius_changed)
ttk.Label(self.frame, text="Фаренгейт:").grid(row=1, column=0)
ttk.Entry(self.frame, textvariable=self.fahrenheit_var, state="readonly").grid(row=1, column=1)
self.update(model) # Начальное обновление
def celsius_changed(self, event):
try:
self.model.temp_celsius = float(self.celsius_var.get())
except ValueError:
pass
def update(self, model):
self.celsius_var.set(f"{model.temp_celsius:.1f}")
self.fahrenheit_var.set(f"{model.temp_fahrenheit:.1f}")
# Создание и запуск приложения
root = tk.Tk()
root.title("Конвертер температур")
model = TemperatureModel()
view = TemperatureView(root, model)
root.mainloop() |
|
TemperatureModel выступает как субъект, а TemperatureView — как наблюдатель. При изменении температуры в модели все представления автоматически обновляются. Такая архитектура позволяет легко добавлять новые представления без изменения модели.
Для более масштабных приложений полезно использовать встроенный модуль concurrent.futures в сочетании с Observer:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| import time
import random
from concurrent.futures import ThreadPoolExecutor
from threading import Lock
class DataSource:
def __init__(self):
self._observers = []
self._lock = Lock()
def register(self, observer):
with self._lock:
self._observers.append(observer)
def unregister(self, observer):
with self._lock:
self._observers.remove(observer)
def notify(self, data):
with self._lock:
observers = list(self._observers) # Создаём копию для безопасного перебора
with ThreadPoolExecutor(max_workers=10) as executor:
for observer in observers:
executor.submit(observer.update, data)
def start_producing(self):
while True:
data = random.randint(1, 100)
self.notify(data)
time.sleep(1) |
|
В распределённых системах паттерн Observer часто реализуется через брокеры сообщений, такие как RabbitMQ или Kafka. Концепция "публикация-подписка" (pub-sub) — это по сути Observer, масштабированный для работы в распределённой среде:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
| import pika
import json
# Издатель (Subject)
def publish_message(exchange, routing_key, message):
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.exchange_declare(exchange=exchange, exchange_type='topic')
channel.basic_publish(
exchange=exchange,
routing_key=routing_key,
body=json.dumps(message)
)
connection.close()
# Подписчик (Observer)
def setup_subscriber(exchange, routing_keys, callback):
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.exchange_declare(exchange=exchange, exchange_type='topic')
result = channel.queue_declare('', exclusive=True)
queue_name = result.method.queue
for key in routing_keys:
channel.queue_bind(
exchange=exchange,
queue=queue_name,
routing_key=key
)
channel.basic_consume(
queue=queue_name,
on_message_callback=lambda ch, method, properties, body: callback(json.loads(body)),
auto_ack=True
)
print("Ожидание сообщений. Для выхода нажмите CTRL+C")
channel.start_consuming() |
|
Современные фреймворки для построения веб-приложений на Python, такие как Django Channels и Quart, также используют концепции, схожие с Observer, для обработки WebSocket-соединений и реализации реального времени обновления:
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| # Пример с Django Channels
class StockConsumer(AsyncWebsocketConsumer):
async def connect(self):
await self.channel_layer.group_add("stock_updates", self.channel_name)
await self.accept()
async def disconnect(self, close_code):
await self.channel_layer.group_discard("stock_updates", self.channel_name)
async def stock_update(self, event):
# Отправка обновления клиенту
await self.send(text_data=json.dumps({
"symbol": event["symbol"],
"price": event["price"]
}))
# Где-то в коде при получении обновления цены:
async def broadcast_stock_price(symbol, price):
channel_layer = get_channel_layer()
await channel_layer.group_send(
"stock_updates",
{
"type": "stock_update",
"symbol": symbol,
"price": price
}
) |
|
broadcast_stock_price играет роль субъекта, уведомляющего всех подписчиков о изменениях.
Паттерн Observer универсален и адаптивен. От простых локальных приложений до сложных распределённых систем — его основные принципы остаются неизменными, обеспечивая гибкое взаимодействие между компонентами при минимальной связанности кода.
Практические рекомендации
Выбор правильного паттерна проектирования для конкретной задачи — настоящее искусство, требующее как теоретических знаний, так и практического опыта. При этом важно помнить, что паттерны — не самоцель, а инструмент решения конкретных проблем. Не стоит стремиться применять их везде только потому, что "так правильно".
Для выбора подходящего паттерна рекомендуется следовать нескольким принципам:
1. Сначала чётко определите проблему, которую пытаетесь решить. Часто разработчики начинают с паттерна, а затем пытаются "подогнать" задачу под него.
2. Придерживайтесь принципа YAGNI (You Aren't Gonna Need It) — не усложняйте архитектуру в расчёте на будущие требования, которых может не быть.
3. Оцените стоимость внедрения паттерна в терминах сложности, поддерживаемости и производительности. Иногда простое решение лучше элегантного, но сложного.
При работе с Singleton стоит учитывать следующие моменты:
| Python | 1
2
3
4
5
6
7
8
9
10
| # Хорошая практика: явное указание на то, что класс является синглтоном
class DBConnection:
"""Синглтон для управления подключением к базе данных."""
_instance = None
@classmethod
def get_instance(cls):
if cls._instance is None:
cls._instance = cls()
return cls._instance |
|
| Python | 1
2
3
4
5
| # Хорошая альтернатива Singleton для конфигурации
config = {'debug': True, 'timeout': 30}
# В разных модулях:
from myapp.config import config |
|
1. Используйте описательные имена методов вместо строковых идентификаторов:
| Python | 1
2
3
4
5
| # Вместо:
shape = factory.create("circle")
# Лучше:
shape = factory.create_circle() |
|
| Python | 1
2
3
4
5
6
7
8
9
10
| creators = {
'circle': create_circle,
'rectangle': create_rectangle
}
def create_shape(shape_type, *args):
creator = creators.get(shape_type)
if not creator:
raise ValueError(f"Unknown shape: {shape_type}")
return creator(*args) |
|
1. Не забывайте отписывать наблюдателей, когда они больше не нужны, чтобы избежать утечек памяти и лишних вычислений:
| Python | 1
2
3
4
5
6
7
8
9
10
11
| class Observer:
def __init__(self, subject):
self.subject = subject
subject.attach(self)
def __del__(self):
# Автоматическая отписка при уничтожении
try:
self.subject.detach(self)
except:
pass |
|
| Python | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| from typing import Callable, List
class Event:
def __init__(self):
self._handlers: List[Callable] = []
def __iadd__(self, handler):
self._handlers.append(handler)
return self
def __isub__(self, handler):
self._handlers.remove(handler)
return self
def __call__(self, *args, **kwargs):
for handler in self._handlers:
handler(*args, **kwargs) |
|
| Python | 1
2
3
4
5
6
7
8
9
| # Вместо сложной фабрики для тривиальных случаев:
class LoggerFactory:
@staticmethod
def create_file_logger(filename):
return FileLogger(filename)
# Лучше использовать простые функции:
def create_file_logger(filename):
return FileLogger(filename) |
|
| Bash | 1
2
| # Пример использования pylint для поиска потенциальных мест для рефакторинга
pylint --load-plugins=pylint_design_patterns myproject/ |
|
Wily — для отслеживания сложности кода и выявления мест, требующих рефакторинга,
Radon — для измерения цикломатической сложности и других метрик кода,
PyCharm — имеет встроенную поддержку обнаружения и рефакторинга к паттернам проектирования.
При внедрении паттернов в существующий проект следуйте подходу постепенного рефакторинга. Начинайте с небольших, изолированных частей кода и последовательно расширяйте применение паттернов, оценивая их эффективность.
Помните, что знание паттернов проектирования — мощный инструмент, но не универсальное решение всех проблем. В духе Дзен Python: "Практичность важнее безупречности". Иногда простой, даже слегка грязный код, справляющийся с задачей, лучше элегантной абстракции, которую сложно понять и поддерживать. Наконец, создавайте документацию, объясняющую, почему был выбран тот или иной паттерн. Явные комментарии в коде помогут будущим разработчикам (включая вас самих через несколько месяцев) понять логику принятых решений и избежать ненужных переделок.
python и паттерны
добрый вечер,подскажите как в игру шашки добавить паттерны
Буду очень благодарен!!!
from... Abstract Factory(java)
Как на тему: "справочная служба театра и цирка" использовать паттерн Abstract Factory? Factory Method
Начал изучать шаблоны проектирования. А именно с порождающих паттернов. И тут при разборе шаблона... Создать словарь, связав его с переменной factory, и заполните данными
1. Создать словарь, связав его с переменной factory, и заполните данными,
которые бы отражали... Создать словарь, связав его с переменной factory, и заполните данными
Помогите исправить код по таким условиям:
1. Создать словарь, связав его с переменной factory,... Чем плох паттерн проектирования Singleton?
Доброго, программисты.
Вот многие пишут, что этот паттерн плох сам по себе.
Но я не пойму почему?... Правильно ли реализован Singleton для подключения к базе
Скажите пож-та правильно ли реализован Singleton для подключения к базе? Подключение к базе должно... Паттерн «Singleton» для настроек программы
Добрый день.
Возник такой вопрос, как лучше организовать использование настроек.
Вот допустим,... Singleton
Добрый вечер. Столкнулся со следующей проблемой. Есть QTabWidget. В нём есть несколько вкладок. В... Создание "Singleton" так, чтобы при повторной инициализации нельзя было измениять атрибуты объекта
Всем привет, для одной задачи потребовался singleton, но такой, чтобы не просто второго объекта не... Паттерны (шаблоны) проектирования
Доброго время суток. Надо реальная программа с описанием используемых паттернов в ней. Можите... Какие паттерны вы используете чаще всего?
Я не сильно знаком с паттернами. Более-менее представляю себе MVC, Фабрику, может еще парочку. Хочу...
|
