Related


Links

Am I free?


Social bookmarking

Delicious Bookmark this on Delicious


Tweets
Flickr randomness


Badges and junk

Support The Commons

Valid HTML 4.01 Strict
Valid CSS!













Introduction

This article is an introduction to metaphor-oriented programming (MOP), the latest and possibly the most significant paradigmatic abstraction in software engineering.

We begin with an overview of MOP and MOPED (metaphor-oriented program engineering and design), move onto an example and end with thoughts on its use in higher education.

Along the way, we argue for a "metaphors-first" approach to teaching programming, while noting that this appears to require very little change in most HE courses.

What is MOP?

Before MOP

Without exception, advances in programming seek to simplify the process of creating working software. In almost all cases, this is achieved by abstraction, moving away from the real and concrete world of electronics and into spaces closer to human understanding. A "dumbing-down", if you like. Think about these examples:

More recent paradigms have simplified things even further by breaking down the clear separation of concerns engendered by OOP. Aspect-oriented programming, for example, allows programmers to be less conscientious and skillful. The potential impact on training budgets is obvious.

MOP

Metaphor-oriented programming takes this one step further, by allowing the programmer to lapse into the kind of vagaries that fill "real-life" specifications.

For example, when talking to a subordinate about the likely outcome if he is found sleeping at work again, we rarely say "I will invoke my reprimand method, with you as the first and only parameter!", but it is often heard (where I work, anyway) "I'll come down on you like a tonne of bricks." If you're thinking "that's a simile, not a metaphor", you aren't relaxed enough for MOP, yet.

Aspect-oriented programming is important because allows us to be less strict about partitioning. In the same way, MOP allows us to be less strict about specifying interaction.

In the next section, we look more closely at MOP and the methodology surrounding it by giving a high-level description

MOPED and a high-level MOP example

Metaphor-oriented program engineering and design (MOPED), is as user-friendly as MOP. That is, we are allowed to be less concrete than with OO.

As an example, we will design a "right-leg" class and associated metaphors. This example has been chosen to be representative of the level of reality and sense found in the average programming course.

First, we have the usual hierarchy of classes. So far, there is no difference between OOP and MOP.

Now we list the metaphors suitable for interacting with the right leg. Some of these would be common and part of a library of metaphors. Others would be application-specific.

Here is our list:

These metaphors would have standard operations that the class definition maps to operations. In some cases, more than one metaphoric operation would map to a single method. "Slice" and "cut", when applied to the left leg as a "knife", would map to "swingInArc", or possibly to another metaphoric operation that ultimately maps to a method, such as "swinging" (as a pendulum).

The key point is that the class deals with these mappings and, once written, allows a programmer to interact with them in any number of vague, half-baked and uncertain ways.

Metaphors-first

In the teaching of programming, MOP will be revolutionary. Currently, the single biggest hurdle faced by students learning to program is the change from programs representing sailing boats, naive bank accounts, people and furniture to creating classes dealing with abstract data types, hardware abstractions and GUI peculiarities (MouseActionListenerAdapterSocket, for example).

With MOP, this change need never happen. Instead, we reduce "real world" problems into the vague metaphors that the students are used to.

Example: Memory is like a row of pigeon-holes, as the classroom metaphor goes. So why not create metaphoric mappings such as "post" and "peek"? Going further, we could add lockable doors to protect regions of memory (goodbye segfaults!) and stickers to mark regions' purpose (addSticker("pikachu")).

Conclusions

University staff are constantly being put under pressure to produce results, employers are constantly seeking ways to reduce training costs, programmers are always looking for the easy option. As long as we're careful about how we mix our metaphors, MOP could be the answer to many people's prayers.

Comments

See all or post