• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Whenever you search in PBworks or on the Web, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, Slack, and browsed web pages. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.



Page history last edited by PBworks 17 years, 1 month ago

Some thoughts on Object Oriented Programming


I wrote my first object oriented program around 1990 with a proprietary IBM language that was very similar to Smalltalk. The IBM engineer that taught me OOP explained it like this:


Think of yourself. You know you exist. You feel things. You know things. You can do things. That's what an object is.


Within thirty minutes I was so hooked. However, I learned one more lesson from this engineer that really cemented the way I think about OOP:


Just like you, an object has a life. It is born, it does useful things, and then it dies. Some objects only live for a fraction of a second, but most objects have a long and prosperous life.


It was fantastic. Things just clicked in my mind and I saw all of the options this fantastic new way of programming gave me. Plus, the way of thinking of objects as real living things seemed so logical and normal to me.


Then I learned something that greatly saddened me: In C++, objects always died when my programs stopped. This is why I'm such a huge fan of OODBMS'. It isn't that they're databases; quite the contrary. It's that they fix the flaw in most OOPLs that exist today. They bring languages like C++ and Java into line with what I believe object oriented programming is all about: living, breathing, useful objects that -- in most cases -- have long and productive lives. -- Author unknown

I discovered many years ago that trying very hard to hammer out a solution without a good, simple, elegant design was almost impossible. It took enormous amounts of thought just to get something coded, it took long hours to get it half way working, and then it took forever to find all the bugs and fix them. Meanwhile someone who took the time to figure out a way to implement it in a few well-crafted lines of code was already done.


I have worked this way ever since. I have suffered criticism, threats of dismissal and even the dreaded Brutal Sarcasm because of it. But by adhering to this principle I have never been late to a deadline. When I stray from this principle I am always late. Simple.


I have modified my application of this principle in one very important way. When I was working with Kent Beck on the fabled Chrysler Comprehensive Compensation project he taught me not to literally sit and analyze the problem till I had an idea. Instead he taught me how to conduct experiments to gain greater insight. Try coding up a couple solutions. Yes, they will be ugly. But what I found out is that when you code a couple attempts at a solution you will notice that there is a common core or common theme between all the solutions you might be considering. All of a sudden the simple idea presents itself.


Now to do this you must avoid the urge to proclaim yourself done as soon as the first experiment is coded. You must throw it away and start again and again till you find the simple solution. It's always faster and cheaper to throw away complex code now, no matter how much is already invested, working or not. --Don Wells

What I find useful is to completely ignore the objects I have and think about how easy this would be if it was all I had to do, starting over. I write a Spike Solution from scratch. I think about how simple objects to do my thing would interact, if they didn't have to deal with all this history, and code that. That lets me get to the core of the solution, and usually points the way to what should be done in the real objects. -- Ron Jeffries

Comments (0)

You don't have permission to comment on this page.