Clean Code with Multiple Classes in Ruby

Welcome to the very first lesson of the "Clean Code with Multiple Classes in Ruby" course! 🎉 This course aims to guide you in writing code that's easy to understand, maintain, and enhance. Within the broader scope of clean coding, effective class collaboration is crucial for building well-structured applications. In this lesson, we will delve into the intricacies of class collaboration and coupling — key factors that can make or break the maintainability of your software. Specifically, we'll address some common "code smells" that indicate problems in class interactions and explore ways to resolve them.

Let's dive into the challenges of class collaboration by focusing on four common code smells:

• Feature Envy: Occurs when a method in one class is overly interested in methods or data in another class.
• Inappropriate Intimacy: Describes a situation where two classes are too closely interconnected, sharing private details.
• Message Chains: Refers to sequences of method calls across several objects, indicating a lack of clear abstraction.
• Middle Man: Exists when a class mainly delegates its behavior to another class without adding functionality.

Understanding these code smells will enable you to improve your class designs, resulting in cleaner and more maintainable code.

These code smells can significantly impact system design and maintainability. Let's consider their implications:

• They can lead to tightly coupled classes, making them difficult to modify or extend. 🔧
• Code readability decreases, as it becomes unclear which class is responsible for which functionality.

Addressing these issues often results in code that's not only easier to read but also more flexible and scalable. Tackling these problems can markedly enhance software architecture, making it more robust and adaptable.

Feature Envy occurs when a method in one class is more interested in the fields or methods of another class than its own. Here's an example in Ruby:

class ShoppingCart
  def initialize
    @items = []
  end
  
  def calculate_total_price
    total = 0
    @items.each do |item|
      total += item.price * item.quantity
    end
    total
  end
end

class Item
  attr_accessor :price, :quantity
  
  def initialize(price, quantity)
    @price = price
    @quantity = quantity
  end
end

In this scenario, calculate_total_price in ShoppingCart overly accesses data from Item, indicating feature envy.

To refactor, consider moving the logic to the Item class:

class ShoppingCart
  def initialize
    @items = []
  end
  
  def calculate_total_price
    total = 0
    @items.each do |item|
      total += item.calculate_total
    end
    total
  end
end

class Item
  attr_accessor :price, :quantity
  
  def initialize(price, quantity)
    @price = price
    @quantity = quantity
  end
  
  def calculate_total
    price * quantity
  end
end

Now, each Item calculates its own total, reducing dependency and distributing responsibility appropriately. ✔️

Inappropriate Intimacy occurs when a class is overly dependent on the internal details of another class. Here's an example in Ruby:

class Library
  def initialize(book)
    @book = book
  end

  def print_book_details
    puts "Title: #{@book.title}"
    puts "Author: #{@book.author}"
  end
end

class Book
  attr_accessor :title, :author
  
  def initialize(title, author)
    @title = title
    @author = author
  end
end

In this scenario, the Library class relies too heavily on the details of the Book class, demonstrating inappropriate intimacy.

To refactor, allow the Book class to handle its own representation:

class Library
  def initialize(book)
    @book = book
  end

  def print_book_details
    puts @book.details
  end
end

class Book
  attr_accessor :title, :author
  
  def initialize(title, author)
    @title = title
    @autor = author
  end
  
  def details
    "Title: #{title}\nAuthor: #{author}"
  end
end

This adjustment enables Book to encapsulate its own details, encouraging better encapsulation and separation of concerns. 🛡️

Message Chains occur when classes need to traverse multiple objects to access the methods they require. Here's a demonstration in Ruby:

class User
  attr_accessor :address

  def initialize(address)
    @address = address
  end
end

class Address
  attr_accessor :zip_code

  def initialize(zip_code)
    @zip_code = zip_code
  end
end

class ZipCode
  def self.postal_code
    "90210"
  end
end

# Usage
user = User.new(Address.new(ZipCode))
postal_code = user.address.zip_code.postal_code

The chain user.address.zip_code.postal_code illustrates this problem.

To simplify, encapsulate the access within methods:

class User
  attr_accessor :address

  def initialize(address)
    @address = address
  end
  
  def user_postal_code
    address.postal_code
  end
end

class Address
  attr_accessor :zip_code
  
  def initialize(zip_code)
    @zip_code = zip_code
  end
  
  def postal_code
    zip_code.postal_code
  end
end

class ZipCode
  def self.postal_code
    "90210"
  end
end

# Usage
user = User.new(Address.new(ZipCode))
postal_code = user.user_postal_code

This adjustment makes the User class responsible for retrieving its postal code, creating a clearer and more direct interface. 📬

A Middle Man problem occurs when a class primarily exists to delegate its functionalities. Here's an example in Ruby:

class Controller
  def initialize(service)
    @service = service
  end

  def execute
    @service.perform_action
  end
end

class Service
  def perform_action
    # Action performed
  end
end

The Controller doesn't do much beyond delegating to Service.

To refactor, simplify delegation or reassign responsibilities:

class Service
  def perform_action
    # Action performed
  end
end

# Usage
service = Service.new
service.perform_action

By removing the unnecessary middleman, the design becomes more streamlined and efficient. 🔥

In this lesson, you've explored several code smells associated with suboptimal class collaboration and coupling, including Feature Envy, Inappropriate Intimacy, Message Chains, and Middle Man. By identifying and refactoring these smells, you can elevate your code's clarity and maintainability.

Get ready to put these concepts into practice with upcoming exercises, where you'll identify and refactor code smells, strengthening your skills. Keep striving for cleaner, more effective code! 🌟