Some Terminology for the Objectively Challenged

We have referred to various terms in the more object oriented parts of the site here we try to explain them in simple terms for folks who might not be fully up to speed on these things. Raddled old Middleware guys like Mr. OLTP may fall into this category.

Objects, Classes and Methods

Objects are programming constructs, entities not unlike Pascal's record, C's struct or Cobol's multilevel DATA DIVISION definitions. Variables of different types are grouped together for common purpose. Objects extend this idea by introducing the idea of functions and function definitions that can be a part of the entity, just as data variables. In turn some of those functions and data can be visible to the outside world or not as the programmer sees fit. Several programming languages claim to have introduced Objects, but the best earliest example we can think of is Smalltalk. In Smalltalk functions held in Objects are called Methods and Objects are Passed Messages rather being invoked with arguments. In C++ [Stroustrup], the Objective successor to C, the Object entity is known as a Class and the functions contained within it, Member Functions. Java can reasonably be thought of as the Object programming language du jour, it has Class like C++, but calls it's member functions methods. You can say you have invoked a Class member function with arguments if you like, but you can also say you passed a message to an Object too, and sound hip, cool and correct in both C++ and Java.

Objects' member functions (or methods) can exhibit polymorphism (read on) and inheritance (again, read on). They simplify their interface to the outside world by data hiding (again, read on).

Polymorphism

An RPC as we have noted in Mr. OLTP's answers, is a subroutine call that may be executed remotely, for example to add two numbers together ...

        result = add (2, 2); 

Polymorphism introduces the idea that there can be several versions of add, defined by the type of data they are invoked with. There can thus be an add for floating point numbers, Complex numbers, Sets of numbers and perhaps more importantly numbers representing important financial information such as money. The addfunction could also be used to concatenate strings or add together the closing balance of two bank accounts if the bank accounts were the type given to it ...

        Money result = add (Account current, Account deposit);

and thus ...

        Money result = add (Account current, Account deposit); 
        Money grandtotal = add (Money grandtotal, Money result); 

You will note that the function add's name stays the same throughout.

Nothing mind bustlingly new to old timers there, the ADD verb in Cobol is polymorphic to an extent as is `+' in just about every program language later than early FORTRAN (remember `+' can be used on types INTEGER, REAL, and COMPLEX. The `new' part of it is allowing the programmer to produce polymorphic functions and procedures, and importantly polymorphic methods (or member functions if you prefer that term) in Classes.

Inheritance and Overloading

Objects as we've seen have both data as variables and functions that can manipulate that data. We can extend an Object by a property known as inheritance. Consider an Object type Account. This can contain entities such as Money balance and String name and member functions such as calculateInterest and so forth. If we could produce a new type of Account by inheriting all these basic properties in the new type, say HighInterestAccount. This type may have a different interest calculation but all the rest is the same. In our new HighIntrestAccount you simply need to provide a new version of the calculateInterest method and everything else could conceivably remain the same. This method of adding new properties to an existing Object definition is known as overloading. In addition you can provide extra variables and member functions as is needed to the new Object type.

Data Hiding and Patterns

These Objects or Classes can have their interface to the outside world made simple and controllable by keeping their data private. It is thus easy to hide the complexity of the data model within an Ojbect and have accessor functions which control the setting and getting of internal data stores. When these accessor functions adopt a standardised naming policy the result is often known as Patterns.

Virtual Methods and Interfaces

In the example above we may be provided with a base Object definition or Class Account for which we absolutely need to provide code for a defined method, calculateInterest. A programmer can therefore produce a CompoundInterestAccount Class or a SimpleInterestAccount Class type as seen fit. Everything they require can be provided for them but the calculateInterest method which they would write themselves. Member functions or Methods such as these are known as either Virtual Member functions or Virtual Methods (again depending upon your programming language).

Taking Virtual Methods to the extreme, a Class can contain nothing but Virtual Methods, in these instances the Class is defined as an Interface (in Java). Other Classes must implement the Interfaces Virtual Methods and thus use it to communicate. This idea is extended to CORBA's mechanism for defining communications between two Objects.

~Z~

Navigation

This is some navigation, it should appear at the side if the page is wide, and at the bottom if it is not.

Search

Seek enlightenment and wisdom: 

Example: "tuxedo".

Highlights

This site is mainly about On-Line Transaction Processing (OLTP). We've some other papers on this:

• Something for non-cognoscente.
• The executive summary.
• OLTP and big computers.
• OLTP and reliability.
• What Transactions are about.
• The need for scaling.
• Tuxedo.
• CICS.

Also of Interest

Juicy morsels from the rest of the site:

• Some site news; it's a sort of infrequently updated journal for the author too.
• Rather specific Technical Notes, the author can still bore people in the Historic Third-person.
• Of the little hacks that have been done recently, the Unofficial Jobcentre Plus Mirror seems to have gained the most traction.
• Other ephemeral, eclectic stuff. Mostly photographs.
• A series of Gormless Anecdotes, basically recycled e-mails.

About the Author

His name is Martin Sullivan. He's a fifty-something some-time computer programmer living in the quaintly named town of Cockermouth in north-west England.

The Company

ZOIS Limited is basically a vehicle for Martin and his OLTP work, he owns it. You can find out more about it elsewhere on the main site.

Pro-Bono Plug

Martin is currently on a health sabbatical, but is interested in the odd bit of pro-bono work by the way of therapeutic recovery. So, if you've anything that he can tackle on a non-commercial basis from his base in Cockermouth please let him know. Unsurprisingly, he's particularly interest in biology, again, and the application of computing to it.