Builder — murakkab obyektni bosqichma-bosqich yaratish jarayonini uning yakuniy ko‘rinishidan ajratadigan creational design patterndir. U ko‘p parametrli constructor, ixtiyoriy qismlar yoki turli konfiguratsiyadan bir xil turdagi natija qurish zarur bo‘lganda ishlatiladi. Builder validatsiya qilingan obyektni build amali orqali qaytaradi.
Asosiy tuzilma
Builder odatda yaratilayotgan qiymatlar uchun vaqtinchalik mutable holat saqlaydi. Fluent metodlar kerakli parametrni o‘rnatib, builderning o‘zini qaytaradi. Yakuniy build metodi majburiy maydonlarni tekshiradi va target obyektni yaratadi. Target immutable bo‘lishi mumkin, builder esa qurilish davomida o‘zgaradi.
Klassik GoF ta’rifida Director qurilish qadamlarining ketma-ketligini boshqaradi, ConcreteBuilder esa aniq representationni hosil qiladi. Zamonaviy application kodida director alohida class bo‘lmasligi mumkin; client fluent API orqali qadamlarni to‘g‘ridan-to‘g‘ri chaqiradi.
Constructor muammosi
Ko‘p bir xil turdagi parametrli constructorni o‘qish qiyin. User(name, true, false, 30, null) chaqiruvida boolean va sonlarning ma’nosi ko‘rinmaydi. Builder withName, active va timeout kabi nomlangan amallar bilan niyatni ochadi. Parameter order xatosi kamayadi.
Builder har doim ko‘p parametr mavjudligi uchungina zarur emas. Til named arguments, default value va data classni yaxshi qo‘llasa, oddiy obyekt uchun builder ortiqcha ceremony bo‘lishi mumkin. Pattern qurilish qoidasi yoki variantlar haqiqatan murakkab bo‘lganda qiymat beradi.
Invariantlar
Majburiy qiymat builder constructoriga berilishi yoki build vaqtida tekshirilishi mumkin. Birinchi usul noto‘g‘ri yarim builder holatini kamaytiradi. Build-time tekshiruv bir nechta maydon orasidagi qoidalarni baholaydi, masalan start date end datedan keyin emasligi yoki TLS yoqilganda certificate berilishi.
Xato aniqlansa target obyekt yaratilmaydi. Builder ichki defaultlarni aniq belgilaydi; yashirin environmentga bog‘liq default testlarni beqaror qilishi mumkin. Bir builderni qayta ishlatish eski qiymatlar keyingi obyektga o‘tishiga sabab bo‘lsa, builddan keyin reset qilinadi yoki builder bir martalik qilinadi.
Variantlar
Step Builder type system orqali qadamlar tartibini majburlashi mumkin: avval endpoint, keyin credential, so‘ng optional sozlamalar. Bu compile-time xavfsizlik beradi, ammo interface va genericlar sonini oshiradi. Test Data Builder esa test obyektlarini ma’noli defaultlar bilan tez yaratadi va faqat scenario uchun muhim maydonlarni o‘zgartiradi.
Lombok yoki IDE code generation builder boilerplateni kamaytiradi. Generatsiya qilingan builder domen invariantini avtomatik bilmaydi; setterlarga o‘xshash barcha maydonni ochib yuborishi mumkin. Maxfiy yoki boshqariladigan maydonlar, masalan ID va audit vaqti, clientga berilmasligi kerak.
Boshqa patternlar bilan aloqasi
Factory qaysi concrete tur yaratilishini yashiradi va ko‘pincha bitta chaqiruvda natija beradi. Builder esa bir obyektning qurilish jarayoni va variantlariga urg‘u beradi. Abstract Factory bog‘liq obyektlar oilasini yaratadi. Builder ichida factorydan yoki factory ichida tayyor builderdan foydalanish mumkin.
Prototype mavjud obyektni klonlashga asoslanadi. ToBuilder varianti immutable obyekt qiymatlarini builderga ko‘chirib, ayrim maydonlari o‘zgargan yangi nusxa yaratishi mumkin. Sensitive qiymatlarning tasodifiy ko‘chirilishi va identity dublikatsiyasi nazorat qilinadi.
Testlash
Builder testi majburiy qiymat yo‘qligi, yaroqsiz kombinatsiya, defaultlar va muvaffaqiyatli obyektni alohida tekshiradi. Property-based test ko‘p parametr kombinatsiyasida invariant saqlanishini ko‘rsatishi mumkin. Builder test helper sifatida ishlatilsa, default qiymatlar scenario maqsadini yashirmasligi kerak; test faqat muhim farqlarni ochiq ko‘rsatadi.
Bog‘liq tushunchalar
Design pattern, Factory Method, Abstract Factory, Prototype, Fluent interface, Immutability, Test Data Builder