Developer

Much ado about objects

Are you lost at development meetings? Do you need some background on object-oriented programming? Managers, read this article to get a grip on OOP terminology.


If your shop uses, or is thinking about using, object-oriented programming (OOP) techniques, you should have a general grasp of what OOP is and why it’s being used. This article offers a quick rundown of the major terms you’ll need to know, and what they mean to your solution.

Why use OOP?
Objects can be incredibly beneficial to a solution, particularly if they are well designed. You can write code once and use it many times instead of writing the same function repeatedly within different portions of an application. This speeds development and reduces bugs by reducing the total amount of code that is written.

The code used to create objects can potentially be used in multiple applications. For example, your team could write a collection of standard classes to calculate your available inventory, and then use that code to create objects in all solutions that require it, such as an ordering interface for your customers, reports for your stock room, and notices for your sales team.

Another major benefit of OOP is its impact on code structure. Concepts like inheritance facilitate development by simplifying variable and function use. OOP makes dividing coding tasks between teams easier. It’s also easier to spot dependencies in child-class code; i.e., code that inherits an object. Testing and debugging are simplified as well.

There are some drawbacks to OOP, however. If a class is modified, all code depending on that class must be retested and potentially modified to support the changes. Also, if documentation is not diligently maintained, it can be difficult to determine what code uses a parent class (code that is inherited). If you discover a bug late in development, it could potentially affect a large portion of your application.

Object-oriented programming follows a different mentality and requires a slightly altered focus than traditional development. For an experienced OOP team, the benefits are phenomenal. If you’re thinking about switching, be sure you have an experienced lead developer to watch out for pitfalls and structure your efforts.

Now that you’ve seen what OOP can do for you, read on to learn some of its concepts and terms.

Object defined
An object is the basic unit upon which object-oriented programs are built. More specifically, an object is an instance of self-contained, or encapsulated, code that performs a specific function. This set of code is most frequently called a class, object class, or module, but other names apply in different programming languages. Each of these terms has slightly different meanings, but they are all collections of code.

As I stated above, an object itself is an instance of a class or other construct. This means that existing physical code serves as a template to create the object. Code that performs a specific function can be written once and referenced several times. Each object has its own identifier, a name given to the object that differentiates it from others.

Objects are not actually copies of the class. Each object has its own namespace in which the identifier and variables are stored, but the object refers back to the original code to perform functions.

An “encapsulated” object has its own set of functions, called methods, and variables, called attributes. When attributes are defined within an object, they generally don’t extend beyond the instance. If I had a class called vegetable and created two object instances, carrot and celery, the values I set for carrot will not affect values for celery. These variables within vegetable itself are never defined since the vegetable class is merely a template.

There are special cases in which functions do affect a class rather than objects created from that class. Class attributes refer to variables specifically designed to preserve a value for use between objects. Class methods are used to define and track class attributes.

Some languages let you call functions specifically from a class without creating an entire instance. If the function is assigned an identifier, or handle, in some cases it can be considered an object in its own right. However, in most cases the function is merely a method used to achieve a result.

Now that you have a definition of what objects are, we can move on to how they’re used.

Using objects
From a main program, an object is constructed by instantiating the class that defines the object. Any methods in that object can be used to create a desired result, and attributes can be referenced and manipulated. When an object is no longer needed, the main program can destruct the object.

One powerful aspect of object classes is that they can inherit other classes. This means that if I’ve written a class named potato, it could inherit the class vegetable, preventing me from having to rewrite functionality that already exists elsewhere. All functions available in the vegetable class would be available from the potato class. Further, vegetable could inherit the class food, and so on.

Some OOP languages allow concepts called dynamic binding, or multiple inheritance. For example, the class potato could inherit from both vegetable and starch classes. This can create issues, such as when both classes have variables of the same name. Each language is different in how it deals with multiple inheritance, and some languages disallow it altogether.

When I’ve inherited a class, I can do what is called overriding a method to achieve a desired result. For example, my vegetable class could have a function called prepare that contains instructions on how to prepare vegetables. However, I want a more specific definition included when I instantiate the potato class, so I create a function with the same name that changes the original behavior. If I didn’t override the prepare method, the function in the vegetable class would be used. This is one aspect of what is called polymorphism.

Another definition of polymorphism involves consistent typing of object methods. This helps to ensure what is referred to as the “is-a” relationship. This relationship dictates that, if I’m able to instantiate the vegetable object, I should be able to instantiate the potato object instead if I wanted. This is because potato is a subclass, or child class, of vegetable. However, because vegetable is not a subclass of potato, the reverse doesn’t hold true. If I instantiate the potato object, I can’t necessarily instantiate the vegetable object in its place.

There are differing schools of thought on how to define polymorphism, although its usage is ultimately the same. Regardless, it’s an important aspect of OOP. When coupled with inheritance, it’s easy to see why OOP is so powerful.

Did you get all that?
While this article wasn’t meant to be an in-depth explanation of object-oriented programming, the key words and phrases I introduced will shed some light on this exciting concept. If this is your first exposure to OOP, or the first time you’ve read an explanation of it, I hope you can now see why it’s become an important trend in modern development.

Editor's Picks

Free Newsletters, In your Inbox