Factory Patterns in Scala: Mastering Creational Design Patterns

Factory in Scala: A boundary that encapsulates how a value or service is created, often through companions, smart constructors, or small capability interfaces rather than heavy OO hierarchies.

Factory patterns still matter in Scala because creation decisions often need a home:

• validation
• normalization
• implementation selection
• environment-dependent assembly
• family coordination

What changes is that many Scala factories become smaller and more direct than their classic textbook counterparts.

Companion Objects Cover Many Simple Factory Cases

The simplest factory in Scala is often just a companion method:

1final case class Port private (value: Int)
2
3object Port {
4  def from(n: Int): Either[String, Port] =
5    if 0 <= n && n <= 65535 then Right(Port(n))
6    else Left("port out of range")
7}

This factory does real work:

• validates input
• controls construction
• returns a richer result than new

That is enough for many application-level needs.

Smart Constructors Are Usually Better Than “Simple Factory” Classes

A lot of classic simple factory examples become unnecessary once construction lives naturally in a companion. A dedicated factory class becomes useful when:

• selection logic depends on runtime configuration
• creation has dependencies of its own
• a whole family of related implementations must be coordinated

If none of that is true, a companion often communicates the creation boundary more cleanly.

Abstract Factory Still Exists, But Usually Smaller

When one subsystem must create multiple related implementations together, the problem is still real:

• serializers and parsers from one ecosystem
• repository and transaction components from one storage backend
• view renderer plus asset strategy for one delivery environment

Scala can express that with a trait returning the related capabilities:

1trait PersistenceFactory {
2  def users: UserRepository
3  def orders: OrderRepository
4}

That may be all the abstraction you need. You do not necessarily need a large “factory method plus product hierarchy” apparatus unless the design genuinely warrants it.

Factories Should Clarify, Not Hide, Effects

Construction can involve more than allocation:

• reading configuration
• opening resources
• choosing implementations from environment
• wiring observability or policy wrappers

If that work is effectful, the factory should be honest about it. Returning an effect or result type is usually clearer than disguising setup behind a pure-looking constructor.

Common Failure Modes

Creating a Factory Class for Trivial Construction

If the only goal is calling new with one obvious argument, the extra abstraction may be empty ceremony.

Hiding Complex Effects Behind Innocent-Looking Creation

A factory that performs I/O or environment lookup without signaling it clearly can mislead callers.

Preserving Classic Hierarchies Without a Real Need

Some abstract factory structures are kept alive mostly out of loyalty to the pattern catalog, not because the system really needs them.

Practical Heuristics

Start with companions and smart constructors. Move to capability-style or family-oriented factories only when runtime selection, richer assembly, or coordinated product families make them worthwhile. In Scala, a factory should make creation boundaries clearer, not merely more formal.

Ready to Test Your Knowledge?