Slides about basic principles to code Object Oriented

basic_oo_principles.md

class: center, middle

@net_engine

@erikecoologic

Slides available at ???????

---

class: center, middle

Boundaries

---

Boundaries

1. single responsibility
2. tell don't ask
3. "law" of demeter

---

Why?

• Group logic
• Set boundaries

---

Wait Why?

• Reuse code
• Easily find the parts (one) you need to modify / reuse
• Abstract complex concepts

---

class: center, middle

Tell Don't Ask

---

Tell Don't Ask

Tell an object what to do, don't ask about its state

class Dude
  def have_coffee
    @barista.status = :making_coffee
    @barista.hand << 'filter handle'
    @barista.hand << @barista.grinder.coffee
    @barista.coffee_machine << @barista.hand # => BaristaPissedOffError:
    # [...]

    drink!
  end
end

---

Tell Don't Ask

The logic (knowledge) belongs to the Barista

class Dude
  def have_coffee
    coffee = barista.get_coffee(:cappuccino)
    drink!(coffee)
  end
end

---

Tell Don't Ask

• Keep the logic in one place
• Find it no time
• Change it one place
• Don't break other code
• Happily move on...

---

class: center, middle

Tell Don't Ask

?

---

class: center, middle

"Law" of Demeter

---

"Law" of Demeter

Don't talk to strangers

class Person
  def name     ;end
  def father   ;end
  def children ;end
  def games    ;end
end

class House
  has_one :garden
end

jeff_buckley.father.name.to_s.titleize.to_a # => ['Tim Buckley']
house.garden.tree.class.name                # => Sicomoro
person.map(&:children).map(&:games).flatten.each(&:destroy)

Count the dots?

"Law" of Demeter

What's familiar?

• Same class
• Language
• Framework

Why? It's reliable

"Law" of Demeter

Unconvinced?

class Booking
  has_one :room
end

class Room
  def price ;end
end

booking.room.price # preview
booking.room.price # confirmation page
booking.room.price # email
booking.room.price # admin

---

class: center, middle

"Law" of Demeter

?

---

class: center, middle

Single Responsibility

---

Single Responsibility

A class should have only one reason to change

# reason: persistence
class Entity < AR:B
  has_many :users
  # [...]
end

# reason: collect data about entities by day
class EntityMetadata
  scope :between # [...]
end

# extract data about entities
class EntityMiner
  # [...]

  def touchable_user_average
    create_missing_metadata
    EntityMetadata.between(period).average(:touchable_user)
  end
end

---

Single Responsibility

The names you give to your classes will affect the amount of responsibility.

  class UserCreator
    # [...]
  end

  class UserManager
    # [...]
  end

---

Single Responsibility

Mr. Miner can you please... create_missing_metadata?

• Re-usable
• Clear
• Modular
• Avoid interdependencies
• Keep the logic in one place (eg: file storage)

---

Single Responsibility

• Goes along with REST/hypermedia
• What about rails concerns?

---

class: center, middle

Single Responsibility

?

---

class: center, middle

Conclusions

---

Why?

• Group logic
• Set boundaries
• Reuse code
• Easily find the parts (one) you need to modify / reuse
• Abstract complex concepts
• Best man (class) for the job

---

Consequences

Lots of classes and methods

• Namespaces
• Extract services
• Extract gems
• Extract engines
• Kiss
• Profit!

---

Agile

• Not just standups
• Write code happy to accept change
• Readable code (XP)
• It's not a quick s**t in the hood
• Technical debt must be manageable
• Red-green-refactor

---

Next

• Design Patterns
• Hexagonal feat Rails on a budget
• Naming things
• Test foobar

---

class: center, middle

@net_engine

@erikecoologic

Slides available at ???????

Slideshow created using remark (thanks)