Принцип подстановки Барбары Лисков: основа правильного полиморфизма в программировании 🌟
Привет, друзья! Сегодня мы поговорим о третьей букве в акрониме SOLID - L, которая означает принцип подстановки Лисков 🤔. Этот принцип гласит, что объекты подклассов должны быть взаимозаменяемы с объектами их базового класса без нарушения корректности работы программы 💻.
Почему это важно? 🤔 Нарушение LSP приводит к непредсказуемому поведению программы, код начинает проверять типы объектов с помощью if/else или is, что противоречит принципу открытости/закрытости и делает систему хрупкой 🌪. Соблюдение LSP гарантирует, что полиморфизм работает правильно и подклассы действительно являются специализацией базового класса 🔩.
Давайте рассмотрим пример нарушения LSP 🚫:
Здесь функция, принимающая Bird, ожидает, что любой потомок сможет летать. Но при подстановке пингвина код валится с ошибкой, значит, иерархия нарушает принцип Лисков 🚫.
А теперь пример правильного использования LSP 🌟:
Ключевые правила LSP 📝:
✔️ Предусловия не могут быть усилены в подклассе — подкласс не должен требовать больше, чем базовый класс
✔️ Постусловия не могут быть ослаблены в подклассе — подкласс должен гарантировать как минимум то, что гарантирует базовый класс
✔️ Инварианты должны сохраняться — свойства, которые истинны для базового класса, должны оставаться истинными для подклассов
✔️ Исключения — подкласс не должен выбрасывать новые типы исключений, которые не ожидаются от базового класса
Полную новость читайте здесь.
FlutterPulse — канал о мире Flutter!
#flutter #dart #FlutterPulse #FlutterPulseNews #flutterfriendly
Привет, друзья! Сегодня мы поговорим о третьей букве в акрониме SOLID - L, которая означает принцип подстановки Лисков 🤔. Этот принцип гласит, что объекты подклассов должны быть взаимозаменяемы с объектами их базового класса без нарушения корректности работы программы 💻.
Почему это важно? 🤔 Нарушение LSP приводит к непредсказуемому поведению программы, код начинает проверять типы объектов с помощью if/else или is, что противоречит принципу открытости/закрытости и делает систему хрупкой 🌪. Соблюдение LSP гарантирует, что полиморфизм работает правильно и подклассы действительно являются специализацией базового класса 🔩.
Давайте рассмотрим пример нарушения LSP 🚫:
class Bird {
void fly() {
print("Flying");
}
}
class Penguin extends Bird {
@override
void fly() {
throw Exception("Cannot fly"); // Нарушение LSP
}
}
Здесь функция, принимающая Bird, ожидает, что любой потомок сможет летать. Но при подстановке пингвина код валится с ошибкой, значит, иерархия нарушает принцип Лисков 🚫.
А теперь пример правильного использования LSP 🌟:
abstract class Bird {
void move();
}
class Sparrow extends Bird {
@override
void move() {
print("Flying");
}
}
class Penguin extends Bird {
@override
void move() {
print("Swimming");
}
}
Ключевые правила LSP 📝:
✔️ Предусловия не могут быть усилены в подклассе — подкласс не должен требовать больше, чем базовый класс
✔️ Постусловия не могут быть ослаблены в подклассе — подкласс должен гарантировать как минимум то, что гарантирует базовый класс
✔️ Инварианты должны сохраняться — свойства, которые истинны для базового класса, должны оставаться истинными для подклассов
✔️ Исключения — подкласс не должен выбрасывать новые типы исключений, которые не ожидаются от базового класса
Полную новость читайте здесь.
FlutterPulse — канал о мире Flutter!
#flutter #dart #FlutterPulse #FlutterPulseNews #flutterfriendly
🔥2
🪙 Жизненный цикл Flutter-приложения: как отслеживать изменения состояний 📱
Каждое мобильное приложение проходит через ряд состояний, определяемых перечислением
Существует пять основных состояний:
-
-
-
-
-
Чтобы отслеживать изменения этих состояний, мы используем
Пример работы с
Полную новость читайте здесь.
FlutterPulse — канал о мире Flutter!
#flutter #dart #FlutterPulse #FlutterPulseNews #flutterfriendly #mobiledevelopment #appdevelopment
Каждое мобильное приложение проходит через ряд состояний, определяемых перечислением
AppLifecycleState. Чтобы корректно реагировать на эти события, нам нужно понимать, какие состояния существуют и как на них реагировать. Существует пять основных состояний:
-
resumed: приложение находится на переднем плане и готово к взаимодействию с пользователем 📈-
inactive: приложение временно неактивно, например, при поступлении звонка 📞-
paused: приложение уходит в фон и не реагирует на действия пользователя 📊-
hidden: приложение скрыто от пользователя, но процесс остается в памяти и готов к быстрому возобновлению 🔒-
detached: приложение больше не активно и готовится к завершению 🔴Чтобы отслеживать изменения этих состояний, мы используем
WidgetsBindingObserver и его метод didChangeAppLifecycleState, который вызывается каждый раз, когда система переводит приложение между состояниями. Пример работы с
didChangeAppLifecycleState:
@override
void didChangeAppLifecycleState(AppLifecycleState state) {
super.didChangeAppLifecycleState(state);
setState(() {
if (state == AppLifecycleState.resumed) {
appState = 'Возобновлено';
} else if (state == AppLifecycleState.inactive) {
appState = 'Неактивно';
} else if (state == AppLifecycleState.paused) {
appState = 'Приостановлено';
} else if (state == AppLifecycleState.detached) {
appState = 'Отключено';
} else if (state == AppLifecycleState.hidden) {
appState = 'Скрыто';
}
});
}
Полную новость читайте здесь.
FlutterPulse — канал о мире Flutter!
#flutter #dart #FlutterPulse #FlutterPulseNews #flutterfriendly #mobiledevelopment #appdevelopment
👍3🔥1