1 / 14

CSC 212 – Data Structures

CSC 212 – Data Structures. Lecture 8: Object-Oriented Design. Your Goal When Writing Classes. Good programs work Everything else is secondary Best way for code to work is reusing code Old code has already been debugged Redesigning the wheel wastes time. Good programs work.

ellery
Télécharger la présentation

CSC 212 – Data Structures

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. CSC 212 –Data Structures Lecture 8: Object-Oriented Design

  2. Your Goal When Writing Classes • Good programs work • Everything else is secondary • Best way for code to work is reusing code • Old code has already been debugged • Redesigning the wheel wastes time • Good programs work

  3. Great Designs in History • Hide complexity but keep functionality • Provide enough details to use class only • Cars only leave critical controls visible

  4. Encapsulation • Keep class details private • Never expose fields • Makes changing their definitions simple • Do not specify how methods work • Specify what they do, instead • Leaves you free to rewrite methods • Limiting public info simplifies using class • Keeps design general & improves reuse

  5. Great Designs in History • Design should not specify use • Should adapt to any environment • Legos place few limits on how used

  6. Abstraction • Describe design in simple, easy language • Each noun should be a class • Each action should be its own public method • Use absolutely minimum number of fields • No fields for values that can be computed • Make type of each field as open as possible • Do not let how enter your design until last step

  7. Great Designs in History • Design should be easy to modify • Enable easy modification as needs change • Quick & easy modifications of components

  8. Modularity • Classes represent single concept/actor • Use classes/fields to provide extra details • Each method should do only 1 thing • Break complex actions into small, private methods • Limit reliance on any implementation details • Always separate input & output from methods that actually do anything • I/O details change frequently

  9. Choosing Classes • Examine from functional point of view • Questions to ask: • What are the actors? (What interacts in system?) • What does each actor do? • Where do actors interact? Whose goals or needs are being met?

  10. Unified Modeling Language • Illustrate system's classes & relationships • Provides class diagram • Class name • Attributes (Fields) • Operations (Methods)

  11. Unified Modeling Language • Illustrate system's classes & relationships • Provides class diagram • Class name • Attributes (Fields) • Operations (Methods) • Basis of tracing format • Become more useful asclass continues

  12. Unified Modeling Language • Can show relationships between actors • Useful for dividing into fine grained classes

  13. Your Turn • Groups will be changing (starting today) • Do not like things getting too static and boring • New groups courtesy of random.org Group 1Group 2Group 3 Jaydon Okan Jim Ryan Alison Debbie Kim Abe Ben Derrick Katey Tim Jake

  14. Before Next Lecture… • Finish lab #2 • Finish week #3 assignment • Start programming assignment #1 • It is due 2 weeks from today • Mondays’s lecture discusses inheritance • Read Section 2.2 of the book

More Related