Object Oriented Programming Concepts

intro10eBriefI recently learned that a close family member is going through his first CS course. It’s intro to programming in Java. And the book is “Introduction to Java Programming, Brief Edition. 10th Edition” by Daniel Liang (http://www.cs.armstrong.edu/liang/).

So  I took a quick look at the book, and was reminded there’s a gap in almost every Java book when it comes to objected oriented programming. It’s a simple concept that is usually glossed over or ignored completely when introducing object oriented programming concepts. Here it is:

Object oriented programming is about organizing and protecting your code, not about modeling things in the real world.

Object oriented books usually start out by explaining that object oriented programming combines data with behavior into classes. Then comes the car analogy. It’s always a car, or plane for some reason.  Yes, that helps. But there’s another more basic, fundamental concept that will help people make the mental leap into object oriented programming. As it is there are a lot of terms to learn with object oriented programming like polymorphism, accessors, etc. Not to mention UML diagrams.  Clever analogies like the car analogy risk confusing people before clarifying objected oriented programming.

So, here’s the information that may be helpful:

Object Oriented programming can be said to be about code management, reusability, and visibility.

The rest of this blog explains what I mean by that.

Code Management

Programs have lots of code. The instructions and variables that make up your code are organized into classes. Where you put that code depends on how you want to organize it. So it’s helpful to ensure each class deals with a specific topic or limited problem.

While each class organizes code, each package organizes classes. For example, all of your networking classes might go into one package. All of the code that downloads movies from YouTube can go into one class.

Some useful statements to complete while deciding where to put your code:

All the code in class X does __________.  All the classes in package Y does _______.

The part you fill in the blank should be something simple, and singular, like

All the code in java.lang.String stores an immutable string.

All the classes in the package android.widget display things on the screen.


When you find two blocks of code that are the same, or nearly identical, that code can be consolidated into a function. Even if it’s three lines of code. In this example, the code in function unConsolidated is factored into one simple function called consolidated with a parameter:

public class Foo {

    public void unConsolidated() {
        for (int i = 0; i < 100; i++) {

        for (int i = 0; i < 200; i++) {

    public void consolidated(int max) {
        for (int i = 0; i < max; i++) {


When you write code, you’re writing it for somebody to use. Your code will get compiled into a JAR file, and that JAR file will be consumed by that other developer’s toolchain. The visibility that you pick for each class, member, and function, determines what that other developer can see. Here are some rough guidelines.

  • public: another developer can see whatever is marked with this accessor. Use it to tell another developer, “Hey, this is important.”
  • private: another developer can’t see whatever is marked with this accessor. Use it to tell yourself, “It’s a secret. Or, nobody else should see it because they shouldn’t need to worry about it.
  • protected: another developer can see whatever is marked with this accessor if they extend your class. Use it to tell another developer, “Hey this is available, but only to child classes.”
  • default/no accessor: another developer can see things with no accessor if that developer’s code is in a package with the same name. Use this to tell another developer, “This is available if your code is defined in some class that lives in a package with the same.


A Bigger Picture

So, if you remember that object oriented programming is a way to make these three types of choices it may help make sense of the other concepts in object oriented programming. I’ll use inheritance as an example.


Inheritance a way to organize code into a hierarchy. Child classes are there to modify the parent class. They get to re-use code from the parent classes.

This class declaration means you don’t know anything about BaseAdapter but the class Foo is going to rely on whatever code is in BaseAdapter:

public class Foo extends BaseAdapter{}


And this class definition means that wherever OnClickReceiver referenced in your code, you know that something is probably going to call one of its functions:

public class Foo implements OnClickReceiver{}


This function is telling you that it doesn’t care how Foo implements OnClickReceiver‘s functions, but you can call Bar.clickMe and pass in any instance of Foo (because it implements OnClickReceiver):

public class Bar{ public void clickMe(OnClickReceiver receiver); }


Interfaces are another great example.  They’re a way to tell the compiler and virtual machine to stop everything if a class doesn’t have all the functions you expect it to have. Interfaces are often understood as a type of “contract” for classes that implement them. This is true, but the idea is a bit ambiguous. We’re programming after all, not signing business agreements.

Here’s an interface on the Android platform:

public interface OnAlarmListener {
    public void onAlarm(Alarm alarm);


When you use an interface you’re telling the compiler and the virtual machine to let you know if a class doesn’t implement all the functions. This class definition would cause the compiler to generate an error and then stop:

public class Foo implements OnAlarmListener { 
    public void onAlarms(Alarm alarm){
        // M-T do nothing


Notice the function name “onAlarms” is plural. If the programmer figures out how to  build this class and get it into a JAR file without compilation errors (which is possible), you would expect the virtual machine should to stop the program when it runs for the same reason.


Until I have time to create a cheat sheet, I’ll leave it as an exercise for you to look at each object oriented concept you encounter and think of in terms of one of these three basic concepts:

code organization, reusability, and visibility

If you run into any object oriented concept that doesn’t seem to be related to one of those three concepts, then you might be over complicating things. There are aspects of object oriented programming that relate to how a compiler actually deals with your code and how a computer runs it, but those are different topics.



And now it's your turn ... comment here or on Twitter (@Androider)

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s