Design

1. Design A departure from syntax

2. First Step: The Idea • Kind of a no-brainer but critically important • Anything is possible, but some ideas are more attainable than others • Consider your timeframe/experience/# of programmers • Get excited! You can change the world

3. Some Good Ideas of the Past:

4. Our Idea • TETRIS! • Unfortunately not an original idea • But great example to demonstrate the design/writing process • Brilliant Idea, relatively simple program

5. This is Tetris:

6. Second Step: The Requirements • Describe exactly how your program will behave • Don’t be vague!! • Someone should be able to understand your program from your requirement write-up • Similar to “project specification” or “specs” in the industry

7. Tetris Specifications • We’re going to cheat because the desired program is spelled out for us, but here’s the idea: When the game starts, only an empty board with borders drawn around its edges should be displayed. A Tetris piece, chosen randomly from the seven possible Tetris pieces shown below, should appear at the top of the board. This piece should fall by moving down the board, one row at a time. A piece cannot fall into a square already occupied by a previously fallen piece. When a piece can fall no further, it should stop moving. A new random piece should then appear at the top of the board and begin to fall. As pieces fall, rows (or horizontal lines) of occupied squares spanning the board's width may form. When such a line is formed, it disappears and all the squares above it fall down one line to fill the newly empty row. This process continues until there is either a piece in the top row of the board or a new piece appears and has no room to fall because it is already resting on a previously fallen piece. The game is then over, and everything on the board should stop completely. A message should be displayed to let the user know that the game is over. While a piece is falling, the player may rotate or shift it by pressing certain keys on the keyboard. Pressing the left arrow should shift the piece one square to the left. Pressing the right arrow should shift the piece one square to the right. Pressing the up arrow should rotate the piece counter-clockwise by ninety degrees. At regular intervals, the piece should fall one row at a time. The player should be able to make the piece fall more quickly by pressing the down arrow. The player should be able to drop the piece by pressing the space bar. By dropping a piece, the player forfeits his/her chance to manipulate the piece any further and the piece simply falls as far as it can. The player should be able to pause the game at any time by pressing ‘p’. Pressing ‘p’ again should allow the user to resume play. When the game is paused or over, some sort of notification should be displayed to the user (most likely using a JLabel or your GFX), and the user should not be allowed to manipulate pieces.

8. Third Step: The Design • There are many aspects and levels of design • Your type of design depends on what your program will do • Don’t skimp here, an hour of design can save many hours of coding/debugging

9. User Interface Design • The User Interface (UI) is how the user interacts with your program • This includes what the user sees when your program is running • Typically users use the keyboard and mouse (now touch and speak) • Visual feedback is crucial • Use of color is important (except for craigslist)

10. UI Visualization Display change/action performed Keystrokes and Mouseclicks

11. A bad UI

12. UI Tips • Keep it simple and elegant, less is more • Mockup with paper/pencil or photoshop if you’re feeling fancy • Make the purpose of UI elements (buttons, sliders, etc) transparent • Use consistent colors and fonts that work well together • Provide the user with quick feedback (button clicks/loading bars)

13. A better UI

14. Our Tetris UI • Arrow Keys will rotate/move the pieces • Space bar will drop the pieces • Our GUI might look something like this:

15. Class Design • Figure out what classes we will need to write (can include instance variables and methods) • This is what makes Object Oriented Programming awesome • Just write a java Class for every object/concept in your program • This way your code will be intuitive and reusable

16. Tetris Classes • One potential design could use the following classes: Board – represents the state of the tetris board TetrisSquare – represents one square IPiece – the line piece, made of 4 TetrisSquare Opiece– the square piece, made of 4 TetrisSquare … Timer – Keeps track of the time telling the pieces when to fall MainPanel – Displays Everything and any auxiliary buttons App – Has a main method which creates a MainPanel

17. Pseudocode • A Step in between design and coding • Really useful for more complicated algorithms • Can be as detailed or general as you want • Can be as close to English or Java as you want

18. Pseudocode Example • Rotation is actually kind of hard • Let’s write some pseudocode for rotating an IPiece method rotate() if the piece is horizontal move leftmost square up 2 right 2 move left middle square up 1 right 1 move rightmost square down 1 right 1 else move top square left 2 down 2 move top middle square left 1 down 1 move bottom square up 1 right 1

19. Fourth Step: Code it up • After you’ve done all your design work, it’s time to open up Eclipse • Code slowly and meticulously, it will save you hours in the end • Code modularly

20. Modular Coding • Code/test small pieces of your program as you go • Don’t write a massive program non-stop and test at the end!! • In our Tetris example: First get your board to show up Then get a piece to show up Then make a piece fall …

21. There’s no Bullshit in coding! • You may be able to write a decent history paper without knowing many of the relevant historical facts • You may be able to get partial credit on a math problem for showing your work • But the computer can only do what you tell it to do • Your program will either work or it won’t (and it’s not the computer’s fault)

22. Fifth Step: Testing and Debugging • Thorough testing is crucial, every possible scenario must be tested! • Don’t prematurely declare victory • Commercial software goes through months of rigorous testing before release • What are the repercussions of faulty code?

23. Debugging, a beautifully frustrating challenge • Any program worth writing will have bugs initially • Be positive, fixing a bug is awesomely satisfying • Use hand simulation to see exactly what your program is doing • Use print lines to see the values of your variables • Party down when you fix all your bugs

24. Additional notes • Java’s GUI library is called “Swing” • For the specifics of Swing check out these lectures: http://cs.brown.edu/courses/cs015/lecture_recordings/2013_lecture9/2013_lecture9.html http://cs.brown.edu/courses/cs015/lecture_recordings/2013_Lecture10_GUIs_and_Event_Handling/2013_Lecture10_GUIs_and_Event_Handling.html • Think of some program ideas you want to build!