The OO Beer Case Analogy

Sometime ago I had a email conversation with a newbie programmer.  The topic of the conversation eventually led to Object Oriented programming.  Having done a fair amount of teaching over the years I have always fallen back on the beer bottle, beer case analogy which for some strange reason programmers, who are majority male, seem to get instantly.  Given this I thought it would be kind of neat to throw it out to the world with great trepidation.  Remember that this analogy is to explain the basic principles for a newbie trying to get to grips with the concept which may seem obvious and natural to many of us but to newbies is certainly not.  So without further adue ‘The  OO Beer Case’ directly from the email exchange:

Object Oriented programming is a conceptual model that can be applied to ANY language that supports it. Therefore regardless of the language you learn OO in you can apply it. OO is in essence very simple at its core and I shall give you a real world example I often use when I have taught. Imagine that your object is a case of beer. The beer case has many properties, such as color, width, height etc. It also has several methods, like open case, close case or getCountofBeer. Now we have a class called beer. We create many instances/copies of beer and then call the method on beer case called add and we pass that method a beer object. This results in the beer being added to the case. The beer of course has properties like width, height, weight, color etc and methods such as open. Now since a beer is based on a base class that we create instances of, if I ‘prototype’ a method or property into that beer base class then ALL existing beers that have already been created automatically get that new method or property we added to the base class. So from a OO perspective the beer case object ‘inherits’ X number of beer objects. Now suppose your fridge is an object and it can inherit multiple beer case objects. So in coding terms you could have this:

var fr = new Fridge()       // create a fridge
var bc = new BeerCase()     // create a beer case
var br = new Beer()         // create a beer
bc.add(br)                  // add the beer to the beer case
fr.add(br)                  // put the beer case in the fridge                   // open the fridge
// Get beer case number 1 from the fridge and call the beer case method get beer 
// and get the first beer and call the method open on the beer.
// This returns beer liquid to the variable getMeABeer
var getMeABeer = fr.beerCases[0].getBeer[0].open()
getMeABeer.drinkIt()             // drink the dam beer

This is the essence of OO and the above example is JS syntax.

So there you have it, the OO Beer Case analogy. Hope you enjoyed it.



What makes a Rich Internet Application (RIA)

Recently I had a discussion on LinkedIn that was spurred by the question ‘How Do I learn JavaScript’.  The conversation took place in the RIA group so the context of the question was learning JavaScript to level to build RIA’s.  During the conversation thread there were a lot of individuals making the argument about Flash/Flex, Silverlight and Java applets are the only true platforms that support the creation of RIAs.  While this may have been the case several years ago in today’s world JavaScript frameworks have been making huge inroads into RIAs.  According to Wikipedia an RIA can be defined as:

Rich Internet Applications (RIAs) are web applications that have many of the characteristics of desktop applications, typically delivered either by way of a site-specific browser, via a browser plug-in, or independently via sandboxes or virtual machines.[1] Adobe Flash, Java and Microsoft Silverlight are currently the three top frameworks, with penetration rates around 95%, 80% and 45% respectively. Continue reading

The great I.T. Divide – I hate big words

I hate big words although I often as not use them.  But I try to stick to English words that one would find in the dictionary not words one would only find in the User Manual to Client I.T. obfuscation!!  It is true that when working with a client there has to be some sort of give and take on knowledge.  As a developer we are beholden to learn their business and as a client they are beholden to learn some basic terminology of information technology .  If this is not done then the lines of communication break down and the end result is a application that does not meet the client’s needs and or expectations. As illustrated by the below cartoon some words should simply not be used… Continue reading