# 9 - Stratified design Part 2

## recap

- Pattern 1: Straightforward implementation


## Pattern 2: Abstraction barrier

### Abstraction barriers hide implementations

### Ignoring details is symmetrical

marketing team => don't care the details of the implementation
dev team => don't care how marketing team uses the functions

### Re-implementing the shopping cart as an object

...(略)

### The abstraction barrier lets us ignore details
What lets us change the data structure without
changing all of the code that uses shopping carts?

> "Abstraction" is just a fancy way of saying, “What details can I ignore?


**Notice how there are no arrows that cross the dotted line.**

## When to use (and when not to use!) abstraction barriers

### To facilitate changes of implementation

an abstraction barrier can be the layer of indirection that lets you change the implementation later

**However, this benefit is often a trap**
Abstraction barriers make change easy, but **that’s not why
we should use them**. They should be used strategically to **reduce
inter-team communication and help clarify messy code.**

### To make code easier to write and read
Abstraction barriers allow us to ignore details.

When writing code with lot of details,
Did we initialize the loop variables correctly?
Did we have an off-by-one error in the loop exit condition?
Did we ...

### To reduce coordination between teams

The abstraction barrier allows teams on either side to ignore the details the other team handles.

### To mentally focus on the problem at hand

An abstraction barrier makes some details unimportant to the problem
we are solving right now.

## Pattern 3: Minimal interface
There are many reasons to keep the abstraction barrier minimal:
1. If we add more code to the barrier, we have more to change when we change the
implementation.
2. Code in the barrier is lower level, so it’s more likely to contain bugs.
3. Low-level code is harder to understand.
4. More functions in an abstraction barrier mean more coordination between teams.
5. A larger interface to our abstraction barrier is harder to keep in your head.

## Pattern 4: Comfortable layers

## What does the graph show us about our code?

1. Maintainability—What code is easiest to change when
requirements change?
2. Testability—What is most important to test?
3. Reusability—What functions are easier to reuse?

## Code at the top of the graph is easier to change


## Testing code at the bottom is more important


answer

## Code at the bottom is more reusable

## Summary: What the graph shows us about our code