Flutter Dev Talk
#ARCH-2 Over-engineering, YAGNI & KISS tushunchalari
Arxitekturaning maqsadi ko'p layer qo'shish emas balki o'zgarishlarni cost'ni boshqarish dedik.
Buyerda ikkita extrimum bor:
Under-engineering Over-engineering
hamma logic har narsaga
bitta joyda abstraction
│ │
└─────────── BALANCE ──────────────┘
kerakli darajada
architecture
Maqsad hozirgi requirementlarga mos sodda yechim qilish va shu bilan birgalikda keyingi o'zgarishlarga ham yo'l ochib qo'yish kerak.
2.1: YAGNI - You Aren't Gonna Need It.
Requirement:
Hozir bizda faqat Paynet bilan to'lov qilinadi.
Lekin biz buning keyinchalik qo'shilishi mumkin deb quyidagicha yozishimiz mumkin :
abstract interface class PaymentStrategy {
Future<void> pay();
}
class PaynetStrategy implements PaymentStrategy {}
class ClickStrategy implements PaymentStrategy {}
class PaymeStrategy implements PaymentStrategy {}
Biz hali bilmagan flowlar uchun taxminan ko'd yozdik.
YAGNI esa shunday deydi:
Hozir kerak bo‘lmagan capability’ni faqat kelajakda balki kerak bo‘lishi mumkinligi uchun yaratma.
2.2: KISS - Keep It Simple.
Tepadagi requirement bo'yicha davom etsak:
class PaymentStrategy {
final PaymentApi api;
PaymentStrategy(this.api);
Future<void> create() {
/// Payment amalga oshirilmoqda
}
Future<void> confirm() {
/// Payment amalga oshirilmoqda
}
Future<void> payment() {
/// Payment amalga oshirilmoqda
}
}
va bu yerda
Bu yerda usecase yoki repository ishlatmaslik bu ko'dni yomon qilmaydi. Lekin keyinchalik buyerga boshqa to'lov providerlari qo'shilsa va ular har xil flowlarga ega bo'lsa ko'd if/else dan iborat bo'lib qoladi.
if (type == paynet) {
// create
// confirm
// payment
} else if (type == click) {
// amount check
// confirm
// payment
} else if (type == payme) {
// confirm
// create
// extra validation
// paym… Read in full →
122 ·