Factory pattern with companion objects in Kotlin - Deep Dive

Overview - Factory pattern with companion objects

What is it?

The factory pattern is a way to create objects without specifying the exact class of the object to create. In Kotlin, companion objects are special objects inside a class that can hold functions and properties shared by all instances. Combining these, the factory pattern with companion objects means using a companion object to create and return instances of a class. This helps keep object creation organized and flexible.

Why it matters

Without this pattern, code that creates objects can become messy and hard to change, especially when many types of objects are involved. Using companion objects for factories centralizes creation logic, making it easier to update or extend without changing many parts of the program. This leads to cleaner, more maintainable code that adapts well as programs grow.

Where it fits

Before learning this, you should understand basic Kotlin classes, objects, and functions. After this, you can explore more advanced design patterns, dependency injection, and Kotlin's sealed classes or interfaces for better type safety in factories.

Mental Model

Core Idea

A companion object acts like a factory inside a class, creating instances without exposing the details of how they are made.

Think of it like...

Imagine a cookie cutter (the companion object) that shapes dough (object creation) into cookies (instances). You don't need to know how the dough is prepared, just use the cutter to get the cookie shape you want.

┌─────────────┐
│   Class     │
│  (Product)  │
│             │
│ companion   │
│ object      │
│  Factory()  │
└─────┬───────┘
      │ creates
      ▼
┌─────────────┐
│  Instance   │
│ (Product)   │
└─────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Kotlin Companion Objects

Concept: Learn what companion objects are and how they belong to a class, not instances.

In Kotlin, a companion object is a special object inside a class declared with the keyword 'companion object'. It can hold functions and properties that are shared across all instances of the class. You can call these functions using the class name without creating an instance. Example: class Example { companion object { fun greet() = "Hello" } } Usage: println(Example.greet()) // prints Hello

Result

You can call functions inside the companion object directly from the class without creating an object.

Understanding companion objects is key because they provide a place to put factory methods that create instances without needing an object first.

2

Foundation

Basics of the Factory Pattern

Concept: The factory pattern creates objects through a method instead of direct constructors.

Normally, you create an object by calling its constructor directly, like 'val obj = MyClass()'. The factory pattern uses a method to create objects, hiding the details of which exact class or how the object is made. Example: interface Animal { fun sound(): String } class Dog : Animal { override fun sound() = "Woof" } class Cat : Animal { override fun sound() = "Meow" } class AnimalFactory { fun create(type: String): Animal = when(type) { "dog" -> Dog() "cat" -> Cat() else -> throw IllegalArgumentException("Unknown animal") } }

Result

You can create different animals by calling the factory's create method with a type string.

Using a factory method separates object creation from usage, making code easier to change and extend.

3

Intermediate

Implementing Factory in Companion Object

🤔Before reading on: Do you think companion objects can hold state or just functions? Commit to your answer.

Concept: Use the companion object inside a class to hold the factory method that creates instances of that class or its subclasses.

Instead of a separate factory class, Kotlin allows putting the factory method inside the companion object of the class itself. Example: interface Animal { fun sound(): String } class Dog : Animal { override fun sound() = "Woof" companion object { fun create() = Dog() } } // Usage val dog = Dog.create() println(dog.sound()) // Woof

Result

You create a Dog instance by calling Dog.create() without needing a separate factory class.

Knowing companion objects can hold factory methods lets you keep creation logic close to the class, improving code organization.

4

Intermediate

Factory Pattern with Multiple Subtypes

🤔Before reading on: Can a single companion object create different subclasses? Yes or no? Commit to your answer.

Concept: A companion object factory can decide which subclass instance to create based on input parameters.

You can write a factory method inside a companion object that returns different subclasses depending on input. Example: interface Animal { fun sound(): String } class Dog : Animal { override fun sound() = "Woof" } class Cat : Animal { override fun sound() = "Meow" } open class Animal { companion object { fun create(type: String): Animal = when(type) { "dog" -> Dog() "cat" -> Cat() else -> throw IllegalArgumentException("Unknown animal") } } } // Usage val animal = Animal.create("cat") println(animal.sound()) // Meow

Result

The factory method returns the correct subclass instance based on the input string.

This pattern allows flexible creation of different types while keeping the factory logic centralized.

5

Advanced

Using Factory Pattern for Encapsulation

🤔Before reading on: Does using a companion object factory help hide constructor details? Yes or no? Commit to your answer.

Concept: The factory method can hide complex or multiple constructors, exposing only simple creation methods.

Sometimes constructors are complex or you want to prevent direct creation. By making constructors private and using a companion object factory, you control how instances are made. Example: class User private constructor(val name: String) { companion object { fun create(name: String): User { // Add validation or setup here if (name.isBlank()) throw IllegalArgumentException("Name required") return User(name) } } } // Usage val user = User.create("Alice") println(user.name) // Alice

Result

Users can only be created through the factory method, ensuring validation and control.

Encapsulating creation logic prevents misuse and enforces rules, improving code safety.

6

Expert

Companion Object Factories and Inheritance Challenges

🤔Before reading on: Can companion object factories be inherited or overridden in subclasses? Commit to your answer.

Concept: Companion objects are not inherited, so factory methods in companion objects do not participate in polymorphism, which can cause design challenges.

In Kotlin, companion objects belong to the class but are not part of the class inheritance chain. This means if you have a base class with a companion object factory, subclasses do not inherit or override that companion object. Example: open class Base { companion object { fun create() = Base() } } class Derived : Base() { companion object { fun create() = Derived() } } // Usage val base = Base.create() // Base instance val derived = Derived.create() // Derived instance // But you cannot do polymorphic calls like Base.create() returning Derived automatically. This requires careful design to avoid confusion or duplicated factory code.

Result

Companion object factories do not support polymorphic factory methods, limiting inheritance use.

Understanding this limitation helps avoid subtle bugs and guides better design choices when using factories with inheritance.

Under the Hood

Companion objects in Kotlin are singleton objects tied to a class. They are initialized when the class is first accessed. Factory methods inside companion objects are just regular functions called on this singleton. When you call a factory method, it runs the code inside and returns a new instance created by constructors or other logic. The companion object itself does not hold instance state but can hold shared data or helper functions.

Why designed this way?

Kotlin introduced companion objects to provide a clean way to define static-like members without Java's static keyword. This design allows factory methods to live inside the class namespace, improving code organization and readability. The choice to make companion objects non-inheritable keeps the language simpler and avoids complex inheritance issues with static members.

┌───────────────┐
│   Class Foo   │
│ ┌───────────┐ │
│ │ Companion │ │
│ │ Object    │ │
│ │ Factory() │ │
│ └────┬──────┘ │
└──────┼────────┘
       │ calls
       ▼
┌───────────────┐
│  New Instance │
│  of Foo or    │
│  subclass     │
└───────────────┘

Myth Busters - 3 Common Misconceptions

Quick: Does a companion object factory method automatically support polymorphism through inheritance? Commit yes or no.

Common Belief: Companion object factory methods are inherited and can be overridden like normal instance methods.

Reality: Companion objects are not inherited, so their factory methods do not participate in polymorphism or overriding.

Why it matters: Assuming inheritance works here can lead to bugs where the wrong factory method is called, causing unexpected object types or duplicated code.

Quick: Can companion objects hold instance-specific data? Commit yes or no.

Common Belief: Companion objects can hold data unique to each instance of the class.

Reality: Companion objects are singletons shared by the class, so they cannot hold data unique to individual instances.

Why it matters: Misusing companion objects for instance data can cause shared state bugs and unexpected behavior.

Quick: Does using a factory method always improve code clarity? Commit yes or no.

Common Belief: Factory methods always make code clearer and simpler.

Reality: In simple cases, factory methods can add unnecessary complexity and indirection.

Why it matters: Overusing factories can make code harder to read and maintain when direct constructors would suffice.

Expert Zone

1

Companion object factories can be combined with Kotlin's sealed classes to enforce exhaustive type creation in a controlled hierarchy.

2

Using inline functions inside companion object factories can optimize performance by reducing overhead in object creation.

3

Companion object factories can leverage Kotlin's named and default parameters to provide flexible creation APIs without multiple constructors.

When NOT to use

Avoid companion object factories when you need polymorphic factory behavior across inheritance hierarchies; instead, use separate factory classes or dependency injection frameworks. Also, if object creation is trivial, direct constructors are simpler and clearer.

Production Patterns

In production Kotlin code, companion object factories are often used for creating data model instances with validation, parsing from external data, or managing complex initialization. They are also common in libraries to provide convenient static-like creation methods while keeping code idiomatic.

Connections

Static methods in Java

Companion object factory methods serve a similar role to static factory methods in Java classes.

Understanding companion objects helps Kotlin developers transition from Java static methods, seeing how Kotlin improves organization and safety.

Dependency Injection

Factory patterns are a foundational concept that dependency injection frameworks build upon to provide flexible object creation.

Knowing factory patterns clarifies how DI frameworks manage object lifecycles and dependencies behind the scenes.

Biological Cell Differentiation

Factory pattern resembles how stem cells differentiate into specific cell types based on signals, similar to how a factory creates different objects based on input.

This cross-domain link shows how controlled creation and specialization are universal concepts in both programming and biology.

Common Pitfalls

#1 Trying to override companion object factory methods in subclasses expecting polymorphism.

Wrong approach:

open class Base {
companion object {
open fun create() = Base()
}
}

class Derived : Base() {
companion object {
override fun create() = Derived() // Error: cannot override
}
}

Correct approach:

open class Base {
companion object {
fun create() = Base()
}
}

class Derived : Base() {
companion object {
fun create() = Derived()
}
}

Root cause:

Misunderstanding that companion objects are not part of the inheritance chain and their members cannot be overridden.

#2 Using companion object to store instance-specific data leading to shared state bugs.

Wrong approach:

class User {
companion object {
var currentUserName: String = ""
}
}

fun main() {
User.currentUserName = "Alice"
val user1 = User()
User.currentUserName = "Bob"
val user2 = User()
// Both user1 and user2 see currentUserName as "Bob"
}

Correct approach:

class User(val name: String) {
companion object {
fun create(name: String) = User(name)
}
}

fun main() {
val user1 = User.create("Alice")
val user2 = User.create("Bob")
// Each user has its own name
}

Root cause:

Confusing companion object as a place for instance data instead of shared class-level data.

#3 Using factory pattern unnecessarily for simple classes with no complex creation logic.

Wrong approach:

class Point(val x: Int, val y: Int) {
companion object {
fun create(x: Int, y: Int) = Point(x, y)
}
}

// Usage
val p = Point.create(1, 2)

Correct approach:

class Point(val x: Int, val y: Int)

// Usage
val p = Point(1, 2)

Root cause:

Overengineering by adding factory methods where direct constructors are simpler and clearer.

Key Takeaways

Companion objects in Kotlin provide a natural place to put factory methods that create instances of a class.

The factory pattern separates object creation from usage, improving code flexibility and maintainability.

Companion object factories cannot be inherited or overridden, so they do not support polymorphic factory behavior.

Using companion object factories helps encapsulate complex creation logic and enforce validation rules.

Avoid overusing factories for simple cases and never store instance-specific data in companion objects.