Last night I did a somewhat impromptu speech at my toastmasters club. Looking through past presentations, I saw ones on OOP and Class vs. Prototypes. Trying to condense a longer talk into something understandable by a non-technical audience was clearly out of the question, so Tried to present only the basic principals of OOP in terms they would understand. Given it was an un-rehearsed speech, the words recorded here are likely very different than the speech itself.
Greetings fellow toastmasters, and honored guests. Tonight I would like to explain a somewhat technical and abstract programming topic. I hope that I will be able to do so in terms that may be more familiar to you.
Object oriented programming has a long history, developing through many people and ideas. One of the best known pioneers was Alan Kay. Alan Kay had a lot of interests, including teaching programming concepts, to children as well as adults. One of the systems he developed was called, Smalltalk, which has become one of the iconic early object oriented systems.
Before we get into Kay’s definition of OOP, I should clarify “objects”. An object is an an abstract notion of one particular piece of a programming system. For tonight, our objects of discussion will be toastmasters and roles and officers they fill.
Alan Key defined object oriented programming as having three key qualities: encapsulation, genericity, and messaging.
Encapsulation means the object has secrets. It knows things about the program’s state and processes so that the rest of the program does not have. By keeping information encapsulated, we hope that programs are shield from small changes causing the whole system to fall apart.
When a toastmaster wants to pay his dues, he knows to pay the club treasurer. The member does not need know which bank we use, or the club’s account number. The treasurer encapsulates that information. Going further, the treasurer does not actually keep the account – he communicates with the bank, and does not need to know every detail of how the bank manages it’s accounts. Keeping this information separate makes it easier for us to change treasurers, or for the club to change banks.
Genericity means we don’t have to know the exact identity of an object – or a toastmaster – up front. When a member joins the club, he doesn’t need to know the identity of every treasurer that he will pay during his term with the club – it is sufficient to know that a treasurer will be available who can fulfil the required duties. Likewise, Toasmasters International does not need to know the exact identity of every officer in it’s thousands of clubs in order write the rules that govern the duties of those offers.
For Alan Kay, genericity ment specifically “extreme late binding”, something we all too often practice with our meeting roles. Many of the meeting roles are filled when we arrive at the meeting. We didn’t need to know all those identities to write up the agenda at all – just that someone would be available who could fulfill that role when it came time.
Messaging means that objects communicate with small, fairly abstract messages. Messages express a request, not a detailed set of instructions on how to perform that request. The agenda tells me as president to “open the meeting”. It does not prescribe the manner in which I do so or the exact words to use. While Toastmasters does have some extensive rules and recommendations, I still have control of how I respond to a message.
Messages may have parameters. So for opening the meeting I might receive a list of guests to greet, but I still choose exactly when and how to do so.
I hope I’ve been able communicate some basic principles of object oriented programming, and do so in terms that you can understand. Perhaps if you find yourself facing a large, complicated system, you might try applying encapsulation, genericity, and messaging to the problem.