Session 4 Top-down design, Breaking down a problem, Modeling OOP


By the end of this session, you will be able to:
  • define top-down design and object oriented programming
  • break down real-world tasks using top-down design strategies
  • model real-world objects and apps by breaking down their attributes and behaviors



  • Notebook
  • Writing instrument
  • Laptop
  • Headphones & mic

Housekeeping and Goals


  • Fairly high scores on hooking up a remote to your local repository! This is great! Keep pracitcing! And, definitely go over the task 1 from the hw again if it’s still fuzzy.
  • Similar scores for navigating Github as well as forking and cloning


  • Don’t “Initial Commit” on an already-existing project (like the mod0resources repository); remember to start with a present-tense verb with a capital letter (like Add, Change, Remove, Fix, Make, etc.)
  • Remember to be aware of where you are in your directory structure of the terminal before you clone anything down or start running git commands. Make sure you’ve navigated to where you want to be

Other Notes

  • Good commit message format:
Add list of mod 0 resources
Remove reference to old blog post
Change data type of age field
Fix spelling mistake
  • Not good commit message format:
Rachel is adding her list of mod 0 resources
old blog post
changed data type for age field
Oops, I need to fix my spelling mistake

Intros, Review, and Icebreaker

Intros, Review, and Icebreaker

Person with the shortest first name goes first.

1. Introduce yourself: name, pronouns

2. What music are you listening to currently, and is there any music that you've found to be helpful when you're studying/programming?

3. Accountability review: what tangible progress have you made toward the focus skills you identified at the beginning of Mod 0?

Have extra time? Share what extra things you're doing to get ready to start school at Turing.

Top Down Design

“Programing is hard because it requires us to solve ill-defined problems with unknown solutions. Our job is to invent the solutions. Coding is inherently creative.” - Danny Smith on Breaking Down Problems

Top Down Design (or step-wise design) is an approach to breaking down a problem or system. In this approach, the designer lays out the problem or system’s high-level overview, then breaking down the overview into sub-systems (or sub-steps), then repeating that process until the system has been broken down into the smallest pieces.

This is not top-down design:

draw an owl meme


This is the start of a top-down approach:

draw an owl top down design

Why is this important? A problem that is not broken down into its smallest components remains too complex and abstract to code. In addition, small components allow for reusable and replaceable units of code.

As humans, we memorize and practice the steps that it takes in order to do even the most basic tasks. If you tell a human to tie their shoe, you (generally) don’t need to specify any further instructions. However, if you were to build a shoe-tying machine, you would need to break down the process into the most basic steps.

Try It Together: Making Pizza

Follow along with your paper and pencil as we walk through breaking down the process of making pizza.

Lets do this interactively where the class navigates and I drive

Now, in groups!

Try It (Break Out Rooms): Top Down Design (~10 minutes)

The person whose first name starts closest to the letter F will pick a scenario below:

  • Reheating a meal
  • Mailing a package
  • Walking a dog
  • Putting children to bed
  • Applying for a job
  • Writing an essay
  • Starting a campfire
  • [Choose your own adventure]

As a group, use a Top-Down Design approach to break down the scenario. Everyone should have their own diagram.

Don't worry about conditional logic. Only focus on breaking down the problems as much as you can

Done? Review, revise, and choose another scenario.

Be ready to share and explain.

Top Down Design in Programming

encrypt and decrypt top down design

Credit: Liam McQuay (IGCSE Computer Science Youtube Tutorial)

Breaking down problems using top down design lends itself nicely to the object-oriented design principles of abstraction (where an object performs a task without other objects being concerned about how it is done) and encapsulation (where an object handles its own internal states and behind-the-scenes work).

Notating Top-Down Design in a .txt file

On your Mod 0 Assessment, you will be asked to break down a scenario using Top Down Design. We’ll demonstrate the pizza scenario in a text (.txt) file.

1 Make dough
  1.1 Add ingredients to bowl
    1.1.1 Add water get measuring cup go to sink fill up the measuring cup with 3 cups of water pour contents from measuring cup into bowl
    1.1.2 Add honey
    1.1.3 Add yeast
    1.1.4 Add flour
  1.2 Mix Ingredients until combined
  1.3 Knead dough
  1.4 Let rest
    1.4.1 set the timer for 30 minutes
    1.4.2 wait
2 Make sauce
3 Make crust
4 Add sauce and toppings

Try It (Break Out Rooms): Top Down Design (~15 minutes)

IF at any point you run into problems with git - keep moving forward on the top down design part of this exercise. Come back to this and work through any issues with git/github after class. You will also get practice in your homework

These steps do not need to be done in perfect order. Practice the workflow and the order of steps that you're comfortable with.

Create a new directory called top_down_design_practice

Open a new file (.txt format) in this directory and use decimal notation to write out your top down design appoach with the scenario you chose from your group.

Make sure to follow the same format that was demonstrated and shown above

After you've made some entries, initialize your repository with git

Add your file and make an initial commit

Run git push at this point and see what the output is

Create a repository on github that you can connect to your local repository

Add more steps

Add and commit your progress

Push to github

Check one anothers files to make sure that the format is correctly notated and indented (although .txt code is unbreakable, it's important to have an eye for detail as most languages will break if syntax is incorrect. And indentation helps make our code more readable)


Turn off your mics and videos and walk away from the computer. Stand up, stretch, drink water. Do a few sit-ups, squats, push-ups, jumping jacks, arm circles, stress ball squeezes, or whatever else moves your body.

Object Oriented Programming

Object oriented programming, or OOP for short, is an approach to programming (or a programmming paradigm) where programs are organized as a series of objects.

OOP is very similar to how the world actually works. Objects are created from templates that we call classes.

A class defines attributes (or properties) and methods (or actions). An object is a very specific instance of a class. For example, if the class were Car, two objects might be 2007 Blue Nissan Versa and 2014 Silver Nissan Juke.

Attributes contain data about a specific object. The information format should be one of the basic data types from Session 2 (string, integer, float, boolean, array, hash).

The names of attributes are generally nouns.

Two good questions to ask when you’re determining what should be classified as an attribute are:

  • “Is this piece of data something that could potentially stay the same over the course of an object’s lifetime?” (you want the answer to be yes)
  • “Is there any other data that underlies this piece of data?” (you want the answer to be no)

CAUTION: Sometimes, methods will feel like they should be attributes. For example: age, years_employed, percent_full.

Try It Together: Bottle Class Attributes

Follow along as we walk through defining a bottle class with three different bottle objects.

NOTE: For consistency in this lesson, we're going to stick to the naming convention of camelCase. This will look very Javascript-esque. However, in Ruby land, you'll see snake_case.
Class: Bottle

color (string)
lidType (string)
totalCapacity (integer)
stickers (array)
currentCapacity (integer)
recyclable (boolean)
insulated (boolean)

Methods define behavior of an object, actions that can be performed on that object, or calculations that generally use . Methods are generally verbs (action words or short action phrases).

Methods generally answer the question “What can this thing do?” or “What can be done to this thing?”

A return value is the result of a method that performs a calculation. For instance, a calculatePercentFull method could divide the value of a currentCapacity attribute from the value of totalCapacity attribute. The result of that calculation would be the return value for calculatePercentFull method.

Key Points

  • A method performs some kind of work and will almost always use or modify an attribute
  • Anything that does work (calculations) should be a method, not an attribute
    • the result of that work is called the return value
  • Attributes are generally nouns (99.9% of time)
  • Methods are generally verbs (90% of time – can also be questions OR nouns that are the result of calculations)
    • ie. age, years_employed, percent_full since they all require calculation
  • One quick side note: accessor methods are outside the scope of today’s lesson.

Try It Together: Bottle Class Methods

Follow along as we walk through defining some methods for our Bottle class.

What kind of methods can we add? What would their return value be?

Class: Bottle

color (string)
lidType (string)
totalCapacity (integer)
stickers (array)
currentCapacity (integer)
recyclable (boolean)

calculatePercentFull (divides currentCapacity by totalCapacity)
refill (subtracts currentCapacity from totalCapacity and then refills that amount)
addSticker (append a sticker item into the stickers array)
changeColor (changes the color attribute)

Try It Together: Defining Bottle Class Instances

Follow along as we walk through defining a couple instances

Make sure that your syntax is correct for each data type: if it's a string, the value below should be wrapped in quotes. If it's an array, each item in the collection should be valid data as well, etc.

Object: Nalgene

color: "Pink"
lidType: "Twist top"

calculatePercentFull: 800 / 1000 = .8
changeColor: color = "Blue"

Can You Spot the Problem?

What would be wrong with…

  • a class called Turing
  • an attribute called current_time
  • having attributes for a Review class called one_star, two_stars, three_stars, etc.
  • a Senator class having an array attribute called senator_names
  • a class called California
  • having attributes on a ShoppingCart class called item_one, item_two, item_three, etc.
  • a method on GroceryStore called clean_aisle_seven
  • a Bottle class having an attribute called water
  • a Chair class having an attribute called number_of_chairs
  • a MenuItem class with a method called CustomerSurvey

Try It (Big Breakout Rooms) (~15 minutes)

Person whose first name starts closest to Q will share their screen and choose one of the following classes:

  • Vehicle
  • Book
  • Playlist
  • GroceryStore

Everyone should create a .txt file to work off of following the conventions we used above for defining classes and instances

As a team, brainstorm at least five attributes (and data types) and five methods (and descriptions) for your chosen class. Each person should be keeping their own copy up to date to use as a reference.

Person whose first name starts closest to the letter A will suggest an object that is an instance of the class. This is Object #1.

Brainstorm the values for each attribute of that object.

Brainstorm the results of each method called on that object.

Person whose first name starts closest to the letter E will suggest a second object that is an instance of the class. This is Object #2.

Repeat the brainstorm process for attributes and methods for object #2.

Homework and GitHub Projects

Find the homework in your Mod 0 Project Board. Contact David or Tim if you’re stuck.