Javier Valencia

Etiqueta: abstracción

  • Comparando el estilo “clásico orientado a clases” con el estilo Ruby-idiomático, funcional y modular

    Vamos a aterrizar la idea de Dave Thomas con código Ruby real, comparando el estilo “clásico orientado a clases” con el estilo Ruby-idiomático, funcional y modular, y viendo por qué el segundo suele envejecer mejor.

    No es una religión. Es ingeniería pragmática.

    1. El punto de partida clásico (el reflejo Java)

    Imagina un caso típico: procesar un pedido.

    Enfoque habitual con clases

    class Order
  attr_reader :items, :customer

  def initialize(items:, customer:)
    @items = items
    @customer = customer
  end

  def total_price
    items.sum(&:price)
  end

  def valid?
    items.any? && customer.active?
  end
end

class OrderProcessor
  def initialize(order)
    @order = order
  end

  def process
    raise "Invalid order" unless @order.valid?

    charge_customer
    send_confirmation
  end

  private

  def charge_customer
    PaymentGateway.charge(@order.customer, @order.total_price)
  end

  def send_confirmation
    Mailer.order_confirmation(@order)
  end
end

    Esto es correcto. También es más estructura de la necesaria.

    Problemas sutiles:

    • Las clases no modelan cosas del mundo real, sino pasos de un flujo
    • La lógica está dispersa
    • Probar OrderProcessor implica instanciar Order
    • La clase existe solo para agrupar métodos

    2. La propuesta de Dave Thomas: empieza por acciones

    Ruby no te obliga a empezar pensando en “objetos”.
    Puedes empezar pensando en verbos.

    Enfoque funcional y plano

    def total_price(items)
  items.sum(&:price)
end

def valid_order?(items, customer)
  items.any? && customer.active?
end

def process_order(items:, customer:)
  raise "Invalid order" unless valid_order?(items, customer)

  PaymentGateway.charge(customer, total_price(items))
  Mailer.order_confirmation(items, customer)
end

    Observa algo importante:

    • No hay estado implícito
    • Cada función hace una cosa
    • Las dependencias son explícitas
    • Es trivial testear cada función

    Esto ya es Ruby de primera clase, no un atajo.

    3. “Pero esto queda desordenado”: módulos al rescate

    Aquí es donde mucha gente se pone nerviosa.
    Dave Thomas dice: no saltes a clases, usa módulos.

    module Orders
  module Pricing
    def self.total(items)
      items.sum(&:price)
    end
  end

  module Validation
    def self.valid?(items, customer)
      items.any? && customer.active?
    end
  end

  module Processing
    def self.process(items:, customer:)
      raise "Invalid order" unless Validation.valid?(items, customer)

      PaymentGateway.charge(customer, Pricing.total(items))
      Mailer.order_confirmation(items, customer)
    end
  end
end

    Esto aporta:

    • Namespacing claro
    • Ningún estado oculto
    • Ninguna jerarquía artificial
    • Código legible como un mapa mental del dominio

    4. ¿Cuándo sí aparece una clase?

    Dave Thomas no es anti-clases.
    Las clases aparecen cuando hay identidad y estado duradero.

    Ejemplo: un Money, un User, un Session.

    class Money
  attr_reader :amount, :currency

  def initialize(amount, currency)
    @amount = amount
    @currency = currency
  end

  def +(other)
    raise "Currency mismatch" unless currency == other.currency
    Money.new(amount + other.amount, currency)
  end
end

    Aquí la clase tiene sentido porque:

    • Tiene identidad
    • Encapsula invariantes
    • Protege reglas internas

    Lo que Dave Thomas critica es crear clases solo para colgar métodos.

    5. Un ejemplo muy Rails-real (Service Objects)

    El patrón clásico Rails:

    class CreateUser
  def initialize(params)
    @params = params
  end

  def call
    user = User.new(@params)
    user.save!
    Mailer.welcome(user)
    user
  end
end

    La versión “Ruby puro”:

    module Users
  def self.create(params)
    user = User.create!(params)
    Mailer.welcome(user)
    user
  end
end

    Pregunta incómoda:
    👉 ¿qué aporta realmente la clase CreateUser?

    Respuesta honesta: nada, salvo ceremonia.

    6. Beneficios reales (no filosóficos)

    Después de años, este estilo suele ganar porque:

    • El código crece horizontalmente, no en jerarquías
    • Refactorizar es más fácil
    • Las dependencias están a la vista
    • Los tests no requieren dobles complejos
    • El dominio se expresa como lenguaje, no como UML

    Esto es muy Ruby y muy Pragmatic Programmer.

    7. La idea profunda del vídeo (la que no sale en el código)

    La charla no va de clases.
    Va de esto:

    No diseñes por anticipación la forma final del sistema.
    Deja que la estructura emerja del uso real.

    Las clases son una decisión tardía, no el punto de partida.