Object Orientation

From HaFrWiki
Jump to: navigation, search
Example Coffee

Object Orientation (OO) can model a complex reality in a very natural way. There are many examples of OO, complex ones and very simple ones. I prefer the KISS principle. Take for instance 'the cup of coffee' example, showing interaction between client, waiter and kitchen.

  • Encapsulation: Customer and kitchen don't know each other. The waiter is the intermediary.
  • Polymorphism: Waiter and kitchen act differently to the request 'a black coffee'.
  • Inheritance: Both waiter and kitchen supply coffee.

The benefits of OO are higher for complex business processes. The more complex the better. Different responsibilities, lots of exceptions, and processes that 'look alike'. Those are the ideal ingredients for an OO approach. |}



Encapsulation means as much as shielding. Each OO object has a shield around it. Objects can't 'see' each other. They can exchange things though, as if they are interconnected through a hatch.
Customer, waiter and kitchen are three shielded objects in the 'cup of coffee' example. Customer and kitchen do not know each other. The waiter is the intermediary between those two. Objects can't see each other in an Object Oriented world. The 'hatch' enables them to communicate and exchange coffee and money.
Encapsulation keeps computer systems flexible. The business process can change easily. The customer does not care about the coffee brew process. Even the waiter does not care. This allows the kitchen to be reconstructed, is only the 'hatch' remains the same. It is even possible to change the entire business process. Suppose the waiter will brew coffee himself. The customer won't notice any difference.
Encapsulation enables OO experts to build flexible systems. Systems that can extend as your business extends. Every module of the system can change independantly, no impact to the other modules.



Objects can respond differently to the same message. Both waiter as kitchen respond to 'a black coffee'. The actions are different though.

  • The waiter passes the message to the kitchen, waits for response, delivers coffee and settles the account.
  • The kitchen brews fresh coffee and passes it to the waiter.

The same message with different implementations, that is polymorphism.

Polymorphism makes Object Oriented systems extremely suitable for various exceptions and exceptions to exceptions.




Similar, but just a little bit different. Class tree, the coat-rack for inheritance The world is full of exceptions and similarities. Object Orientation places everything perfectly in a class tree.

  • Both waiter and cook are employee. So they both have an employee number. This generic employee number gets a generic place in Employee.
  • Both return a cup of coffee to the question "A cup of Coffee please". That similar behavior also gets a generic place in Employee.
  • There are some exceptions. Waiter and Cook have different methods to get a cup of coffee. Those specific methods get a specific place, reusing the more generic part in Employee.

No matter how complex your business situation is, Object Orientation can cope with it.

Subaru Inheritance


In OO, the concept of IS-A is based on class inheritance or interface implementation. IS-A is a way of saying, "this thing is a type of that thing." For example, a Mustang is a type of horse, so in OO terms we can say, "Mustang IS-A Horse."
Subaru IS-A Car. Broccoli IS-A Vegetable (not a very fun one, but it still counts). You express the IS-A relationship in Java through the keywords extends (for class inheritance) and implements (for interface implementation).

public class Car {
  // Cool Car code goes here
public class Subaru extends Car {
  // Important Subaru-specific stuff goes here
  // Don't forget Subaru inherits accessible Car members which
  // can include both methods and variables.

A Car is a type of Vehicle, so the inheritance tree might start from the Vehicle class as follows:

public class Vehicle { ... }
public class Car extends Vehicle { ... }
public class Subaru extends Car { ... }

"Car extends Vehicle" means "Car IS-A Vehicle." "Subaru extends Car" means "Subaru IS-A Car."

Inheritance HAS A


HAS-A relationships are based on usage, rather than inheritance. In other words, class A HAS-A B if code in class A has a reference to an instance of class B. For example, you can say the following, A Horse IS-A Animal. A Horse HAS-A Halter. The code might look like this:

public class Animal { }
public class Horse extends Animal {
     private Halter myHalter;

In the preceding code, the Horse class has an instance variable of type Halter, so you can say that "Horse HAS-A Halter." In other words, Horse has a reference to a Halter. Horse code can use that Halter reference to invoke methods on the Halter, and get Halter behavior without having Halter-related code (methods) in the Horse class itself.

HAS-A relationships allow you to design classes that follow good OO practices by not having monolithic classes that do a gazillion different things. Classes (and their resulting objects) should be specialists. As our friend Andrew says, "specialized classes can actually help reduce bugs." The more specialized the class, the more likely it is that you can reuse the class in other applications. If you put all the Halter-related code directly into the Horse class, you'll end up duplicating code in the Cow class, UnpaidIntern class, and any other class that might need Halter behavior. By keeping the Halter code in a separate, specialized Halter class, you have the chance to reuse the Halter class in multiple applications.


Abstraction — the ability of a program to ignore the details of an object's (sub)class and work at a more generic level when appropriate. For example, "Lassie" the Dog may be treated as a Dog much of the time, but when appropriate she is abstracted to the level of Canidae (superclass of Dog) or Carnivora (superclass of Canidae), and so on.


OOP stands Object Oriented Programming and provides Object Oriented implementations.

Methods, Overloading and Overriding

Re-using methods in Java can be done in two ways.

  • Overriding Re-using the same method name with different arguments and perhaps a different return type.
  • Overloading Re-use the same method name with identical arguments and return type is known


Any time you have a class that inherits a method from a superclass, you have the opportunity to override the method (unless, as you learned earlier, the method is marked final). The key benefit of overriding is the ability to define behavior that's specific to a particular subclass type. The following example demonstrates a Horse subclass of Animal overriding the Animal version of the eat() method:

public class Animal {
  public void eat() {
    System.out.println("Generic Animal Eating Generically");
class Horse extends Animal {
  public void eat() {
    System.out.println("Horse eating hay, oats, "
                       + "and horse treats");
Watch Out


Overloaded methods let you reuse the same method name in a class, but with different arguments (and optionally, a different return type). Overloading a method often means you're being a little nicer to those who call your methods, because your code takes on the burden of coping with different argument types rather than forcing the caller to do conversions prior to invoking your method. The rules are simple:

  • Overloaded methods MUST change the argument list.
  • Overloaded methods CAN change the return type.
  • Overloaded methods CAN change the access modifier.
  • Overloaded methods CAN declare new or broader checked exceptions.
  • A method can be overloaded in the same class or in a subclass. In other words, if class A defines a doStuff(int i) method, the subclass B could define a doStuff(String s) method without overriding the superclass version that takes an int. So two methods with the same name but in different classes can still be considered overloaded, if the subclass inherits one version of the method and then declares another overloaded version in its class definition.

External Links