Factory: the essence of Factory Method and Abstract Factory patterns

What is Factory: the essence of the object creation pattern?

Factory — a creational design pattern from the GoF catalog. The main idea: move object creation logic out of client code into a separate method or class. The client works with an interface or abstract class, while the concrete implementation is created by the factory. This implements the Dependency Inversion principle: the client does not depend on concrete classes, only on abstractions.

Two varieties of Factory: Factory Method and Abstract Factory. Factory Method — a single method in a class that subclasses override to create objects. Abstract Factory — an interface with a family of factory methods for creating groups of related objects. Both variants solve the same problem: the client does not call new MyClass() directly, but asks the factory to create an object by its type or parameters.

Factory vs new() — direct object creation tightly couples code to a concrete implementation. Factory adds a layer: changing the implementation requires editing only the factory, not all clients. In mobile development, Factory is actively used for creating ViewModel (ViewModelProvider.Factory), network clients (Retrofit.create()), list adapters and serialization factories. DI containers (Dagger, Koin) automatically generate factories.

Factory Method: Swift and Kotlin examples

Factory Method — a method declared in a protocol or abstract class that returns an object of a specific type. Subclasses implement the method, creating concrete instances. In Swift, this can be a static method in a protocol or a method in a base class. In Kotlin — a companion object with a factory method or open fun in an abstract class. The pattern is widely used for creating parsers, error factories, and query builders.

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()
        }
    }
}

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

Kotlin version of Factory Method uses companion object or sealed class to limit types. Sealed class ensures that the when branch covers all possible types — the compiler checks completeness. This is typical for Android projects where the factory creates different Repository or DataSource implementations depending on build flavour or 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: families of related objects

Abstract Factory — a pattern for creating families of related or interdependent objects without specifying their concrete classes. The client works with the abstract factory interface, which defines methods for creating each product of the family. A concrete factory implements the interface and creates objects of a specific variant. For example, a UI component factory for iOS creates UIButton, UILabel, UITableView, while for Android — Button, TextView, RecyclerView.

Abstract Factory vs Factory Method — Factory Method creates one type of object through inheritance, Abstract Factory creates a family of objects through composition. Factory Method is overridden in subclasses, Abstract Factory provides multiple factory methods through a protocol. Abstract Factory often contains several Factory Methods. In mobile development, Abstract Factory is used for platform-dependent components, theme styling, and database factories.

Real-world case of Abstract Factory in Android — implementing different database types (SQLite vs Room) through a single DatabaseFactory interface. The factory creates DAO objects, migrations, and connection pools. In iOS — a service factory for different environments (Development/Staging/Production). Abstract Factory is rarely used directly — its functions are taken over by DI containers (Dagger Module, Swinject Assembly).

Factory in iOS: protocols and static methods

Swift Factory is implemented through protocols and static methods. The Factory protocol declares a create() method returning an abstract type. A concrete factory implements the protocol and creates the required objects. Swift does not require a separate factory class for simple cases — a static method in an enum or struct is sufficient. For complex scenarios, a Factory protocol with DI injection is used.

Factory in iOS SDK — many system factories: UIStoryboard.instantiateViewController(withIdentifier:), NSKeyedUnarchiver.unarchivedObject(ofClass:from:), JSONDecoder().decode(_:from:). Developers create factories for ViewController (StoryboardFactory), for services (ServiceFactory), and for data models. Factory Method is actively used in VIPER and Clean Swift architectures for creating screen modules.

Factory + DI — a modern alternative: a DI container (Swinject, Factory) automatically generates factories for registered types. The container stores object creation recipes and resolves dependencies. The Factory library (github.com/hmlongco/Factory) uses @Injected(.service) for automatic injection. DI factories are tested by replacing an entire module with a single line: container.register { MockService() }.

Factory in Android: companion factory and DI modules

Android Factory — a classic example: ViewModelProvider.Factory for creating ViewModel with parameters. Google recommends using Hilt for automatic ViewModel factory generation — the @HiltViewModel annotation creates Factory automatically. For simple objects, a companion object with create() or invoke() method is used. In Kotlin, the invoke operator allows calling the factory like a function: Factory(param).

Factory in Jetpack Compose — factories are used for creating states and effects. remember { Factory.create() } creates an object on first render and preserves it throughout the composable's lifecycle. ViewModel in Compose is created via viewModel() — this is a factory managed by Hilt. In Compose, factories are less common explicitly, as DI and Compose StateManager handle object creation.

Factory vs Hilt — Dagger/Hilt automatically generates factories at compile time. @Module + @Providers replaces Factory Method, @Binds replaces Abstract Factory. Manual factories remain relevant for dynamic runtime implementation selection (A/B testing, feature flags). For static dependencies, Hilt fully automates object creation — the developer only writes interfaces and annotations.