Why OO?

1. Reuse/Flexibility

Features of OO programming languages offer features which promote extension and reuse of code.

2. Class-based Models closely mimic the real world

Classes model real-world abstractions.

3. OO technology provides ways of dealing with complexity

-- Hide implementation complexity behind well-defined interfaces
-- Systems can be decomposed in different ways


REUSE/FLEXIBILITY

Demand for software is exploding.
Traditional approach to this problem: build software systems more quickly. This usually reduces quality.

Given that same type of software is built again and again, avoid building new systems from scratch. Instead build software that can be extended to include new features and reused in different but similar contexts.

Ex: text box for a graphical user interface

|
cursor in text box

-- TextBox class that is used to produce all text boxes in application
-- Subclass CashTextBox can just override a single method of TextBox (i.e. the verifyInput method) and reuse everything else

class TextBox
{
    String getValue() {...}
    void setValue(String setStr) {...}
    boolean verifyInput(String testStr) {...}
    void setPos(int x, int y) {...}
}

class CashTextBox extends TextBox
{
    ...
    boolean verifyInput(String testStr) {...}
}

                       ^^^
                       returns true if testStr is in the format xxxx.xx

Goal of software reuse is not unique to OO programming. E.g. libraries of procedures, particularly numerical packages like LinPack.
In practice extensive reuse of procedures doesn't work very well.

Objects and classes bind data and operations together, so they promote reuse better. We can easily modify objects for different contexts (via inheritance, for example).

MIMICKING THE REAL WORLD

Classes model real world abstractions in an intuitive fashion. A class models state and behavior for its instances.

Ex: An order processing application
An Order class: defines the state of an order (order number, list of items)
                                            the actions that can be performed on an order (finalizing, canceling, changing)

In a non-OO system: connections between data, actions are not explicit. As the programmer, you must remember these connections and maintain them - the data and actions are not automatically tied together by the class construct. You write the code that ties them together.

class Order
{
    int orderNum;
    float[] items;
  ...
    void cancel();
    void finalize();
  ...
}

Non-OO System:
int myOrderNum;                                                 void cancel(int orderNum)
float[] myItems;                                                    {
                                                                                             ...
                                                                                  }

You must keep track of the connections between these.


DEALING WITH COMPLEXITY

A class provides a public interface while encapsulating the details and complexity of the underlying implementation. The class user must only understand the class interface.

Hierarchical Decomposition: Systems must be hierarchically decomposed into manageable units.

Consider good manufacturing processes - based on assembly of end product from subassemblies. Processes are specified in terms of operations on subassemblies. Break product into manageable parts.

Ex (from manufacturing)




Traditional software development doesn't follow this example. Focuses on operations, not parts. Hierarchical structuring done in terms of functions, not objects.

Large operations can be decomposed into smaller operations, but the meaning of the larger operations gets lost in the smaller operations.

OO design notation and languages allow different ways of decomposing systems. So developers can deal with complexity in different ways. A system can be broken into components, where each component has a well-defined interface (and a hidden implementation). To compose these components, you only need to understand the interfaces.

Classes can be organized in different types of hierarchies:
1. Specialization Hierarchy:
Classes are arranged according to the specialization (is-a-kind-of) relationship. A specialization inherits the properties of its generalization (superclass). A subclass is simplified because it only contains the properties that distinguish it from its superclass.

Ex: specialization hierarchy

2. Composition Hierarchy
In some situations, classes can better be arranged in a composition hierarchy (like the manufacturing example above). Classes are organized on whole-part relationships. The instances of one class are composed of instances of others. This is the has-a relationship.

Ex: A document consists of paragraphs, which in turn consists of words.