For some time, Macromedia has outlined its vision of ColdFusion interoperating seamlessly with Java.
This raises some very interesting, exciting possibilities that CFDJ has invited authors to explore this month.
My own experience with object-oriented programming is somewhat unusual, as my first programming language was Smalltalk.
When people speak of OO languages, they often separate them into "pure" OO languages and "hybrid" languages. Smalltalk is a pure OO language - everything in Smalltalk is an object - while C++ is a hybrid language, mixing OO methodology with procedural programming concepts. The idea be-hind hybrid languages was that someone coming to objects from procedural programming would have an easier time if there were familiar landmarks along the way. I say was because, for the most part, this idea has been abandoned. This was probably a wise decision. After all, science fiction literature is littered with cautionary tales of the dire consequences of combining different types, the common moral being that it's definitely not nice to mess with Mother Nature.
At any rate, the Java creators have made a strong commitment to object-oriented design philosophy. This month I'd like to take a closer look at that philosophy, as - more than any other language I know of - the design philosophy greatly impacts how developers write code.
Object Basics
The fundamental building block for OO languages like Java is this mysterious thing called an object. Actually, not so mysterious. You've been aware of objects for about as long as you've been aware of anything. As a child, you gradually became aware of a Mommy object. This Mommy object had certain distinguishing characteristics: she was warm, soft, and big. As you came to learn, the Mommy object could actually do things - things like feed you, burp you, talk to you, and clean you. To the naked eye you may have appeared to be doing nothing more than drooling, goo-gooing, and eliminating, but you were actually mastering the key concept of OO languages, you clever person, you!
An object is a software simulation of something in the external world. That "something" may be a person, a thing, even an idea, but all objects share the same traits as your Mommy object: they have characteristics (or properties) and they have certain behaviors - things they can do. An object combines properties (data) and behaviors (functions) to produce a simulation. Object-oriented languages provide support for objects by allowing you to create objects.
Classes
Of course, nothing in life - or at least in programming - is that simple, so there are a few other concepts you'll need to learn. Still, this is nothing terribly new. As you got older, you found that your Mommy object was not the only one out there. In your first experience with naming collisions, you found that both you and the funny-looking kid down the street called your respective Mommy objects "Mommy." And the little red-haired girl had a Mommy object too. As you met more people, it seemed that almost everyone had a Mommy object and that, despite their obvious differences, they all had certain common traits and behaviors. You had, in fact, just discovered object classes.
A class is a blueprint - a set of instructions for building specific objects. All Mommies, it turns out, are produced from a central Mommy class. Mommies come off the assembly line (so to speak) with a whole set of properties and behaviors. I've managed to smuggle out the specifications for a Mommy object and while it's too large to reproduce in its entirety, I include snippets of it here.
Class: Mommy
Superclass: Parent
Properties:
firstName
lastName
mood
...
numberOfActiveMommies
Behaviors:
loveChild()
feedChild()
cleanChild()
buyToys()
takeChildToSchool()
...
sayNoToChild()
Notice that some properties, like numberOfActiveMommies, belong to the Mommy class, but not to a specific Mommy. These are often called class
variables. Behaviors are often called
methods, and methods that belong to the Mommy class, but to no specific Mommy, are called
class methods.
As you begin to take in more of your world, you realize that there is another large, warm object hovering about. It's like a Mommy object, and yet not like a Mommy object. You try out a number of names for this object, but the one the object responds to best is "Daddy." Mommy and Daddy have many things in common; as a budding software architect, you realize that such situations often create duplicate code - something you sense should be avoided.
And so, as you're watching Big Bird reveal the mysteries of the number 3, it strikes you: you will come up with a new class, something that encompasses all the commonalities between the Mommy class and the Daddy class. You decide to call it the Parent class. (Later you'll shorten this to "the 'rents.")
A Mommy object is a specific kind of Parent object. A Daddy object is a different kind of Parent object. In discussing this with the funny-looking kid down the street, he suggests that Parent is a superclass to both Mommy and Daddy. He explains that superclasses are like parents to other classes. It's a funny-sounding name from a funny-looking kid, but it'll do.
Instances
While classes as blueprints are interesting, what we really want are objects. After all, the concept of a parent never paid anyone an allowance. But if we have a class defined, we can (almost) always produce an object from the class. This is known as creating an instance of a class. This explains a lot, but not why your Daddy object tells you to ask your Mommy when you ask how you were instantiated. Still, you understand that when Mommy and Daddy tell you that you're going to have a new baby sister, what they really mean is that a new object will be instantiated from the class, Daughter, whose superclass is Child. Why, you wonder, don't adults just say what they mean? It's something you'll wonder about for a long, long time.
Messages and Methods
One central feature of objects is that they're separate entities and are entitled to their privacy. While you were very young, if your Mommy wanted to know how you were feeling, she would do things like feel your forehead and listen to your breathing. Later you developed the method speak(), and she was able to ask you, "How are you feeling today?" In object-speak a Mommy object sent a message to a Child object.
Messages are how objects communicate with each other. If one object wants to know about another object, it does so by asking the object to perform some action - even if this action is nothing more than asking it to retrieve one of its properties. Objects then have methods they use to respond to those messages. If you think of messages as subroutines or functions, you'll get the sense of it.
This allows the object to manage its own affairs and provides a layer of protection to the object's integrity that direct manipulation would not. It also lets the object respond differently depending on where the message is coming from. (This may explain the universal experience of parents who, when asking their child how she's feeling on a test day, receive the answer, "I think I'm sick," while no child in all of recorded history has ever had a fever on school holidays.)
The OO Trinity
ColdFusion isn't an object-oriented language, of course. In general, OO languages support three practices: polymorphism, inheritance, and encapsulation, summed up in the acronym PIE. I'll explain each of these in reverse order.
Encapsulation
What would we do without buzzwords? Life just wouldn't be the same. Encapsulation refers to the fact that both properties and behavior of an object are wrapped up together (encapsulated). Unlike most procedural programming models, data is not separate from functions. An object is a "black box" that accepts message requests and, if it's in a good mood, responds to you. The set of messages an object responds to constitutes its public interface. In addition to this, it has a private set of methods that it alone can call on.
Inheritance
Object classes have parents or superclasses. You saw earlier that the Mommy class has a superclass of Parent (making Mommy a subclass of Parent). This means that every Mommy object produced from the Mommy class blueprint inherits both the properties and the methods of Parent. The inheritance tree is determined by the architect; there is no "right way" to construct this, and as your expertise in OO grows, you'll likely find your inheritance tree changes quite a bit, too.
In rummaging about in my attic, I found an old inheritance tree I constructed as a tot. (Luckily, I've always documented my code meticulously!) It's in Figure 1, showing how I modeled my world way back then.
Note that each class can inherit from only one superclass. This is known as single inheritance, and is the model adopted by Java. A few other languages allow a class to inherit from more than one superclass. I would have liked this model of multiple inheritance when modeling my teacher, Mrs. Sorenson, who clearly belonged to both the Teacher and the Monster class, but multiple inheritance has proven to be very unwieldy.
Polymorphism
Polymorphism is tied to the concept of inheritance, and it's the toughest piece of the PIE to grasp. Stated as simply as I can, polymorphism allows Mrs. Sorenson to tell me, "Give this note to your parents, young man!" - knowing that the Hal object, by virtue of inheriting from the Child class (which implements the method giveNoteToParents()), will know how to give a note to his parents. But, hey, nothing's keeping me from overriding that method in the Hal object!
A Sea Change
Moving to OO programming is a fundamental change in thinking about programming. It's not that it's more complex - in fact, Smalltalk was written for fifth-graders to understand - but if you're new to it, it's quite a switch. In fact, many people have discovered that people new to programming adapt to OO concepts easier and faster than seasoned veterans who must "unlearn" much of the way they approach programming.
In addition to the new concepts to be mastered, most OO languages (including Java) have a number of built-in classes that need to be mastered. When I was working with Smalltalk, we used to say that it took about a year for a new Smalltalker to stop rewriting the existing classes. I think the most helpful advice I can offer is that if you're going to tackle Java, you need to think of Java not so much as another language (obviously, it is that), but as a way of building models that simulate the "real world." Only you as the model maker determine how to organize that real world.
It's often helpful to see common ways of tackling problems. Such solutions are often called software patterns and there are books devoted to this aspect of OO programming.
No Panacea
The philosopher of gloom, Arthur Schopenhauer, once remarked, "All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." I missed the first stage in OO's march toward ascendancy, but was there for stage 2, so it strikes me as ironic that OO has finally gotten respect. Often, though, the pendulum swings dramatically in both directions, and today the conventional wisdom is that OO is the only way to approach a problem.
Coming to ColdFusion from OO programming has given me a different perspective. Despite OO programming's near-universal acceptance, problems lurk under the surface. Gertrude Stein once wrote about Oakland, California, "There's no there there." OO programs can suffer from this. It's hard to see the forest, but you sure can see a lot of tree objects. This often means that as the system becomes more complex, the knowledge required to make changes to the system is substantial. Since so much of a project's life cycle involves maintenance, this can be a burden on both senior programmers and the organizations that employ them.
As I stated earlier, the learning curve for an OO programmer is usually very long, and moving to OO programming is a very large commitment. There should be better reasons to do it than its being fully buzzword compliant. Finally, OO development in distributed environments is difficult due to the great amount of interaction between objects. This type of development seems to work better in small groups, as shown by the interest in extreme programming, a development methodology built to deal with some of these problems.
Resources
One of the great promises of ColdFusion 6.0's adoption of a Java-based model is that it can act as a sort of front end to Java, reducing the complexity of building Java programs while offering new power and interoperability with other, Java-based development initiatives. So, while it behooves us all to learn more about Java, you don't need to abandon the ease of use and speed of development that we all love in ColdFusion.
Web Sites
The site that has the "Two Ralphs Java Newsletter" is
www.javatrainingcenter.com. One of the Ralphs is Ralph Fiol, a good friend and creator of CFObjects. In fact, if you'd like to work with OO concepts in the comfort of ColdFusion, you should check out
www.cfobjects.com. Ralph has done an amazing job of bringing OO concepts to the ColdFusion world.
Books
- Object Technology: A Manager's Guide by David Taylor: This thin, extremely well written book is the best introduction to objects I've ever seen. It's geared for people with no knowledge of object orientation.
- On to Java by Patrick Henry Winston: This book, by a professor at MIT, is simply the best book on Java I've read. In only 360 pages, Patrick Henry Winston somehow manages to perfectly blend an extemely readable style with exactly what you need to know. Don't be intimidated by Winston's credentials; the book's style is extremely approachable.
If you want to learn Java, buy this book.
- Thinking in Java by Bruce Eckel: I'd read this one after you've tackled the first two.
- Java Objects by Jacquie Barker: An excellent book that provides a very good foundation in OO programming as well as Java syntax. If you buy only one book, this might be the most comprehensive.
Subscribe to ColdFusion Developer's Journal Email News Alerts
Subscribe via RSS
