Ответ
Принцип открытости/закрытости (OCP) гласит, что сущности (классы, модули) должны быть открыты для расширения, но закрыты для модификации. В Flutter это часто реализуется через композицию и абстракции.
Практический пример: система уведомлений. Допустим, у нас есть сервис, отправляющий уведомления пользователю. Вместо того чтобы модифицировать его каждый раз при добавлении нового канала, мы проектируем его, следуя OCP.
// Абстракция (открыта для расширения новыми реализациями)
abstract class NotificationService {
Future<void> send(String message);
}
// Конкретные реализации (расширяют функциональность)
class EmailNotificationService implements NotificationService {
@override
Future<void> send(String message) async {
// Логика отправки email
print('Sending email: $message');
}
}
class PushNotificationService implements NotificationService {
@override
Future<void> send(String message) async {
// Логика отправки push-уведомления через Firebase
print('Sending push: $message');
}
}
// Класс, использующий сервис (закрыт для модификации)
class UserNotifier {
final List<NotificationService> services;
UserNotifier({required this.services});
Future<void> notifyUser(String event) async {
final message = 'Event occurred: $event';
for (final service in services) {
await service.send(message);
}
}
}
// Использование
void main() async {
final notifier = UserNotifier(services: [
EmailNotificationService(),
PushNotificationService(),
// Легко добавить новый канал, не меняя UserNotifier:
// SmsNotificationService(),
]);
await notifier.notifyUser('Login from new device');
}Теперь, чтобы добавить отправку SMS, мне нужно лишь создать новый класс SmsNotificationService, реализующий NotificationService. Класс UserNotifier менять не требуется — он закрыт для модификаций.
Ответ 18+ 🔞
А, ну это же классика, ёпта! Принцип открытости/закрытости — звучит как какая-то хитрая жопа, а на деле всё просто, как три копейки. Представь, ты написал класс, и он работает. Потом приходит начальник и говорит: «А сделай-ка, чтобы оно ещё и смски слало». Ты такой: «Да щас, пару строчек допишу в старый код». А потом он: «А ещё в телегу». И ты снова лезешь в тот же файл, дописываешь, а там уже спагетти-код, в котором через месяц сам нихуя не разберёшься. Вот чтобы этого не было, умные дядьки и придумали OCP.
Смысл в чём: твой основной код должен быть закрыт от правок. То есть ты его написал, протестировал, и больше туда не лезешь. Но при этом он должен быть открыт для того, чтобы к нему можно было легко прикрутить новую фичу. Как? Да через абстракции, блядь! Через интерфейсы или абстрактные классы.
Смотри, вот тебе реальный пример из Flutter, чтобы не быть голословным. Допустим, надо слать пользователю уведомления. Самый простой и кривой способ — написать один метод, который внутри себя проверяет типы и шлёт куда надо. Но это пиздец, чувак. Каждый раз, когда добавляется новый способ отправки, тебе придётся лезть в этот метод и его менять. Это нарушение принципа. Мы так не делаем.
Вот как надо, по-взрослому:
// Абстракция (открыта для расширения новыми реализациями)
abstract class NotificationService {
Future<void> send(String message);
}
// Конкретные реализации (расширяют функциональность)
class EmailNotificationService implements NotificationService {
@override
Future<void> send(String message) async {
// Логика отправки email
print('Sending email: $message');
}
}
class PushNotificationService implements NotificationService {
@override
Future<void> send(String message) async {
// Логика отправки push-уведомления через Firebase
print('Sending push: $message');
}
}
// Класс, использующий сервис (закрыт для модификации)
class UserNotifier {
final List<NotificationService> services;
UserNotifier({required this.services});
Future<void> notifyUser(String event) async {
final message = 'Event occurred: $event';
for (final service in services) {
await service.send(message);
}
}
}
// Использование
void main() async {
final notifier = UserNotifier(services: [
EmailNotificationService(),
PushNotificationService(),
// Легко добавить новый канал, не меняя UserNotifier:
// SmsNotificationService(),
]);
await notifier.notifyUser('Login from new device');
}Видишь магию? Класс UserNotifier — он тупой как пробка и счастливый. Ему похуй, как там отправляется сообщение. Его задача — взять список сервисов и у каждого вызвать send(). Всё. Он закрыт для модификации. Ты его больше не трогаешь.
А когда тебе понадобится добавить отправку в Telegram, ты что делаешь? Ты не лезешь в UserNotifier с криками «ёбаный рот этого казино». Ты просто создаёшь новый класс TelegramNotificationService, который implements NotificationService. И подсовываешь его в список сервисов при создании UserNotifier. Всё, блядь! Функциональность расширена, а старый код даже не чихнул. Это и есть открытость для расширения.
Итог: не пихай всю логику в один класс, как последний распиздяй. Выделяй абстракцию, завись от неё, а конкретные реализации пусть приходят и уходят, как мартышлюшки. Главное, чтобы контракт (send(String message)) соблюдался. Тогда и жить проще, и код не превратится в монстра, от которого все будут охуевать.