Object-Oriented Programming, commonly known as OOP, is one of the most important programming concepts for developers building real-world applications.
If you are learning Swift for iOS, macOS, watchOS, or other Apple-platform development, you will frequently work with concepts such as:
- Classes
- Objects
- Properties
- Methods
- Encapsulation
- Inheritance
- Polymorphism
- Abstraction
- Protocols
- Composition
Understanding these concepts helps you organize large applications into smaller, reusable, and maintainable components.
For example, imagine you are building an eCommerce application.
Your application may contain:
User
Product
Cart
Order
Payment
Notification
Address
Instead of writing all application logic in one huge file, Object-Oriented Programming helps you model these responsibilities as separate types.
In this complete beginner’s guide, you will learn what OOP means in Swift, how its major principles work, where classes fit into Swift’s type system, and how to apply OOP concepts in practical applications.
What Is Object-Oriented Programming?
Object-Oriented Programming is a programming approach that organizes software around objects and their responsibilities.
An object can contain:
Data
+
Behavior
For example, consider a bank account.
It contains data:
Account Number
Account Holder
Balance
And behavior:
Deposit Money
Withdraw Money
Check Balance
Instead of keeping all of these things separate, we can represent them using one type.
class BankAccount {
let accountNumber: String
let accountHolder: String
private(set) var balance: Double
init(
accountNumber: String,
accountHolder: String,
balance: Double
) {
self.accountNumber = accountNumber
self.accountHolder = accountHolder
self.balance = balance
}
func deposit(_ amount: Double) {
balance += amount
}
func withdraw(_ amount: Double) {
guard amount <= balance else {
print("Insufficient balance")
return
}
balance -= amount
}
}
Now the data and behavior related to a bank account are grouped together.
Why Is OOP Important?
Imagine building an application containing thousands of lines of code without organizing responsibilities.
You might end up with:
Login Logic
Payment Logic
Cart Logic
User Logic
Notification Logic
API Logic
Database Logic
all mixed together.
That becomes difficult to:
- Understand
- Debug
- Test
- Reuse
- Maintain
- Extend
OOP helps separate responsibilities.
For example:
User
├── Profile data
└── User-related behavior
Cart
├── Cart items
└── Cart calculations
PaymentService
├── Payment state
└── Payment operations
NotificationService
└── Notification behavior
This organization can make a growing application much easier to manage.
Is Swift an Object-Oriented Programming Language?
Yes, Swift supports Object-Oriented Programming.
Swift provides features such as:
- Classes
- Objects
- Properties
- Methods
- Initializers
- Encapsulation
- Inheritance
- Polymorphism
- Access control
- Type casting
However, Swift is not only an object-oriented language.
Swift also strongly supports:
- Protocol-oriented programming
- Functional programming
- Value-oriented programming
- Generics
- Structured concurrency
This is important.
Modern Swift development does not require everything to be a class.
You may frequently combine:
Structs
Classes
Enums
Protocols
Extensions
Closures
Generics
depending on the problem you are solving.
What Is a Class in Swift?
A class is a reference type that can group data and behavior.
Basic syntax:
class ClassName {
}
Example:
class User {
var name: String
init(name: String) {
self.name = name
}
func greet() {
print("Hello, my name is \(name)")
}
}
Create an instance:
let user = User(name: "Alex")
Call:
user.greet()
Output:
Hello, my name is Alex
What Is an Object in Swift?
An object is an instance of a class.
Consider:
class Car {
let brand: String
init(brand: String) {
self.brand = brand
}
}
Here:
Car
is the class.
Now:
let car = Car(brand: "Toyota")
car is an instance of Car.
Conceptually:
Class
↓
Blueprint
↓
Object
↓
Actual Instance
You can create multiple objects from the same class:
let car1 = Car(brand: "Toyota")
let car2 = Car(brand: "BMW")
let car3 = Car(brand: "Tesla")
Each object is an instance of the same class.
Class vs Object
Beginners often confuse these two terms.
A simple analogy is:
Class → Blueprint
Object → Actual Thing
For example:
House Blueprint → Class
Actual House → Object
In Swift:
class User {
}
defines a type.
let user = User()
creates an object.
Properties in OOP
Properties represent the data or state associated with an object.
Example:
class User {
var name: String
var age: Int
init(name: String, age: Int) {
self.name = name
self.age = age
}
}
Here:
name
age
are properties.
Create:
let user = User(
name: "Alex",
age: 25
)
Access:
print(user.name)
print(user.age)
Output:
Alex
25
Methods in OOP
Methods represent behavior associated with an object.
Example:
class User {
let name: String
init(name: String) {
self.name = name
}
func introduce() {
print("Hi, I am \(name)")
}
}
Call:
let user = User(name: "Alex")
user.introduce()
Output:
Hi, I am Alex
Think of:
Properties → What an object has
Methods → What an object can do
Initializers in OOP
An initializer prepares an object when it is created.
Example:
class Product {
let name: String
let price: Double
init(name: String, price: Double) {
self.name = name
self.price = price
}
}
Create:
let product = Product(
name: "MacBook",
price: 1299
)
The initializer ensures that required properties receive their initial values.
The Four Main Principles of OOP
Object-Oriented Programming is commonly explained using four major principles:
Object-Oriented Programming
│
├── Encapsulation
│
├── Inheritance
│
├── Polymorphism
│
└── Abstraction
Understanding these four concepts will give you a strong foundation in OOP.
1. Encapsulation in Swift
Encapsulation means grouping related data and behavior together while controlling how internal state can be accessed or modified.
Consider a bank account.
A poor design might expose the balance directly:
class BankAccount {
var balance: Double = 1000
}
Now external code can do:
let account = BankAccount()
account.balance = -100000
That may violate the business rules of the application.
Instead, we can control access.
class BankAccount {
private(set) var balance: Double
init(balance: Double) {
self.balance = balance
}
func deposit(_ amount: Double) {
guard amount > 0 else {
return
}
balance += amount
}
func withdraw(_ amount: Double) {
guard amount > 0 else {
return
}
guard amount <= balance else {
print("Insufficient balance")
return
}
balance -= amount
}
}
Now external code can read:
print(account.balance)
but cannot directly assign an arbitrary value to it.
Changes must go through controlled methods.
Why Encapsulation Is Useful
Encapsulation can help:
- Protect internal state
- Prevent invalid modifications
- Hide implementation details
- Create clearer APIs
- Reduce accidental misuse
Instead of allowing:
Any Code
↓
Directly Modify Everything
we create:
External Code
↓
Public Method
↓
Validation
↓
Internal State
Access Control in Swift
Swift provides access-control modifiers that support encapsulation.
Important levels include:
open
public
package
internal
fileprivate
private
For beginners, three commonly encountered levels are:
public
internal
private
private
private restricts access to a declaration according to Swift’s private access rules.
Example:
class User {
private var password: String
init(password: String) {
self.password = password
}
}
External code cannot simply access:
user.password
This helps protect implementation details.
private(set)
Sometimes you want external code to read a property but prevent it from changing the property directly.
Use:
private(set)
Example:
class Counter {
private(set) var value = 0
func increment() {
value += 1
}
}
External code can:
print(counter.value)
but cannot:
counter.value = 100
This is a useful encapsulation technique.
2. Inheritance in Swift
Inheritance allows one class to inherit functionality from another class.
Example:
class Animal {
var name: String
init(name: String) {
self.name = name
}
func makeSound() {
print("Animal sound")
}
}
Now create:
class Dog: Animal {
}
Dog inherits from Animal.
Create:
let dog = Dog(name: "Buddy")
dog.makeSound()
Output:
Animal sound
Parent Class and Child Class
In:
class Dog: Animal
Animal is called:
Superclass
Parent Class
Base Class
Dog is called:
Subclass
Child Class
Derived Class
Conceptually:
Animal
│
├── Dog
├── Cat
└── Bird
Each child class can inherit common behavior from Animal.
Why Use Inheritance?
Without inheritance:
class Dog {
var name: String
func eat() {}
func sleep() {}
}
class Cat {
var name: String
func eat() {}
func sleep() {}
}
we may duplicate common functionality.
With inheritance:
class Animal {
var name: String
init(name: String) {
self.name = name
}
func eat() {
print("\(name) is eating")
}
func sleep() {
print("\(name) is sleeping")
}
}
Then:
class Dog: Animal {
}
class Cat: Animal {
}
Both subclasses inherit common functionality.
Method Overriding
A child class can replace an inherited implementation.
Use:
override
Example:
class Animal {
func makeSound() {
print("Animal sound")
}
}
class Dog: Animal {
override func makeSound() {
print("Woof!")
}
}
class Cat: Animal {
override func makeSound() {
print("Meow!")
}
}
Use:
let dog = Dog()
let cat = Cat()
dog.makeSound()
cat.makeSound()
Output:
Woof!
Meow!
super in Swift
A subclass can call the superclass implementation using:
super
Example:
class Animal {
func describe() {
print("I am an animal")
}
}
class Dog: Animal {
override func describe() {
super.describe()
print("I am also a dog")
}
}
Call:
let dog = Dog()
dog.describe()
Output:
I am an animal
I am also a dog
Preventing Inheritance with final
Use:
final
when a class should not be subclassed.
final class PaymentManager {
}
Now another class cannot inherit from PaymentManager.
You can also mark individual methods as final when they should not be overridden.
3. Polymorphism in Swift
Polymorphism means that different concrete objects can be used through a common type while providing different behavior.
Consider:
class Animal {
func makeSound() {
print("Animal sound")
}
}
class Dog: Animal {
override func makeSound() {
print("Woof!")
}
}
class Cat: Animal {
override func makeSound() {
print("Meow!")
}
}
Now:
let animals: [Animal] = [
Dog(),
Cat(),
Dog()
]
Loop:
for animal in animals {
animal.makeSound()
}
Output:
Woof!
Meow!
Woof!
The variable is treated as:
Animal
but the appropriate overridden implementation runs for each actual object.
That is runtime polymorphism through class inheritance.
Why Polymorphism Is Useful
Suppose a payment system supports:
Credit Card
PayPal
Apple Pay
Instead of writing separate calling code for every payment type, we can expose a common interface.
For example:
protocol PaymentMethod {
func pay(amount: Double)
}
Implementations:
class CreditCardPayment: PaymentMethod {
func pay(amount: Double) {
print("Paid \(amount) using Credit Card")
}
}
class ApplePayPayment: PaymentMethod {
func pay(amount: Double) {
print("Paid \(amount) using Apple Pay")
}
}
Now:
func processPayment(
using method: PaymentMethod,
amount: Double
) {
method.pay(amount: amount)
}
Use:
processPayment(
using: CreditCardPayment(),
amount: 100
)
processPayment(
using: ApplePayPayment(),
amount: 200
)
The calling function doesn’t need to know the implementation details of each payment type.
4. Abstraction in Swift
Abstraction means exposing the important behavior while hiding unnecessary implementation details.
Consider driving a car.
You use:
Accelerator
Brake
Steering Wheel
You don’t need to understand every internal engine process to drive the car.
Programming APIs work similarly.
Suppose:
class PaymentService {
func makePayment(amount: Double) {
validatePayment(amount)
connectToGateway()
processTransaction()
saveTransaction()
sendReceipt()
}
private func validatePayment(_ amount: Double) {
print("Validating payment")
}
private func connectToGateway() {
print("Connecting to gateway")
}
private func processTransaction() {
print("Processing transaction")
}
private func saveTransaction() {
print("Saving transaction")
}
private func sendReceipt() {
print("Sending receipt")
}
}
External code only needs:
paymentService.makePayment(amount: 100)
The internal steps are hidden.
That is abstraction.
Encapsulation vs Abstraction
These concepts are related but not identical.
Encapsulation
Focuses on:
Protecting and controlling state
Example:
private(set) var balance
Abstraction
Focuses on:
Hiding unnecessary implementation complexity
Example:
makePayment()
instead of forcing the caller to manually perform every payment-processing step.
A simple way to remember:
Encapsulation
↓
Protect internal state
Abstraction
↓
Hide unnecessary complexity
OOP with Protocols in Swift
Swift makes protocols extremely important.
A protocol defines requirements that conforming types must provide.
Example:
protocol Drivable {
func start()
func stop()
}
Now:
class Car: Drivable {
func start() {
print("Car started")
}
func stop() {
print("Car stopped")
}
}
Another type:
class Bike: Drivable {
func start() {
print("Bike started")
}
func stop() {
print("Bike stopped")
}
}
Both types share a common contract without needing the same superclass.
Protocol-Based Polymorphism
Protocols also enable polymorphism.
let vehicles: [Drivable] = [
Car(),
Bike()
]
Then:
for vehicle in vehicles {
vehicle.start()
}
Each type executes its own implementation.
This is extremely common in modern Swift design.
Protocols vs Inheritance
Inheritance creates relationships such as:
Animal
↓
Dog
Protocols describe capabilities:
Drivable
Payable
Downloadable
Serializable
Authenticatable
A class can inherit from only one superclass, but a type can conform to multiple protocols.
Example:
protocol Drivable {
}
protocol Trackable {
}
protocol Insurable {
}
Then:
class Car: Drivable, Trackable, Insurable {
}
This flexibility is one reason protocols are heavily used in Swift.
Composition in Swift
Another important design technique is composition.
Composition means building a type by giving it other objects or capabilities instead of putting everything into an inheritance hierarchy.
For example:
class Engine {
func start() {
print("Engine started")
}
}
Now:
class Car {
let engine: Engine
init(engine: Engine) {
self.engine = engine
}
func start() {
engine.start()
}
}
Here:
Car HAS an Engine
instead of:
Car IS an Engine
This is composition.
Inheritance vs Composition
Inheritance represents:
IS-A
Example:
Dog IS an Animal
Composition represents:
HAS-A
Example:
Car HAS an Engine
A useful design principle is:
Prefer composition when it models the relationship more naturally and avoids unnecessary inheritance coupling.
Real-World OOP Example: Employee System
Let’s create a small employee system.
Base class:
class Employee {
let id: Int
let name: String
init(id: Int, name: String) {
self.id = id
self.name = name
}
func performWork() {
print("\(name) is working")
}
}
Developer:
class Developer: Employee {
override func performWork() {
print("\(name) is writing code")
}
}
Designer:
class Designer: Employee {
override func performWork() {
print("\(name) is designing interfaces")
}
}
Manager:
class Manager: Employee {
override func performWork() {
print("\(name) is managing the team")
}
}
Create:
let employees: [Employee] = [
Developer(id: 1, name: "Alex"),
Designer(id: 2, name: "Emma"),
Manager(id: 3, name: "John")
]
Loop:
for employee in employees {
employee.performWork()
}
Output:
Alex is writing code
Emma is designing interfaces
John is managing the team
This example demonstrates:
Classes
Objects
Inheritance
Method Overriding
Polymorphism
Real-World OOP Example: Notification System
Protocols can often provide a more flexible design.
Define:
protocol NotificationSender {
func send(message: String)
}
Email:
class EmailNotification: NotificationSender {
func send(message: String) {
print("Email sent: \(message)")
}
}
Push notification:
class PushNotification: NotificationSender {
func send(message: String) {
print("Push notification sent: \(message)")
}
}
SMS:
class SMSNotification: NotificationSender {
func send(message: String) {
print("SMS sent: \(message)")
}
}
Service:
class NotificationService {
let sender: NotificationSender
init(sender: NotificationSender) {
self.sender = sender
}
func notifyUser(message: String) {
sender.send(message: message)
}
}
Use:
let service = NotificationService(
sender: PushNotification()
)
service.notifyUser(
message: "Your order has shipped!"
)
The service depends on:
NotificationSender
rather than one specific notification implementation.
This makes the design easier to extend and test.
Real-World OOP Example: Payment System
Define:
protocol PaymentProcessor {
func process(amount: Double)
}
Stripe:
class StripePaymentProcessor: PaymentProcessor {
func process(amount: Double) {
print("Processing \(amount) with Stripe")
}
}
Apple Pay:
class ApplePayProcessor: PaymentProcessor {
func process(amount: Double) {
print("Processing \(amount) with Apple Pay")
}
}
Checkout:
class CheckoutService {
private let paymentProcessor: PaymentProcessor
init(paymentProcessor: PaymentProcessor) {
self.paymentProcessor = paymentProcessor
}
func checkout(total: Double) {
paymentProcessor.process(amount: total)
}
}
Use:
let checkout = CheckoutService(
paymentProcessor: ApplePayProcessor()
)
checkout.checkout(total: 499)
Later, another payment provider can be introduced without rewriting the core checkout behavior.
Dependency Injection and OOP
The previous example demonstrates a concept called dependency injection.
Instead of creating a dependency internally:
class CheckoutService {
let processor = StripePaymentProcessor()
}
we provide it from outside:
class CheckoutService {
let processor: PaymentProcessor
init(processor: PaymentProcessor) {
self.processor = processor
}
}
Now different implementations can be supplied.
For example:
CheckoutService(
processor: StripePaymentProcessor()
)
or:
CheckoutService(
processor: ApplePayProcessor()
)
Benefits can include:
- Easier testing
- Lower coupling
- Greater flexibility
- Easier replacement of implementations
Reference Types in OOP
Swift classes are reference types.
Example:
class User {
var name: String
init(name: String) {
self.name = name
}
}
Create:
let user1 = User(name: "Alex")
let user2 = user1
Change:
user2.name = "Emma"
Print:
print(user1.name)
Output:
Emma
Why?
Because:
user1 ──┐
│
▼
User Object
▲
│
user2 ──┘
Both variables reference the same class instance.
This reference behavior is important when designing object-oriented Swift code.
Object Identity
Because classes are reference types, Swift can check whether two references point to the same object.
Use:
===
Example:
let user1 = User(name: "Alex")
let user2 = user1
print(user1 === user2)
Output:
true
Use:
!==
to check whether two references point to different objects.
Automatic Reference Counting
Swift manages the memory of class instances using:
Automatic Reference Counting (ARC).
ARC tracks strong references to class instances.
When an object no longer has strong references keeping it alive, Swift can deallocate it.
Example:
class User {
let name: String
init(name: String) {
self.name = name
print("\(name) created")
}
deinit {
print("\(name) removed")
}
}
Use:
var user: User? = User(name: "Alex")
user = nil
If no other strong references exist, the object can be deallocated.
Strong Reference Cycles
Reference types introduce an important memory-management concern.
Suppose:
Object A
↓
Object B
↓
Object A
If both references strongly retain each other, they can form a strong reference cycle.
Swift provides:
weak
unowned
references to help model relationships that should not keep an object alive.
Understanding ARC becomes especially important when working with:
- Delegates
- Closures
- View controllers
- Coordinators
- Services
- Parent-child object relationships
Type Casting in OOP
Sometimes you have a superclass reference but need to determine the concrete subclass.
Example:
class Animal {
}
class Dog: Animal {
func bark() {
print("Woof")
}
}
class Cat: Animal {
}
Create:
let animals: [Animal] = [
Dog(),
Cat()
]
Check:
for animal in animals {
if animal is Dog {
print("This is a dog")
}
}
Safe Downcasting
Use:
as?
Example:
for animal in animals {
if let dog = animal as? Dog {
dog.bark()
}
}
If the object isn’t a Dog, the cast returns nil.
This avoids a crash.
Forced Downcasting
Swift also provides:
as!
Example:
let dog = animal as! Dog
If the object isn’t actually a Dog, the program crashes.
For this reason, use forced casting only when you know the cast must succeed.
OOP and Structs in Swift
Traditional OOP discussions often focus heavily on classes.
However, Swift also gives structures a major role.
Example:
struct Product {
let id: Int
let name: String
let price: Double
}
A product model often doesn’t require object identity or inheritance.
Using a struct provides value semantics.
This is why modern Swift code often combines:
Structs → Data models and values
Classes → Shared identity/reference-based objects
Protocols → Common capabilities
Composition → Combine behavior
Extensions → Add functionality
rather than forcing every concept into a class hierarchy.
OOP vs Protocol-Oriented Programming
Object-oriented design often uses classes and inheritance.
Protocol-oriented design focuses on:
Protocols
+
Protocol Extensions
+
Composition
For example, instead of:
Vehicle
↓
Car
↓
ElectricCar
you might describe capabilities:
protocol Drivable {
func drive()
}
protocol Chargeable {
func charge()
}
Then:
struct ElectricCar: Drivable, Chargeable {
func drive() {
print("Driving")
}
func charge() {
print("Charging")
}
}
Swift supports both approaches.
Good Swift architecture often combines ideas rather than treating them as mutually exclusive.
OOP vs Functional Programming
Swift also supports functional programming concepts.
OOP often organizes code around:
Objects
State
Methods
Relationships
Functional approaches often emphasize:
Functions
Transformations
Immutability
Higher-order functions
For example:
let numbers = [1, 2, 3, 4]
let doubled = numbers.map { $0 * 2 }
This is a functional-style transformation.
Swift allows object-oriented and functional techniques to coexist.
Advantages of OOP in Swift
OOP can provide several benefits when used appropriately.
Code Organization
Related state and behavior can live together.
Reusability
Common behavior can be reused through protocols, composition, inheritance, or shared components.
Maintainability
Responsibilities can be separated into focused types.
Encapsulation
Internal state can be protected.
Extensibility
New implementations can be introduced behind common interfaces.
Testability
Well-designed dependencies can be replaced with test implementations.
Real-World Modeling
Concepts such as:
User
Order
Payment
Vehicle
Employee
Session
can often be modeled naturally as types.
Potential Problems with Poor OOP Design
OOP itself doesn’t automatically make code clean.
Poorly designed OOP can lead to:
- Huge classes
- Deep inheritance trees
- Excessive shared mutable state
- Tight coupling
- Difficult testing
- Too many responsibilities
- Unnecessary abstractions
For example:
class AppManager {
func login() {}
func fetchProducts() {}
func processPayment() {}
func uploadImage() {}
func sendNotification() {}
func saveDatabase() {}
func trackAnalytics() {}
}
One object controlling everything is difficult to maintain.
This is sometimes described as a God object.
A better design separates responsibilities.
Single Responsibility
A useful design principle is that a type should have a clear responsibility.
Instead of:
AppManager
├── Authentication
├── Payments
├── Networking
├── Database
└── Notifications
consider:
AuthService
PaymentService
APIService
DatabaseService
NotificationService
Each component has a clearer purpose.
SOLID Principles and OOP
As you progress beyond beginner-level OOP, you will likely encounter the SOLID principles.
SOLID represents five design principles:
S → Single Responsibility Principle
O → Open/Closed Principle
L → Liskov Substitution Principle
I → Interface Segregation Principle
D → Dependency Inversion Principle
You do not need to master SOLID immediately.
However, these principles can help you design object-oriented systems that are easier to extend, test, and maintain.
OOP Example: Simple Shopping System
Let’s combine several concepts.
Product:
struct Product {
let id: Int
let name: String
let price: Double
}
Cart:
class ShoppingCart {
private(set) var products: [Product] = []
func add(_ product: Product) {
products.append(product)
}
func calculateTotal() -> Double {
products.reduce(0) {
$0 + $1.price
}
}
}
Payment protocol:
protocol PaymentProcessor {
func pay(amount: Double)
}
Payment implementation:
class CardPayment: PaymentProcessor {
func pay(amount: Double) {
print("Paid \(amount) using card")
}
}
Checkout:
class CheckoutService {
private let paymentProcessor: PaymentProcessor
init(paymentProcessor: PaymentProcessor) {
self.paymentProcessor = paymentProcessor
}
func checkout(cart: ShoppingCart) {
let total = cart.calculateTotal()
paymentProcessor.pay(amount: total)
}
}
Use:
let phone = Product(
id: 1,
name: "iPhone",
price: 999
)
let watch = Product(
id: 2,
name: "Apple Watch",
price: 399
)
let cart = ShoppingCart()
cart.add(phone)
cart.add(watch)
let checkout = CheckoutService(
paymentProcessor: CardPayment()
)
checkout.checkout(cart: cart)
Output:
Paid 1398.0 using card
This small example demonstrates several Swift design concepts:
Struct
Class
Encapsulation
Protocol
Polymorphism
Composition
Dependency Injection
Common OOP Mistakes Beginners Make
Creating Classes for Everything
Not every Swift type needs reference semantics.
For simple data:
struct Product {
let id: Int
let name: String
}
may be more appropriate than a class.
Making Every Property Publicly Mutable
Instead of:
var balance: Double
consider whether external code really needs unrestricted write access.
Sometimes:
private(set) var balance: Double
provides a safer API.
Deep Inheritance Hierarchies
Avoid creating inheritance simply because OOP supports it.
For example:
A
↓
B
↓
C
↓
D
↓
E
can become difficult to reason about.
Protocols and composition may sometimes be clearer.
One Class Doing Everything
Avoid creating huge manager classes containing unrelated responsibilities.
Split them into focused services or types.
Excessive Shared Mutable State
Reference types can make state visible from many parts of an application.
Use shared mutable objects intentionally.
Value types can sometimes make state changes easier to reason about.
Ignoring Memory Management
Class references can participate in strong reference cycles.
Learn ARC, weak, and closure capture behavior as you progress.
OOP Cheat Sheet
Class
class User {
}
Object
let user = User()
Property
var name: String
Method
func greet() {
}
Initializer
init(name: String) {
self.name = name
}
Encapsulation
private(set) var balance: Double
Inheritance
class Dog: Animal {
}
Method Override
override func makeSound() {
}
Parent Implementation
super.makeSound()
Prevent Inheritance
final class UserManager {
}
Protocol
protocol Drivable {
func drive()
}
Protocol Conformance
class Car: Drivable {
func drive() {
}
}
Identity
object1 === object2
Safe Cast
object as? Dog
Practice Exercise 1: Student Class
Create:
class Student
with:
name
rollNumber
marks
Add:
calculateAverage()
displayProfile()
Practice Exercise 2: Bank Account
Create:
class BankAccount
with:
accountNumber
balance
deposit()
withdraw()
Use encapsulation to prevent invalid direct balance modifications.
Practice Exercise 3: Animal Inheritance
Create:
Animal
├── Dog
└── Cat
Add:
makeSound()
and override it in each subclass.
Practice Exercise 4: Payment Polymorphism
Create:
protocol PaymentMethod
Then:
CardPayment
ApplePayPayment
CashPayment
Make all of them provide:
pay()
Create one function capable of processing any PaymentMethod.
Practice Exercise 5: Notification System
Create:
protocol NotificationSender
Implement:
EmailSender
SMSSender
PushNotificationSender
Then inject one implementation into:
NotificationService
Frequently Asked Questions
What is OOP in Swift?
Object-Oriented Programming in Swift is a programming approach that uses types, especially classes and objects, to organize related data and behavior.
Swift supports OOP features including encapsulation, inheritance, polymorphism, abstraction, access control, and type casting.
What are the four pillars of OOP?
The four commonly taught OOP principles are:
Encapsulation
Inheritance
Polymorphism
Abstraction
What is an object in Swift?
An object is an instance of a class.
Example:
let user = User()
If User is a class, user refers to an instance of that class.
What is a class?
A class is a reference type that can contain properties, methods, initializers, and other behavior.
Classes also support inheritance and object identity.
What is encapsulation?
Encapsulation groups data and behavior while controlling access to internal state.
Swift access control such as private and private(set) can help implement encapsulation.
What is inheritance?
Inheritance allows a class to derive behavior and properties from another class.
Example:
class Dog: Animal {
}
What is polymorphism?
Polymorphism allows different concrete types to be used through a common superclass or protocol while providing their own behavior.
What is abstraction?
Abstraction exposes useful operations while hiding unnecessary implementation details.
Does Swift support multiple inheritance?
Swift classes cannot inherit from multiple classes.
However, a type can conform to multiple protocols.
Is a struct an object in Swift?
A struct is a value type rather than a class reference type.
Swift uses structures extensively, and many problems that might be modeled with classes in other languages are naturally modeled with structs in Swift.
Should I use classes or structs?
Use semantics as your guide.
A struct is often suitable when you want independent value behavior.
A class is useful when shared identity or reference semantics are required.
Is Swift purely object-oriented?
No.
Swift supports several programming paradigms, including:
Object-oriented programming
Protocol-oriented programming
Functional programming
Value-oriented programming
What is better: inheritance or protocols?
Neither is universally better.
Inheritance is useful for genuine class hierarchy relationships.
Protocols are useful for defining shared capabilities across different types.
Modern Swift frequently uses protocols and composition to avoid unnecessary inheritance.
Is SwiftUI object-oriented?
SwiftUI uses many Swift programming paradigms.
Views are commonly structures conforming to the View protocol, while reference types can still be used where shared identity and observable reference-based state are appropriate.
So SwiftUI should not be viewed as purely class-based OOP.
What Should You Learn After OOP in Swift?
After understanding OOP fundamentals, a useful learning path is:
OOP Fundamentals
↓
Struct vs Class
↓
Protocols
↓
Extensions
↓
Protocol-Oriented Programming
↓
Generics
↓
ARC & Memory Management
↓
Closures
↓
SOLID Principles
↓
Dependency Injection
↓
Design Patterns
↓
SwiftUI Architecture
These topics will help you move from writing simple Swift programs to designing larger applications.
Final Thoughts
Object-Oriented Programming is an important part of Swift development, but Swift gives developers more than traditional class-based OOP.
The four major OOP principles are:
ENCAPSULATION
Protect and control internal state
INHERITANCE
Reuse and specialize class behavior
POLYMORPHISM
Use different implementations through a common type
ABSTRACTION
Hide unnecessary implementation complexity
Swift then extends your design options with:
Structs
Protocols
Extensions
Generics
Closures
Composition
A simple class may begin as:
class User {
let name: String
init(name: String) {
self.name = name
}
func greet() {
print("Hello, \(name)")
}
}
But building maintainable Swift applications requires understanding more than how to create a class.
You should understand:
When identity matters
When value semantics are better
When inheritance makes sense
When protocols are more flexible
When internal state should be protected
When dependencies should be injected
The most important lesson is:
Good OOP is not about creating as many classes as possible. It is about giving each type a clear responsibility and designing relationships that make your application easier to understand, test, maintain, and extend.
Once you understand OOP together with Swift’s structs, protocols, and composition features, you will have a much stronger foundation for building real-world iOS and Swift applications.
