Classes and Objects in Scala
In Scala, every class is a blueprint for creating objects that bundle state (fields) and behavior (methods) together, and unlike Java, Scala also has first-class singleton objects declared with the object keyword for values and behavior that should exist exactly once. A class defines a type and, when instantiated with new (or without new for classes with apply factories), produces an object with its own independent state, while a Scala object is itself the single instance -- there is no separate class you can create more of.
Cricket analogy: A class is like the blueprint the BCCI uses to certify a wicketkeeper role -- every team fields its own instance (MS Dhoni for CSK, Rishabh Pant for DC) with independent stats, but the singleton scorer's table at a stadium, like a Scala object, exists as exactly one shared instance for the whole match.
Defining Classes and Primary Constructors
Scala classes declare their primary constructor directly in the class signature: class Employee(val name: String, var salary: Double, age: Int = 25). Parameters marked val become public read-only fields, var parameters become public mutable fields, and parameters with neither modifier are just constructor arguments usable inside the class body but not exposed as fields unless referenced by a method. Parameters can also have default values, like age: Int = 25, letting callers omit them and Scala fill in the default, and the entire class body doubles as the constructor body -- any statement outside a method definition runs once at construction time.
Cricket analogy: Declaring class Batsman(val name: String, var strikeRate: Double, matches: Int = 0) mirrors how a franchise registers a player for the IPL auction -- name and strikeRate are published on the scoreboard for everyone to see, while matches might just be an internal auction detail used for valuation but not displayed.
Auxiliary Constructors and this
Beyond the primary constructor, Scala classes can define auxiliary constructors using def this(...), and every auxiliary constructor's first statement must call either the primary constructor or another auxiliary constructor via this(...), forming a chain that always bottoms out at the primary constructor. This is different from default parameter values in that auxiliary constructors let you provide entirely different combinations of arguments and computed logic, such as parsing a string into structured fields before delegating to the primary constructor.
Cricket analogy: An auxiliary constructor is like a franchise having a secondary signing route -- a marquee player goes straight through the main IPL auction (the primary constructor), but a replacement signing due to injury calls this(replacedPlayer.team, replacedPlayer.role), funneling through the same core registration process.
Singleton Objects and Companion Objects
A Scala object defines both a class and its single instance simultaneously -- there is no way to create a second one, which makes objects ideal for utility functions, constants, and the entry point def main. When an object shares the same name as a class and lives in the same source file, it becomes that class's companion object, gaining special access to the class's private members and conventionally hosting factory methods like apply (so Employee(Asha, 50000) can create instances without writing new) and extractor methods like unapply used in pattern matching.
Cricket analogy: A companion object is like the BCCI selection committee paired with the Indian cricket team -- the committee (companion object) has special access to internal squad data and can apply selections to name the playing XI, functioning alongside the team (the class) but existing as exactly one shared body.
class Employee(val name: String, var salary: Double, age: Int = 25) {
def raiseSalary(pct: Double): Unit = {
salary = salary * (1 + pct / 100)
}
override def toString: String = s"$name (age $age): $$${salary}"
}
object Employee {
def apply(name: String, salary: Double): Employee = new Employee(name, salary)
}
val asha = Employee("Asha", 50000.0)
asha.raiseSalary(10)
println(asha)Auxiliary constructors are far less common in idiomatic Scala than in Java, because default parameter values and companion object apply factory methods usually cover the same use cases more concisely.
A companion object must live in the same source file as its class and share its exact name -- Scala silently fails to link them (no error, just no privileged access) if they are defined in separate files.
- A class defines a reusable blueprint; instantiating it with new (or via a companion's apply) creates independent objects with their own state.
- Primary constructor parameters prefixed with val or var become public fields; unprefixed parameters are just local constructor arguments.
- Constructor parameters can carry default values, letting callers omit arguments in any trailing position.
- Auxiliary constructors, defined with def this(...), must delegate to the primary constructor (directly or transitively) as their first statement.
- An object is both a class and its one and only instance -- ideal for utilities, constants, and main methods.
- A companion object shares a name and file with its class, gaining access to private members and conventionally hosting apply/unapply.
- apply factory methods let you construct instances without the new keyword, e.g., Employee("Asha", 50000).
Practice what you learned
1. What does prefixing a primary constructor parameter with val do in Scala?
2. Which statement about auxiliary constructors is correct?
3. What makes an object a companion object of a class?
4. What is the primary benefit of defining apply in a companion object?
5. How many instances can a Scala object have?
Was this page helpful?
You May Also Like
Case Classes Explained
Understand what case class generates for free -- structural equality, copy, and pattern matching support -- and how pairing it with sealed traits builds safe, exhaustiveness-checked data models.
Traits in Scala
Learn how Scala traits provide composable, disciplined multiple inheritance, how linearization resolves overriding conflicts, and when to reach for a trait versus an abstract class.
Pattern Matching in Depth
Go beyond basic match expressions to guards, type patterns, list deconstruction, custom extractors, and compiler-checked exhaustiveness over sealed hierarchies.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics