Part I: Why Use OO Technologies?

Building a Graphical Tool

Procedural Solution

int height;
int width;
int radius;
int shapeType;

void draw(int shapeType) {
  switch(shapeType) {
  case CIRCLE:
    /* code here to get the radius 
       and draw a circle */
    break;
    
  case TRIANGLE:
    /* code here to use a base/height 
       to draw a triangle */
    break;

    ... (ad nauseum)

  default:
    /* Error!! Can't draw an unknown shape! */
  }
}

void print(int shapeType) {
  switch(shapeType) {
  case CIRCLE:
    /* code here to print a circle */
    break;
    
  case TRIANGLE:
    /* code here to print a triangle */
    break;

    ... (ad nauseum)

  default:
    /* Error!! Can't print an unknown shape! */
  }
}

Our Main Program

public static void main(String[] args) {
  radius = 3;
  draw(CIRCLE);
  base = 4;
  height = 6;
  draw(TRIANGLE);
  ...
  print(SQUARE);
}

Non-OO Development/Testing Efforts

1. You must add a new shapeType: Hexagon = 6
2. You must go to all of your subroutines: draw(), print(), etc. and add a new case statement for that new shape. Can you see some problems?
• It's as if someone took a shotgun to your code. In order to add a new shape, you must touch every function that you wrote!
• Question: What happens if you add hexagon to 19 of your 20 subroutines? Well, it turns out, the compiler won't be able to detect this, and now you're counting on the developer's diligence during unit testing, or your quality assurance group during system testing to catch these errors.
3. You must change your main program to use this new shape, and manipulate the appropriate variables

1. You must test all of the new code that was added (and test Every Single Method)
2. The switch statement is an error-prone construct, such that you must also test all of the old code to make sure you didn't break anything!
3. You must test your main program

• How complex is all of this to maintain over time?
• Can you imagine that code is shipped to production which is not production-ready?

Object-Oriented Solution

public abstract class Shape {
  protected abstract void draw();
  protected abstract void print();
  protected abstract boolean move();
  protected abstract boolean resize();
  ...
}

public class Circle extends Shape {
  public void draw() {
    // draw a Circle
  }
  public void print() {
    // print a Circle
  }
  ...
}

public class Triangle extends Shape {
  public void draw() {
    // draw a Triangle
  }
  public void print() {
    // print a Triangle
  }
  ...
}

The Main Program

public static void main(String[] args) {
  Shape[] shapes = new Shape[10];
  shapes[0] = new Square();
  shapes[1] = new Triangle();
  shapes[2] = new Circle();
  ...
  for (int i = 0; i < shapes.length; i++)
    shapes[i].draw();
}

Shape shape = new Circle();

Maintaining an OO Design

1. Add a new Shape subclass called Hexagon, and implement the methods for that class
• Question: Now what happens if you implement 19 out of 20 methods, but forget one? Again, since the Shape class is abstract, concrete subclasses of Shape must implement all of the abstract methods, otherwise the code won't compile. This means the developer now catches and fixes these mistakes (and not the client, during production).
2. Add a line in our main program to instantiate this new type (but nothing else has to change, since we have polymorphism and dynamic binding which means the generic draw() method will now call the correct draw() method for our new Hexagon subclass!)

1. Test our new Hexagon class

• We don't need to re-test the other classes, other than making sure we instantiated our new shape correctly in main.
• We never touched the Shape class or other subclasses.

Entry Barrier to OO

Taking a Step Back

1. Does all of this make sense?
2. Does this help to alleviate some of the fear, frustration, maybe even the anger you felt when you first encountered these strange new concepts?
3. Most important of all: does this free you, so that you can focus on what is truly important? If you've become truly OO aware, now put your nose to the grindstone learning the syntax and cornerstone OO concepts. Because if you are OO aware and you work hard, there is a good chance you will wake up one day and realize: hey, I've made it.