Interfaceoff

1_interfaceoff.md

###The design of an interface should always speak the language of the consumer, ###for if not for the consumer, the interface serves no purpose.

2.md

##Example: designing a presenter collaborator for a view

####Meh Example:

# some view somewhere
%button{ class: 'delete-repo' }
  = "Delete #{presenter.repo_name}"

class RepoButtonPresenter
  def initialize(repo)
    @repo = repo
  end
  
  def repo_name
    repo.name
  end
  
  private
  
  attr_reader :repo
end

Why isn't this so good? The consumer knows the details of the implementation. There's no abstraction, therefore change is difficult.

3.md

##Example: designing a presenter collaborator for a view

####Better Example:

# some view somewhere
%button{ class: 'delete-repo' }
  = presenter.delete_button_label

class RepoButtonPresenter
  def initialize(repo)
    @repo = repo
  end
  
  def delete_button_label
    "Delete #{presenter.repo_name}"
  end
  
  private
  
  attr_reader :repo
end

Why is this better? We've created a flexible abstraction and the interface speaks the language of the consumer. We can now change the details of the implementation without having to change the consumer at all.

Imagine a change request that wants the button's label capitalized. What needs to change in the 1st example? What about the 2nd?

4.md

Let's imagine a more drastic change. Let's say we want the button label to just say "DELETE"

# some view somewhere
%button{ class: 'delete-repo' }
  = presenter.delete_button_label

class ButtonPresenter
  def delete_button_label
    "Delete"
  end
end

Oh snap! Are we following the depend in the direction of stability rule? Heck yes we are!

Wait a minute, did we prove that abstractness increases with stability? I think we did!

SOLID according to Uncle Bob Stable Dependencies / Stable Abstractions Principle

5.md

##Outside-in development

####For new code:

• it greatly improves interface design
• it complements TDD - one could argue that strict TDD is outside-in development

####For existing code:

• it guarantees that you'll come across the appropriate abstraction
• it greatly helps identify missing abstractions

Outside in development

6.md

##Interfaces are everywhere!

Which is better?

$ docker-compose exec fetcher bundle exec rspec

$ make test_fetcher

The docker-compose example is not only riddled with details, but is technology specific. Ack!

The make example hides the implementation details. Are we using Docker or Rkt? At this level of abstraction, I don't care!

Solid, stable interfaces will be especially important for CE. We need others to understand our abstractions and feel safe working within a given context.

7.md

Being abstract is something profoundly different from being vague
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

• Dijkstra