Moving to Object Oriented Design with Perl 5 and Java Servlets

When Object Oriented Perl 5 became ubiquitous and Server Side Java /Servlets became a reality, it was clear which direction the development framework would have to go.

Object Oriented Design (OOD) was the answer.

So what exactly is OOD and how does it help solve the problems we just discussed?

Well, OOD is based on the concept of objects. You can think of an object as a little "black box" of functionality that accepts some standardized input and produces some standardized output.

What is an example of an object that we can sink our teeth into?

Think of a telephone. Do you know how it works--the details of the circuitry from end to end? Probably not. However, whether you know how the phone or the underlying telecommunications systems work, you can still call your buddy.

This is because a phone is a black box. It accepts a phone number as input and returns a phone connection as output. All the magic of creating phone connections in the international telecommunication network is handled magically and invisibly by the phone object. All you need to be concerned with is the protocols for picking up the receiver, dialing, and what you are going to say to your buddy on the other end.

So, in summary, objects have the following attributes:

• Objects can provide "plug-and-play" functionality. They "hide" the internal machinery of how they do their job. Users need not understand these internals in order to use the object.
• Objects accept standardized input. Objects have an API (Application Programmers Interface).
• Objects produce some standardized output.

Essentially, you dump some bit of data into an object, that data gets "magically" transformed inside the object, and then the transformed data is returned to you.

How OOD Solves Problems of the Old Model

There are three primary reasons that objects are excellent programming aides.

First, since you need not concern yourself with the internals of objects in order to use them, you can create complex programs built on a library of objects without needing to be an expert in each area of the program.

For example, if you want to incorporate database access into a program, and you can use a pre-written database connectivity object to do it, you needn't worry about how database connectivity actually works. You just let the object, designed by a database connectivity specialist, do it for you.

Objects allow you to focus on the workflow of a program rather than this nitty gritty of algorithms.

Second, an object-oriented framework makes it very easy to divide development work among community members. Objects can be developed independently and submitted to the common pool of objects. So long as all objects provide a standard API, they can be plugged into other people's work with little effort.

Finally, objects can be modified (made more efficient, secure, and robust) without breaking all the code that uses them. Since the internals are hidden anyway, the client code (the code using an object) does not care how the implementation is changed. So long as the API stays the same, the client code is happy.

WebWare 1.0:The Old Framework
Extropia WebWare Suite 2.0: Towards a New Application Development Framework for Server-Side Web-Based Applications in Perl and Java
The Existing Perl Modules