For my first real article, I’ll write about Object-Oriented Programming, reviewing what Alexander Shvets¹ defines, showing some practical usage in Ruby with references from Russ Olsen². I’ll also transition from Object-oriented programming to object-oriented design, present the definition of SOLID as discussed by Sandi Metz³, and list the 23 design patterns cataloged by the GoF⁴, separating them into their purposes.

Core Building#

First of all, we need to define what Object-oriented programming is:

As Alexander Shvets writes in his book, “Object-oriented programming is a paradigm based on the concept of wrapping a piece of data, and behavior related to that data, into special bundles called objects, which are constructed from a set of ‘blueprints’, defined by a programmer, called classes.”

But what does he mean by objects and classes, the main points of OOP?

Well, I’ll take an example with something I’m familiar with, rather than use animals or vehicles as usual. Take a football team. It has a name, it belongs to a city, has many titles and has a division. I root for Fluminense. It has all those attributes.

Fluminense is an object, Football Team is a class and all those data points are class fields. Other football teams will also share these class fields and also do the same things: play matches, compete in championships and hire or fire players. These are the class’ methods. Both fields and methods can be referenced as the members of their class.

So, for simple understanding, an object’s fields are referenced as state and an object’s methods define its behavior. A class is the blueprint that defines the structure for objects.

Here is an example of what is a class (Football Team) and what are instances of that class (Fluminense and Gama):

With that briefly explained, we can start talking about the pillars of OOP.

The Four Pillars of OOP#

To differentiate itself, OOP is based on four pillars:

Abstraction#

A model of a real-world object which represents all details relevant to this context with high accuracy and omits all the rest. For example, take a coffee machine. It has a lot of things going on, we need to boil water, brew the coffee beans and pour it in a cup, but all we need for this situation is the coffee for us to drink.

1
class CoffeeMachine
2
  # Public interface: The user only needs to press one button
3
  def make_coffee
4
    boil_water
5
    brew_coffee
6
    pour_in_cup
7
    puts "Your coffee is ready! ☕"
8
  end
9

10
  # Abstraction: Complex internal steps are hidden from the user
11
  private
12

13
  def boil_water
14
    puts "Boiling water..."
15
  end
16

17
  def brew_coffee
18
    puts "Brewing coffee grounds..."
19
  end
20

21
  def pour_in_cup
22
    puts "Pouring coffee..."
23
  end
24
end
25

26
# Usage
27
machine = CoffeeMachine.new
28
machine.make_coffee

Encapsulation#

The ability of an object to hide parts of its state and behaviors from other objects, exposing only a limited interface to the rest of the program. A common example used is when you use your key or a button to turn on your car. You don’t need to know what is happening inside, but you need to know that it’s working.

1
class BankAccount
2
  def initialize(owner, balance)
3
    @owner = owner
4
    @balance = balance # Hidden internal state
5
  end
6

7
  # Public method to safely modify internal data
8
  def deposit(amount)
9
    if amount > 0
10
      @balance += amount
11
      puts "Deposited $#{amount}. New balance: $#{@balance}."
12
    end
13
  end
14

15
  # Public method to read internal data safely
16
  def display_balance
17
    puts "#{@owner}'s balance: $#{@balance}."
18
  end
19

20
  private
21

22
  # Private method hidden from the outside world
23
  def internal_audit
24
    # Hidden system logic goes here
25
  end
26
end
27

28
# Usage
29
account = BankAccount.new("Alice", 1000)
30
account.deposit(500)         # Works: Deposited $500. New balance: $1500.
31
account.display_balance     # Works: Alice's balance: $1500.

Inheritance#

The ability to build new classes on top of existing ones. This helps with code reuse, avoids duplicate code when you need to create a class, and lets you focus on only extending the existing class and putting extra information into the resulting subclass.

1
# Parent class (Superclass)
2
class Animal
3
  def eat
4
    "Eating food..."
5
  end
6
end
7

8
# Child class (Subclass) inherits from Animal
9
class Dog < Animal
10
  def bark
11
    "Woof!"
12
  end
13

14
  # Overriding the parent's eat method
15
  def eat
16
    super + " specifically bones!"
17
  end
18
end
19

20
# Usage
21
my_dog = Dog.new
22

23
puts my_dog.bark  # Output: Woof!
24
puts my_dog.eat   # Output: Eating food... specifically bones!

Polymorphism#

The ability of a program to invoke a method on an object while the correct implementation is determined at runtime based on the object’s actual type, even when the declared type is a parent class or interface. It can also be the ability of an object to be treated as something else, usually a class it extends or an interface.

1
class Duck
2
  def make_sound
3
    puts "Quack!"
4
  end
5
end
6

7
class Dog
8
  def make_sound
9
    puts "Woof!"
10
  end
11
end
12

13
# This method does not care about the class type.
14
# It only cares that the object can respond to 'make_sound'.
15
def activate_sound(animal)
16
  animal.make_sound
17
end
18

19
# Usage
20
duck = Duck.new
21
dog = Dog.new
22

23
activate_sound(duck) # Output: Quack!
24
activate_sound(dog)  # Output: Woof!

With all that in mind, we can start migrating from OOP to OOD. For that, we will look forward to the SOLID Design Principles.

SOLID Design Principles#

• Single Responsibility (SRP): A class should have only one reason to change. It prevents the creation of massive “god classes”.

• Open/Closed (OCP): Software entities should be open for extension but closed for modification.

• Liskov’s Principle (LSP): Derived or child classes must be substitutable for their base or parent classes without breaking the functionality of the program.

• Interface Segregation (ISP): No client should be forced to depend on methods it does not use.

• Dependency Inversion (DIP): High-level modules should not depend on low-level modules.

We’ll explore these topics further in other posts, showing some code examples.

After that, we need to talk about patterns, which provide established solutions to many common design problems we’ll encounter in an Object-Oriented language.

Primary Design Patterns#

According to the GoF, there are 23 design patterns separated into 3 purposes: Creational, Structural and Behavioral. Each purpose can have two scopes: class or object.

Creational Patterns#

• Creational class patterns defer some part of object creation to subclasses.
• Creational object patterns defer it to another object.

Structural Patterns#

• Structural class patterns use inheritance to compose classes
• Structural object patterns describe ways to assemble objects

Behavioral Patterns#

• Behavioral class patterns use inheritance to describe algorithms and flow of control.
• Behavioral object patterns describe how a group of objects cooperate to perform a task no single object can carry out alone.

As we can see, it’s a lot to take in. For our next topic, we will examine SRP.

References#