Introduction to Computer Science and Object-Oriented Programming Week 11

Tonight Lab 5 Chapter 8 Week 11

Bubble Sort Simple sort Think of regions … … next place to bubble [0] … … sorted unsorted “Bubble through the unsorted region, to place then next value to it’s correct position Week 11

Bubble Sort Compare the first two elements of the array. If the first element is larger than the second Then swap them Otherwise, leave them alone. Repeat this step for the second and third element then the third and fourth and so on. At the end of the first pass the last number in the array is the largest. Repeat for as many times as elements in the array Week 11

Bubble Sort Pass Week 12

Bubble Sort 11 9 17 5 12 11 9 17 5 12 9 11 5 12 17 Initial state Begin first pass 1st pass compare pattern: 9 11 5 12 17 Begin second pass 2nd pass compare pattern: Week 11

Bubble Sort 9 5 11 12 17 5 9 11 12 17 5 9 11 12 17 Begin third pass 3rd pass compare pattern: 5 9 11 12 17 Begin forth pass 4th pass compare pattern: 5 9 11 12 17 Final state Week 11

Code for Bubble Sort Week 12

An Optimization Propagates up in one direction but down in the other So… It may get sorted before final pass! Week 12

With the Optimization Week 12

Object Oriented Design Two common approaches for problem solving: Procedural Approach Identify tasks break down to lowest level Object Oriented Approach Identify objects Identify data (instance fields) Identify procedures (methods)

OOD Begins with identifying classes (objects) Class names should be nouns not DetermineGrade, OrderAutomobile easy with most objects: Grade, Automobile, Coin, Customer some classes not as easy: Scanner, MazeResultDriver Classes should represent a single concept from the problem domain

Example: Student as a class Cohesion Cohesion The public interface of class relates just to the class concept. High cohesion is good when designing a class (represents a single concept) Example: Student as a class But poor cohesion if it ontains methods to list times when courses are offered

Coupling Level to which classes are dependent on each other A class X is dependent on another class Y if a change to Y could require a change in X Low coupling is good when designing a class

Categories of Classes Classes fall into 4 categories: Domain Classes Nouns, related to problem set (e.g., Employee, CompactDisc, Time, Skier) Represent single concept, non-programmer recognizes Actor Classes Verbs, related to problem set (e.g., TaxCalculator, ReportPrinter, MazeResultDriver) Usually a process or action, often end in -er or -or

Categories of Classes Classes fall into 4 categories: Utility Classes Provides reusable services across many problem sets (e.g., Math) Typically, only static methods and constants, no instantiation Library Classes Provides reusable components across many problem sets (e.g., String, ArrayList) Instantiation required, are true objects

Accessor / Mutator methods Two types of methods for class: Accessor does not change the object (instance fields) Mutator changes the object’s instance fields

Immutable Classes Immutable class has no mutator methods (no methods can alter the value of the data in the object) Example is String class String newName = name.toLowerCase( ); String str2 = str1.substring(start, end); Another example is Wrapper classes (Double, Integer) Call to intValue( ) method of Double class does not change the value of the Double variable