Csc 212 data structures
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

CSC 212 – Data Structures PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Csc 212 data structures

CSC 212 –Data Structures

Lecture 8:

Object-Oriented Design


Your goal when writing classes

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


Great designs in history

Great Designs in History

  • Hide complexity but keep functionality

    • Provide enough details to use class only

  • Cars only leave critical controls visible


Encapsulation

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


Great designs in history1

Great Designs in History

  • Design should not specify use

    • Should adapt to any environment

  • Legos place few limits on how used


Abstraction

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


Great designs in history2

Great Designs in History

  • Design should be easy to modify

    • Enable easy modification as needs change

  • Quick & easy modifications of components


Modularity

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


Choosing classes

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?


Unified modeling language

Unified Modeling Language

  • Illustrate system's classes & relationships

  • Provides class diagram

    • Class name

    • Attributes (Fields)

    • Operations (Methods)


Unified modeling language1

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


Unified modeling language2

Unified Modeling Language

  • Can show relationships between actors

    • Useful for dividing into fine grained classes


Your turn

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


Before next lecture

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


  • Login