1 / 28

308-203A Introduction to Computing II Lecture 4: Visual Programming A Case Study of OOP

308-203A Introduction to Computing II Lecture 4: Visual Programming A Case Study of OOP. Fall Session 2000. What is Visual Programming?. Answer: Just the point-and-click we know-and-love. Window. Desktop. Start. A good example of OOP. Windows, dialogs and all the other little boxes

fathia
Download Presentation

308-203A Introduction to Computing II Lecture 4: Visual Programming A Case Study of OOP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 308-203AIntroduction to Computing IILecture 4: Visual ProgrammingA Case Study of OOP Fall Session 2000

  2. What is Visual Programming? Answer: Just the point-and-click we know-and-love Window Desktop Start

  3. A good example of OOP • Windows, dialogs and all the other little boxes • can be clearly visualized as individual objects • with their own private instance data • They share many behaviors, so code can • be reused if it is arranged to leverage inheritance

  4. A Simplified Case-Study We will implement one from scratch: • Text-based: just arrays of char • Simple visual hierarchy: just windows • on a desktop (no mouse-clicks)

  5. A Simplified Case-Study “Desktop” with two windows .............................. .............................. ..********.......... ..*Win 1 *.......... ..* ++++++++... ..***+Win 2 +... ........+ +... .…....++++++++... ..............................

  6. Helper Class “Coordinate” To draw text at certain x-y coordinates, it will be handy to package up those coordinates: class Coordinate { Coordinate(int x, int y) { … } int getX( ) {…} ; int getY( ) {…}; }

  7. The Class Hierarchy Vector (JDK) DrawingArea Coordinate DrawableVector ConcreteDrawingArea EmbeddedDrawingArea Screen Window TextWindow Desktop

  8. Abstraction of “Drawing” • Drawable - things which can be drawn (the “painting”) • DrawingArea - where things can be drawn (the “canvas” ) DrawingAreas will provide methods so that Drawable things can draw themselves.

  9. Abstraction of “Drawing” • Drawable - things which can be drawn (the “painting”) • DrawingArea - where things can be drawn (the “canvas” ) interface Drawable { void draw( ); }

  10. Abstraction of “Drawing” • Drawable - things which can be drawn (the “painting”) • DrawingArea - where things can be drawn (the “canvas” ) abstract class DrawingArea { void drawCharAt(Coordinate, char); char getCharAt(Coordinate); boolean checkValid(Coordinate) {…}; }

  11. Making it more Concrete class ConcreteDrawingArea extends DrawingArea { char [] [] myData; void drawCharAt(Coordinate, char) { … } char getCharAt(Coordinate) { … } }

  12. So what’s the difference? • ConcreteDrawingAreas have real text data • ConcreteDrawingAreas provide methods • to access that data which were prescribed • but not implemented in DrawingArea • Note: even a ConcreteDrawingArea is little • more than a stylized array of char

  13. Screen Problem: We still can’t actually print anything… Solution: Add a class with more functionality class Screen extends ConcreteDrawingArea { // This just calls System.out.println void dump( ) { … } }

  14. Desktop Problem: screens only remember character data and print it out… they don’t know about windows and things class Desktop extends Screen { addItem(Drawable); removeItem(Drawable); bringToFront(Drawable); }

  15. Desktop is “Drawable,” too class Desktop extends Screen { void draw( ) { // for each Drawable thing, d, on the Desktop d.draw( ); } }

  16. DrawableVector The above is neatly handled by extending the JDK class Vector so that it is Drawable… To draw yourself, just draw each element in order.

  17. The Class Hierarchy (so far) Vector (JDK) DrawingArea Coordinate DrawableVector ConcreteDrawingArea Screen Desktop

  18. Any questions?

  19. So what Drawables do we put on the Desktop? It’s time for windows, dialogs, and such: the stuff of point-and-click…

  20. Embedded Drawing Areas Problem: Windows and dialogs and such need to move around easily and transparently. Window (0,0) Window Desktop Start

  21. Embedded Drawing Areas Problem: Windows and dialogs and such need to move around easily and transparently. Window (0,0) has moved Window Desktop Start

  22. Embedded Drawing Areas Solution: Remember offset inside another drawing area. Embedding area Embedded area Window Desktop Start

  23. Embedded Drawing Areas class EmbeddedDrawingArea extends ConcreteDrawingArea { int x_offset, y_offset; DrawingArea embedding; void moveTo(x,y); }

  24. Window Problem: We can’t see where a window ends and the desktop begins. Solution: Add a border.

  25. Window class Window extends EmbeddedDrawingArea { char border; drawBorder( ) { // new method } drawCharAt( ) { // OVERRIDE } draw( ) { // OVERRIDE } }

  26. TextWindow class TextWindow extends Window { String text; void setText(String); draw( ) { // OVERRIDE } }

  27. The Class Hierarchy Vector (JDK) DrawingArea Coordinate DrawableVector ConcreteDrawingArea EmbeddedDrawingArea Screen Window TextWindow Desktop

  28. Any questions?

More Related