Introduction: Organizing Your Tools

Ever notice how the messiest parts of your code are often where you’re handling different cases or variations? Maybe it’s different file formats, payment methods, or shipping calculations. That’s exactly what we’re going to tackle today with one of the most practical object-oriented design principles: ‘Encapsulate what varies.’

Think of it like organizing your tools. Instead of having screwdrivers and wrenches scattered throughout the shop and house, you put them all in one toolbox. Now, when you need to change or add a tool, you know exactly where to go. That’s what we mean by encapsulation in code – taking the parts that might change and putting them in a well-defined place. Okay, yes. There is that one screwdriver that always ends up in the kitchen drawer, but sometimes a little duplication is better than an unhappy spouse.

In this article, we’ll look at how this principle can transform messy, hard-to-maintain code into something clean and flexible. I’ll show you real examples in Ruby, and by the end, you’ll have a new tool for keeping your code organized and easy to change.

The Core Principle Explained

Encapsulate what varies is all about isolating the parts of your code that might change. It’s a simple idea, but it can have a big impact on how you structure your code. By putting the things that vary in one place, you make your code more flexible and easier to maintain.

Imagine you’re working on an woodworking platform that sells many types of dressers. Each dresser can be of a different type and have a different assembly process for one kind of dresser. If you scatter these variations throughout your code, or conflate them with other code you’ll end up with a tangled mess that’s hard to understand and change.

By encapsulating what varies, you can isolate these differences in one place. This makes your code easier to read, test, and extend. When you need to add a new dresser type or change the assembly logic, you know exactly where to look.

A Practical Example

🔍 In this post, we’ll use Ruby 3.1 for code examples with endless methods for brevity, but the principles here apply to any object-oriented language.

Here’s a simple example to illustrate the concept. Suppose you have a class that builds a dresser based on the dresser type. You could write a single method that handles all these variations:

class DresserBuilder
  def self.construct(type)
    case type
    when :armoire
      dresser = Armoire.new
    when :highboy
      dresser = Highboy.new
    when :bombe
      dresser = Bombe.new
    else
      raise ArgumentError, "Unknown dresser type: #{type}"
    end

    dresser.select_wood
    dresser.cut_pieces
    if type == :armoire
      dresser.join_traditionally
    else
      dresser.join_with_screws
    end
    dresser.finish

    puts "Dresser built!"

    dresser
  end
end

# Usage
armoire = DresserBuilder.construct(:armoire)
# => Dresser built!

This code works, but it’s not very flexible. What if you need to add a new dresser type or change the assembly process for one kind of dresser? You’d have to modify this method, which violates the Open/Closed Principle of SOLID.

Let’s apply the ’encapsulate what varies’ principle to this code. We’ll create a separateDresserFactory class to handle the creation of different dresser types. This class will encapsulate the choice of dresser type and return the appropriate dresser object:

class DresserFactory
  def self.make(type)
    case type
    when :armoire
      Armoire.new
    when :highboy
      Highboy.new
    when :bombe
      Bombe.new
    else
      raise ArgumentError, "Unknown dresser type: #{type}"
    end
  end
end

class DresserBuilder
  def self.construct(type)
    dresser = DresserFactory.make(type)

    dresser.select_wood
    dresser.cut_pieces
    if type == :armoire
      dresser.join_traditionally
    else
      dresser.join_with_screws
    end
    dresser.finish

    puts "Dresser built!"

    dresser
  end
end

# Usage
armoire = DresserBuilder.construct(:armoire)
# => Dresser built!

Now we can easily add new types without modifying the Dresser class. This is better, but what if the assembly process varies between dresser types? You’d have to modify the Dresser class again.

Strategy Pattern

Let’s take it a step further and use the Strategy pattern to encapsulate the assembly process in separate classes. This way, each dresser type can have its own assembly logic, and we can easily change that without changing the Dresser class:

class DresserFactory
  BLUEPRINTS = {
    armoire: Armoire,
    highboy: Highboy,
    bombe: Bombe
  }.freeze

  def self.make(type)
    BLUEPRINTS.fetch(type) { 
      raise ArgumentError, "Unknown dresser type: #{type}"
    }.new
  end
end

module Assembleable
  def assemble = raise NotImplementedError
end

class AbstractDresser
  include Assembleable
end

class Armoire < AbstractDresser
  def assemble
    select_wood
    cut_pieces
    join_traditionally
    finish_with_lacquer
  end

  private

  def select_wood = puts "Selecting wood for armoire"
  def cut_pieces = puts "Cutting pieces for armoire"
  def join_traditionally = puts "Assembling armoire traditionally"
  def finish_with_lacquer = puts "Finishing armoire with lacquer"
end

class DresserBuilder
  def self.construct(type)
    dresser = DresserFactory.make(type)
    dresser.assemble

    puts "Dresser built!"

    dresser
  end
end

# Usage
armoire = DresserBuilder.construct(:armoire)
# => Selecting wood for armoire
# => Cutting pieces for armoire
# => Assembling armoire traditionally
# => Finishing armoire with lacquer
# => Dresser built!

Now, each dresser type has its own class, and the Dresser class delegates the assembly process to the appropriate type. We’ve also taken this opportunity to update the DresserFactory class to trade the case statement for a hash of blueprints for each dresser type. This way, adding a new type is as simple as adding a new entry to the hash.

Common Patterns That Apply This Principle

The ’encapsulate what varies’ principle is closely related to several design patterns that help you manage change in your code. Above, we used the Strategy pattern to encapsulate the assembly process for different dresser types and the Factory Method pattern to create instances of these types.

Tips for Identifying Varying Elements

When applying the ’encapsulate what varies’ principle, it’s essential to identify the parts of your code that are likely to change. Here are some tips to help you spot these elements:

• Look for conditional logic: If you have a lot of if statements or case blocks that handle different cases, those are good candidates for encapsulation.
• Think about future requirements: Consider what might change in the future and how you can isolate those changes.
• Separate concerns: If you have different concerns mixed together in one class or method, try to separate them into distinct components.
• Code analysis: Use tools like static code analysis or code reviews to identify parts of your code that change frequently.

Common Pitfalls

While the ’encapsulate what varies’ principle is a powerful tool for managing change, there are some common pitfalls to watch out for:

• Overengineering: Don’t go overboard and create unnecessary abstractions. Keep it simple and refactor only when it makes sense.
• Premature optimization: Don’t try to predict every possible change upfront.
• Ignoring SOLID principles: Remember that encapsulation is just one part of good object-oriented design. Make sure your code follows other principles like the Single Responsibility Principle and the Open/Closed Principle.
• Not testing variations: When you encapsulate what varies, make sure to test each variation thoroughly. It’s easy to introduce bugs when you refactor code, so testing is crucial.

Keep these pitfalls in mind as you apply this principle in your code. With practice, you’ll get better at identifying the parts that might change and encapsulating them effectively.

Conclusion

The ’encapsulate what varies’ principle is a powerful tool for managing change in your code. By isolating the parts that are likely change, you make your code more flexible, maintainable, and testable. Whether you’re working on an e-commerce platform, a game engine, or a woodworking platform, this principle can help you keep your code organized and easy to extend.

And yes, sometimes that screwdriver will still end up in the kitchen drawer, but sometimes that’s just where it needs to be to maintain household harmony.

🔍 This post is part of the SOLID++ series where we are exploring principles of object-oriented design beyond the five SOLID principles.

Introduction: getting to know Demeter

Have you ever looked at your code and thought ‘Why does this class need to know about that other class’s internal workings?’ Such dependencies can make code difficult to understand, maintain, and test. The Law of Demeter, also known as the principle of least knowledge, offers a way out of this complexity. Let’s explore how this principle can help you write cleaner, more maintainable code.

🔍 This post is part of the SOLID++ series where we are exploring principles of object-oriented design beyond the five SOLID principles.

What is the Law of Demeter?

The Law of Demeter suggests that a given object should only interact with its immediate collaborators and not reach through them to interact with other objects’ methods or data. This helps reduce coupling and increase modularity in code. Think of how you interact with a restaurant - you talk to the waiter, not the chef directly. The Law of Demeter works similarly in code.

Why follow Demeter?

Following Demeter’s law offers several benefits:

• It makes your code more modular and easier to understand
• It reduces coupling between objects
• It simplifies refactoring and maintenance

Now let’s roll up our sleeves and look at some code that needs help.

🔍 In this post, we’ll use Ruby 3.1 for code examples with endless methods for brevity, but the principles of Demeter apply to any object-oriented language.

Common violations: spotting the problem

Let’s look at an example of a Demeter violation:

class Engine
  def start = 'Engine started!'
end

class Car
  attr_reader :engine

  def initialize(engine) = (@engine = engine)
end

car = Car.new(Engine.new)
car.engine.start  # Violation

Can you spot the violation here? The violation is that the Car class is directly accessing the Engine object’s start method. This breaks Demeter’s law by reaching too far into the Engine object.

Common violations: fixing the problem

Let’s fix this violation by introducing a method in the Car class to start the engine:

class Engine
  def start = 'Engine started!'
end

class Car
  def initialize(engine) = (@engine = engine)
  def start_engine = engine.start
end

# Usage
car = Car.new(Engine.new)
car.start_engine  # Violation fixed

In this refactored version, we’ve introduced a start_engine method in the Car class that delegates the call to the Engine object. This way, we avoid violating Demeter’s law.

Another example: spotting the problem

class Project
  attr_reader :manager

  def initialize(manager) = (@manager = manager)
end

class Manager
  attr_reader :team

  def initialize(team) = (@team = team)
end

class Team
  def lead = "Alice"
end

project = Project.new(Manager.new(Team.new))
puts project.manager.team.lead  # Violation

When you are reviewing code, look for long chains of method calls like this (aka, “dot chains”). They are often the code smell for Demeter violations. In this example, the Project class is directly accessing the lead method of the Team object through the Manager object. This is another violation of Demeter’s law.

Another example: fixing the problem

class Project
  def initialize(manager) = (@manager = manager)
  def team_lead = @manager.team_lead
end

class Manager
  def initialize(team) = (@team = team)
  def team_lead = @team.lead
end

class Team
  def lead = "Alice"
end

project = Project.new(Manager.new(Team.new))
puts project.team_lead  # No violation

In this corrected version, we’ve introduced a team_lead method in the Project class that delegates the call to the Team object through the Manager object. This way, we avoid violating Demeter’s law by better encapsulating the behavior.

Using Ruby’s built-in tools

In the previous examples, we could have used Ruby’s forwardable module to delegate the method call. This is a common pattern in Ruby to avoid Demeter violations. Let’s refactor the previous example using forwardable:

require 'forwardable'

class Project
  extend Forwardable

  def_delegator :@manager, :team_lead, :team_lead

  def initialize(manager) = (@manager = manager)
end

class Manager
  extend Forwardable

  def_delegator :@team, :lead, :team_lead

  def initialize(team) = (@team = team)
end

class Team
  def lead = "Alice"
end

# Usage
project = Project.new(Manager.new(Team.new))
puts project.team_lead  # No violation

In this refactored version, we’ve used Ruby’s forwardable module to delegate the team_lead method call from the Project class to the Team object through the Manager object. This is a clean and concise way to avoid Demeter violations.

Demeter on Rails: the delegate method

Rails ActiveSupport provides a bit of syntactic sugar to make following Demeter even easier. Let’s use the delegate method to refactor the previous example:

class Project
  delegate :team_lead, to: :@manager

  def initialize(manager) = (@manager = manager)
end

class Manager
  delegate :team_lead, to: :@team

  def initialize(team) = (@team = team)
end

class Team
  def team_lead = "Alice"
end

# Usage
project = Project.new(Manager.new(Team.new))
puts project.team_lead  # No violation

The delegate method allows us to easily forward method calls to associated objects, keeping our Rails code clean and readable.

Exceptions to the rule

While Demeter is generally a good practice, there are situations where you might need to bend the rules:

When working with external APIs or libraries

class WeatherService
  def temperature = WeatherAPI.get_temperature
end

class WeatherAPI
  def self.get_temperature = 25
end

service = WeatherService.new
puts service.temperature

Why does this not violate Demeter? Because the WeatherService class is directly accessing the get_temperature method of the WeatherAPI class. In this case, it might be acceptable due to the nature of the external API.

When working with data structures like hashes or arrays

class WeatherService
  def temperature = WeatherAPI.weather_data[:temperature]
end

class WeatherAPI
  def self.weather_data = { temperature: 25 }
end

service = WeatherService.new
puts service.temperature

Why does this not violate Demeter? Because the WeatherService class is directly accessing the temperature attribute of the weather_data hash. In this case, it might be acceptable due to the nature of the data structure.

In cases of immutability

class User
  attr_reader :name

  def initialize(name) = (@name = name)
end

class Greeting
  def initialize(user) = (@user = user)

  def greet = "Hello, #{user.name}!"
end

user = User.new("Alice")
greeting = Greeting.new(user)
puts greeting.greet

Why does this not violate Demeter? Because the Greeting class is directly accessing the name attribute of the User object. In this case, it might be acceptable due to the immutability of the User object.

With certain design patterns like Builder

class User
  attr_reader :name

  def initialize(name) = (@name = name)
end

class UserBuilder
  attr_reader :user

  def initialize = (@user = User.new)

  def with_name(name)
    user.name = name
    self
  end

  def build = user
end

builder = UserBuilder.new
user = builder.with_name("Alice").build
puts user.name

Why does this violate Demeter? Because the UserBuilder class is directly accessing the name attribute of the User object. In this case, it might be acceptable due to the nature of the Builder pattern. That is, the UserBuilder class is responsible for constructing the User object.

Testing benefits

Following Demeter’s law can make your code easier to test. By reducing the coupling between objects, you can write more focused unit tests that don’t need to know about the internal details of other objects. This makes your tests more resilient to changes and easier to maintain. For example:

class Engine
  def start = 'Engine started!'
end

class Car
  def initialize(engine) = (@engine = engine)
  def start_engine = engine.start
end

# Test
RSpec.describe Car do
  it 'starts the engine' do
    engine = instance_double(Engine, start: 'Engine started!')
    car = Car.new(engine)
    expect(car.start_engine).to eq('Engine started!')
  end
end

In this test, we’re able to mock the Engine object and focus on testing the Car class in isolation. This is possible because the Car class follows Demeter’s law and doesn’t reach into the Engine object.

Common pitfalls: when to be cautious

While Demeter is a powerful principle, there are some common pitfalls to be aware of:

• Overuse of delegation: Be cautious of overusing delegation, as it can lead to excessive method chaining and complexity.
• Excessive abstraction: Avoid creating unnecessary layers of abstraction just to follow Demeter. Sometimes direct access is more readable and maintainable.
• Performance concerns: Excessive delegation can lead to performance issues due to the overhead of method calls.
• Contextual understanding: Sometimes direct access to an object’s methods can provide better context and understanding of the code.
• Code readability: While Demeter aims to improve code readability, excessive delegation can sometimes have the opposite effect.

To avoid these pitfalls, use your best judgment and consider the specific requirements of your codebase. While being careful not to overcomplicate things in the name of following Demeter, also don’t use these pitfalls as an excuse to ignore the principle altogether.

Conclusion: Putting Demeter into Practice

As you start applying the Law of Demeter, you’ll notice your code becoming more modular and easier to understand. Changes that once felt risky become straightforward, and refactoring becomes less of a headache.

Remember, Demeter is not a strict rule but a guideline to help you write cleaner, more maintainable code. Use it wisely, and your code will thank you.

Introduction

Ever been stuck in a tangled inheritance hierarchy where changing one parent class feels like playing software Jenga? You’re not alone. I found myself in that situation once while writing a font creation library. The rigid hierarchy and fragile base class led to a brittle solution that was difficult to extend and maintain. While inheritance is a powerful feature of object-oriented programming, it’s often not the best tool for the job. Let’s explore a more flexible alternative: composition.

As part of the SOLID++ series, we are exploring principles of object-oriented design beyond the five SOLID principles. Here we’ll discuss the idea of favoring composition over inheritance. First, we’ll look at some different types of composition and then dive into the reasons why it’s often preferred over inheritance. All code examples are written for Ruby 3.1. using endless methods for brevity.

Different types of composition

Before diving into why composition is often better than inheritance, let’s look at seven common ways to compose objects. Each approach has its own strengths and use cases.

1. Has-a aggregation

This is where an object contains a reference to another object, but the contained object can exist independently. Think of a Team that has Players - the Players can exist even if the Team dissolves:

class Player
  attr_reader :name
  def initialize(name) = (@name = name)
end

class Team
  def initialize = (@players = [])
  def add_player(player) = (@players << player)
end

# Usage
t_rex = Player.new("T. Rex")
raptors = Team.new
raptors.add_player(t_rex)

Use this when objects have independent lifecycles and loose coupling is desired.

2. Part-of aggregation

Part-of aggregation is a stronger form of aggregation where the contained object’s lifecycle is tied to the container. This is useful when objects are tightly coupled. Think of a Car and its Engine - the Engine only exists as part of the Car:

class Engine
  def start = "Let's go!"
end

class Car
  def initialize = (@engine = Engine.new)
  def start = @engine.start
end

# Usage
car = Car.new
car.start  # => "Let's go!"

Use this when objects are tightly coupled and the contained object can’t exist without the container.

3. Dependency injection

This is where dependencies are passed in rather than created internally. Useful for creating flexlible, testable code.

class PaymentProcessor
  def initialize(payment_gateway) = (@payment_gateway = payment_gateway)
  def process_payment(amount) = @payment_gateway.charge(amount)
end

# Different gateways can be injected
class StripeGateway
  # This is pseudo-code and the actual API may be different
  def charge(amount) = Stripe::Charge.create(amount: amount)
end

class PayPalGateway
  # This is pseudo-code and the actual API may be different
  def charge(amount) = PayPal::Charge.create(amount: amount)
end

# Usage
processor = PaymentProcessor.new(StripeGateway.new)
processor.process_payment(100)

Use this when you want to decouple components and make them easier to test.

4. Delegation

Ruby has built-in support for delegation with forwardable. Used to forward messages while maintaining encapsulation.

require 'forwardable'

class Writer
  extend Forwardable
  
  def_delegators :@formatter, :format_text
  
  def initialize(formatter) = (@formatter = formatter)
end

class HTMLFormatter
  def format_text(text) = "<p>#{text}</p>"
end

# Usage
html_writer = Writer.new(HTMLFormatter.new)
html_writer.format_text("Hello, world!")  # => "<p>Hello, world!</p>"

Use this when you want to forward messages to another object while maintaining encapsulation.

5. Role/trait composition (similar to mixins but more flexible)

Used for the additions of dynamic behavior. This is where objects can gain or lose behaviors at runtime:

module Swimming
  def swim = "swimming"
end

module Flying
  def fly = "flying"
end

class Bird
  def initialize = (@behaviors = [])
  
  def add_behavior(behavior)
    extend(behavior)
    @behaviors << behavior
  end
  
  # Note: In real code, you'd need a more sophisticated way to remove modules
  # as this would only remove the behavior from the array and not undo the extend
  # operation.
  def remove_behavior(behavior) = @behaviors.delete(behavior)
end

# Usage
duck = Bird.new
duck.add_behavior(Swimming)
duck.add_behavior(Flying)
duck.swim  # => "swimming"
duck.fly   # => "flying"

Use this when you want to add or remove behaviors dynamically.

6. Strategy pattern

This is similar to dependency injection but focused on encapsulating algorithms. This is one of the more commonly used patterns in real-world applications.

class PricingStrategy
  def calculate_price(base_price) = raise NotImplementedError
end

class RegularPricing < PricingStrategy
  def calculate_price(base_price) = base_price
end

class DiscountPricing < PricingStrategy
  def calculate_price(base_price) = (base_price * 0.9)
end

class Product
  def initialize(pricing_strategy) = (@pricing_strategy = pricing_strategy)
  def price(base_price) = (@pricing_strategy.calculate_price(base_price))
end

# Usage
product = Product.new(DiscountPricing.new)
product.price(10)  # => 9.0

Notice that the example above appears to use inheritance, but the base class PricingStrategy is an abstract class that defines an interface for concrete strategies to implement. This is a form of composition because the Product class is composed of a pricing strategy.

Use the strategy pattern when you want to encapsulate algorithms and make them interchangeable.

7. Decorator pattern

This is where objects can be wrapped in other objects to add behaviors.

class Coffee
  def cost = 3.00
  def description = "Plain coffee"
end

class MilkDecorator
  def initialize(coffee) = (@coffee = coffee)
  def cost = (@coffee.cost + 0.50)
  def description = (@coffee.description + " with milk")
end

# Usage
coffee = Coffee.new
coffee_with_milk = MilkDecorator.new(coffee)
coffee_with_milk.cost  # => 3.50

Use the decorator pattern when you want to add behaviors to objects at runtime.

Now that we’ve seen the various ways objects can work together through composition, let’s tackle the big question: Why should we usually prefer these approaches over inheritance?

Favoring composition over inheritance

The core argument for composition over inheritance is that inheritance can lead to tight coupling between parent and child classes. This can lead to several problems:

1. Fragile base class problem

When you change something in a parent class, it can unexpectedly break child classes in ways that are hard to predict. For example, if you have a Bird parent class and modify how its fly() method works, you might accidentally break specific bird implementations that were relying on the old behavior.

2. Rigid hierarchy

Inheritance hierarchies are fixed at compile-time and can’t be changed at runtime. With composition, you can easily swap behaviors at runtime, making your code more flexible.

3. The “is-a” relationship isn’t always clear

Sometimes what seems like an “is-a” relationship isn’t actually appropriate. The classic example is Square inheriting from Rectangle. While mathematically a square is a rectangle, in code this can violate the Liskov Substitution Principle because a square’s width and height must always be equal.

4. Limited to single inheritance

In languages with single inheritance (like Java, Ruby, etc.), you’re forced to choose one parent class. With composition, you can combine multiple behaviors.

5. Testing and maintenance

Composition makes testing easier because you can mock or stub out components. It also makes maintenance easier because changes are more localized and don’t ripple through an inheritance hierarchy.

Conclusion

We’ve covered a lot of ground in our exploration of composition! While inheritance is a fundamental feature of object-oriented programming, we’ve seen how composition often provides more flexible, maintainable solutions. Let’s recap when to use each approach.

Choose composition when:

• You need runtime flexibility (like our Bird with swappable movement behaviors)
• The relationship between objects is “has-a” rather than “is-a”
• You want to keep your components loosely coupled
• You need to combine multiple behaviors (remember our swimming, flying duck!)

Stick with inheritance when:

• You have a true “is-a” relationship that won’t change over time
• The parent class is stable and well-designed
• You’re extending framework classes that expect inheritance
• The child class is a proper behavioral subtype of the parent

Think of composition as building with LEGO blocks instead of sculpting from a single piece of clay. With LEGO, you can easily snap pieces together, rearrange them, or swap them out. That flexibility is exactly what makes composition so powerful in software design.

In our next article, we’ll explore another powerful OOD principle: the Law of Demeter. We’ll see how this principle helps us write code that’s more maintainable by reducing dependencies between objects. Until then, try looking at your current codebase - are there places where composition might work better than inheritance?

Remember: Good design isn’t about following rules blindly. It’s about understanding the trade-offs and choosing the right tool for the job. Sometimes that tool will be inheritance, but more often than not, composition will give you the flexibility you need to build maintainable, adaptable software.

• Cover image designed by Freepik

Introduction

If you’ve been writing object-oriented code for a while, you’ve probably heard of the SOLID principles. These five guidelines have become so fundamental to OO design that they’re often treated as the complete playbook for writing good code. But here’s the thing - they’re just the beginning.

Beyond SOLID

The SOLID principles, introduced by Robert C. Martin (affectionately known as “Uncle Bob”) in the early 2000s, are like the foundation of a well-built house. They give us a stable base for creating code that’s easier to maintain, extend, and understand. You can find a good explanation of them in this post at freeCodeCamp. Briefly, the SOLID principles are:

Single Responsibility Principle - A class should do one thing, and do it well
Open/Closed Principle - Open for extension, closed for modification
Liskov Substitution Principle - Subtypes must be substitutable for their base types
Interface Segregation Principle - Clients should not be forced to depend on interfaces they do not use
Dependency Inversion Principle - High-level modules should not depend on low-level modules; both should depend on abstractions

While SOLID principles are fantastic tools for good design, they’re part of a larger toolbox. There are several other powerful OOD principles that can take your code to the next level. In this series, we’ll explore three of my favorites:

1. Composition Over Inheritance - Learn when to favor object composition over class inheritance
2. Law of Demeter - Discover how to write code that minds its own business
3. Encapsulate What Varies - Master the art of isolating change

While SOLID principles provide an excellent foundation for object-oriented design, they’re just the beginning of your journey toward writing exceptional code. In the upcoming posts, we’ll explore these additional principles through practical examples and real-world scenarios. By the end of this series, you’ll have new tools to help you write code that’s not just solid - it’s outstanding.

Conclusion

Stay tuned for our next post, where we’ll dive into Composition Over Inheritance and learn why sometimes it’s better to have a friend than a complex relationship with parents!

• Cover image designed by pikisuperstar / Freepik