Factory: diwa ng pattern ng Factory Method at Abstract Factory

Ano ang Factory: diwa ng pattern ng paglikha ng mga bagay?

Factory — isang creational design pattern mula sa katalogo ng GoF. Pangunahing ideya: ilipat ang lohika ng paglikha ng mga bagay mula sa code ng kliyente patungo sa isang hiwalay na pamamaraan o klase. Ang kliyente ay gumagana gamit ang isang interface o abstract na klase, at ang konkretong implementasyon ay nilikha ng pabrika. Ito ay nagpapatupad ng prinsipyo ng pagbabaligtad ng dependency (Dependency Inversion): ang kliyente ay hindi nakadepende sa mga konkretong klase, kundi sa mga abstraksyon lamang.

Dalawang uri ng Factory: Factory Method at Abstract Factory. Factory Method — isang pamamaraan sa klase na ni-override ng mga subclass upang lumikha ng mga bagay. Abstract Factory — isang interface na may isang pamilya ng mga factory method para sa paglikha ng mga grupo ng magkakaugnay na bagay. Ang parehong variant ay nalulutas ang parehong problema: ang kliyente ay hindi direktang tumatawag ng new MyClass(), kundi humihiling sa pabrika na lumikha ng isang bagay ayon sa uri o mga parameter nito.

Factory vs new() — ang direktang paglikha ng mga bagay ay mahigpit na nagbubuklod ng code sa isang konkretong implementasyon. Nagdaragdag ang Factory ng isang layer: ang pagpapalit ng implementasyon ay nangangailangan ng pagbabago lamang sa pabrika, hindi sa lahat ng kliyente. Sa pag-develop ng mobile, ang Factory ay aktibong ginagamit para sa paglikha ng ViewModel (ViewModelProvider.Factory), mga network client (Retrofit.create()), mga adapter ng listahan at mga factory ng serialization. Ang mga DI container (Dagger, Koin) ay awtomatikong bumubuo ng mga pabrika.

Factory Method: mga halimbawa sa Swift at Kotlin

Factory Method — isang pamamaraan na idineklara sa isang protocol o abstract na klase na nagbabalik ng isang bagay ng isang tiyak na uri. Ipinapatupad ng mga subclass ang pamamaraang ito, na lumilikha ng mga konkretong instance. Sa Swift ito ay maaaring maging static method sa isang protocol o pamamaraan sa isang base class. Sa Kotlin — companion object na may factory method o open fun sa isang abstract na klase. Ang pattern ay malawakang ginagamit para sa paglikha ng mga parser, factory ng error at mga builder ng query.

protocol PaymentGateway {
    func processPayment(amount: Decimal) async throws -> PaymentResult
}

final class StripeGateway: PaymentGateway { /* ... */ }
final class ApplePayGateway: PaymentGateway { /* ... */ }

enum PaymentType { case stripe, applePay }

final class PaymentFactory {
    // Factory Method
    static func create(type: PaymentType) -> PaymentGateway {
        switch type {
        case .stripe: return StripeGateway()
        case .applePay: return ApplePayGateway()
        }
    }
}

// Paggamit
let gateway = PaymentFactory.create(type: .stripe)

Kotlin bersyon Factory Method ay gumagamit ng companion object o sealed class upang limitahan ang mga uri. Ginagarantiya ng Sealed class na ang sangay ng when ay sumasaklaw sa lahat ng posibleng uri — sinusuri ng compiler ang pagkakumpleto. Ito ay tipikal para sa mga proyekto ng Android, kung saan ang pabrika ay lumilikha ng iba't ibang implementasyon ng Repository o DataSource depende sa build flavour o configuration.

sealed class PaymentType {
    object Stripe : PaymentType()
    object ApplePay : PaymentType()
}

interface PaymentGateway {
    suspend fun processPayment(amount: BigDecimal): PaymentResult
}

class PaymentFactory {
    companion object {
        fun create(type: PaymentType): PaymentGateway = when (type) {
            PaymentType.Stripe -> StripeGateway()
            PaymentType.ApplePay -> ApplePayGateway()
        }
    }
}

Abstract Factory: mga pamilya ng magkakaugnay na bagay

Abstract Factory — pattern para sa paglikha ng mga pamilya ng magkakaugnay o magkaka-dependeng bagay nang hindi tinutukoy ang kanilang mga konkretong klase. Ang kliyente ay gumagana gamit ang interface ng abstract na pabrika na tumutukoy sa mga pamamaraan para sa paglikha ng bawat produkto ng pamilya. Ang konkretong pabrika ay nagpapatupad ng interface at lumilikha ng mga bagay ng isang tiyak na variant. Halimbawa, ang isang pabrika ng mga bahagi ng UI para sa iOS ay lumilikha ng UIButton, UILabel, UITableView, at para sa Android — Button, TextView, RecyclerView.

Abstract Factory vs Factory Method — Factory Method ay lumilikha ng isang uri ng bagay sa pamamagitan ng pamana, Abstract Factory ay lumilikha ng isang pamilya ng mga bagay sa pamamagitan ng komposisyon. Factory Method ay na-override sa mga subclass, Abstract Factory ay nagbibigay ng maraming factory method sa pamamagitan ng isang protocol. Abstract Factory ay madalas naglalaman ng maraming Factory Method. Sa pag-develop ng mobile, Abstract Factory ay ginagamit para sa mga bahaging nakadepende sa platform, mga tema at mga factory ng database.

Tunay na kaso Abstract Factory sa Android — pagpapatupad ng iba't ibang uri ng database (SQLite vs Room) sa pamamagitan ng pinag-isang interface ng DatabaseFactory. Ang pabrika ay lumilikha ng mga DAO object, migrasyon at mga pool ng koneksyon. Sa iOS — pabrika ng mga serbisyo para sa iba't ibang kapaligiran (Development/Staging/Production). Abstract Factory ay bihirang ginagamit nang direkta — ang mga function nito ay ginagampanan ng mga DI container (Dagger Module, Swinject Assembly).

Factory sa iOS: mga protocol at static na pamamaraan

Swift Factory ay ipinapatupad sa pamamagitan ng mga protocol at static na pamamaraan. Ang protocol ng Factory ay nagdedeklara ng pamamaraang create() na nagbabalik ng isang abstract na uri. Ang konkretong pabrika ay nagpapatupad ng protocol at lumilikha ng mga kinakailangang bagay. Ang Swift ay hindi nangangailangan ng hiwalay na klase-pabrika para sa mga simpleng kaso — sapat na ang isang static na pamamaraan sa enum o struct. Para sa mga komplikadong sitwasyon, ginagamit ang Factory protocol na may iniksyon sa pamamagitan ng DI.

Factory sa iOS SDK — maraming system factory: UIStoryboard.instantiateViewController(withIdentifier:), NSKeyedUnarchiver.unarchivedObject(ofClass:from:), JSONDecoder().decode(_:from:). Ang mga developer ay lumilikha ng mga pabrika para sa ViewController (StoryboardFactory), para sa mga serbisyo (ServiceFactory) at para sa mga modelo ng data. Factory Method ay aktibong ginagamit sa mga arkitektura ng VIPER at Clean Swift para sa paglikha ng mga module ng screen.

Factory + DI — modernong alternatibo: DI container (Swinject, Factory) ay awtomatikong bumubuo ng mga pabrika para sa mga nakarehistrong uri. Ang container ay nag-iimbak ng mga recipe ng paglikha ng bagay at nilulutas ang mga dependency. Ang Factory library (github.com/hmlongco/Factory) ay gumagamit ng @Injected(.service) para sa awtomatikong iniksyon. Ang mga DI pabrika ay sinusuri sa pamamagitan ng pagpapalit ng buong module ng isang linya: container.register { MockService() }.

Factory sa Android: companion factory at mga module ng DI

Android Factory — klasikong halimbawa: ViewModelProvider.Factory para sa paglikha ng ViewModel na may mga parameter. Inirerekomenda ng Google ang paggamit ng Hilt para sa awtomatikong pagbuo ng mga factory ng ViewModel — ang anotasyon na @HiltViewModel ay awtomatikong lumilikha ng Factory. Para sa mga simpleng bagay, ginagamit ang companion object na may pamamaraang create() o invoke(). Sa Kotlin, ang operator na invoke ay nagpapahintulot sa pagtawag sa pabrika bilang isang function: Factory(param).

Factory sa Jetpack Compose — ginagamit ang mga pabrika para sa paglikha ng mga estado at epekto. Ang remember { Factory.create() } ay lumilikha ng isang bagay sa unang pag-render at iniimbak ito sa buong buhay ng composable. Ang ViewModel sa Compose ay nilikha sa pamamagitan ng viewModel() — ito ay isang pabrika na pinamamahalaan ng Hilt. Sa Compose, ang mga pabrika ay bihirang lumitaw nang tahasan dahil ang DI at Compose StateManager ang humahawak sa paglikha ng mga bagay.

Factory vs Hilt — Dagger/Hilt ay awtomatikong bumubuo ng mga pabrika sa yugto ng kompilasyon. @Module + @Provides pumapalit sa Factory Method, @Binds pumapalit sa Abstract Factory. Ang mga manu-manong pabrika ay nananatiling may kaugnayan para sa dinamikong pagpili ng implementasyon sa runtime (A/B testing, feature flags). Para sa mga static na dependency, ganap na awtomatiko ng Hilt ang paglikha ng mga bagay — ang developer ay sumusulat lamang ng interface at mga anotasyon.