The Secret to Solving Big Problems or How

The Secret to Solving Big Problems or “How do you eat an elephant? ”

One Byte at a Time • Problem solving approaches – Divide and conquer – Incremental development

An Approach to Word Problems • Given a specification for a problem 1 Understand the problem 1 2 3 4 5 Do you know what the big picture problem result should be? Think about each of the smaller problems that comprise the bigger problem. Do you know how each of these should work? What is provided as part of the problem? (Nim, Nim. Driver) Of the smaller problems, inventory which of these you have solved before. Look for patterns in how you have solved the problem in the past. Which of the solutions do you have readily available in code? 1 Toolkit 2 Prior labs or PAs that you have solved.

An Approach to Solving Word Problems • Determine an overall structure of the program – Which of these “mini”-solutions will be methods and which will be in the main flow? (Think about methods being small blocks that you can put together in any order in the main flow. ) – Create the base classes and “stubs” for each method so that you can test incrementally. • Determine the order of solving each of the smaller problems – Will you go top down? • Overall flow vs component parts – Will you go bottom up? • Build components first, then link them together • Implement the first “solution” AND TEST

The Game of Nim • By now you should understand how the game works. • So, given the specification, what are the smaller component problems to be solved? (5 minutes in groups). – REPORT • Which of these component problems were solved for you by the author? (1 minute) - REPORT • Which of these component problems do you already have a solution for? (2 minute) – REPORT

Game of Nim continued • What should the overall structure look like? Where will you construct each of the mini solutions? • Think about 3 of the mini problems. How will you know if you have solved the problem? Develop a test strategy so you know if that mini problem has been solved. (5 minutes) REPORT

What about RATS! • How does the overall game work? • What are the smaller problems that you need to solve? (5 minutes) – REPORT • Which problems have you already solved in labs, PAs or Toolkit? • Where (in which class) will each of these minisolutions reside? (2 minutes) – REPORT • Of the problems that you must solve, how will you know that you have created the correct solution? Choose 3 of the problems and design a test for each of these. (5 minutes) - REPORT

As you finish PA 6 • Make sure your components are working correctly and make sense. • If you have more than 50 lines of code(roughly) in a method, split it up. Design a smaller solution or a series of smaller solutions. (As you get better, you will split methods which are much smaller). • Test each component as you go along. This can be done whether you are developing bottom up or top down.

Always, SMALLER IS BETTER • I have helped a lot of students with MASS O’ CODE § If you write smaller components that you know work, there is less need to debug large chunks.