Typical Programmer

A glittering performance of rare perception


Popular articles
All articles

About me
Hire me

Introduction to Abject-Oriented Programming

14 Jun 2007

Abject-oriented programming is a set of practices for encouraging code reuse and making sure programmers are producing code that can be used in production for a long time. The number of lines of code in the application is a common measure of the importance of the application, and the number of lines a programmer can produce in a day, week, or month is a useful metric for project planning and resource allocation. Abject-oriented programming is one of the best ways to get the most lines of code in the shortest time.

abject: utterly hopeless, miserable, humiliating, or wretched: abject poverty.

Inheritance

Inheritance is a way to retain features of old code in newer code. The programmer derives from an existing function or block of code by making a copy of the code, then making changes to the copy. The derived code is often specialized by adding features not implemented in the original. In this way the old code is retained but the new code inherits from it.

Programs that use inheritance are characterized by similar blocks of code with small differences appearing throughout the source. Another sign of inheritance is static members: variables and code that are not directly referenced or used, but serve to maintain a link to the original base or parent code.

A pseudo-code example of inheritance:

function getCustName(custID)
{
    custRec = readFromDB("customer", custID);
    fullname = custRec[1] + ' ' + custRec[2];
    return fullname;
}

function getCustEmail(custID)
{
    custRec = readFromDatabase("customer", custID);
    fullname = custRec[1] + ' ' + custRec[2];
    /***************
    * 4/15/96 git : email address stored in
    * second fax field
    ***************/
    return custRec[17];
}

The function getCustEmail was inherited from getCustName when email addresses were added to the application. Inheriting code in this way leverages working code with less risk of introducing bugs.

Subtyping

A form of inheritance where the variable types are changed when inheriting from the original code.

Modularity

A modular program is one that is divided into separate files that share a common header comment block. A module usually consists of:

  • Copyright notice
  • Legal disclaimers
  • Three to five lines of asterisks
  • Change history
  • Description of what the module was originally supposed to do
  • Three to five more lines of asterisks
  • Big block of whitespace surrounded by asterisks or other character, including the name of each function or subroutine, the author’s name or initials, and the date originally written
  • The code

Modules are usually kept to a reasonable size to reduce coupling and improve module strength. If a module gets too big divide it into smaller pieces, copying the copyright notice, legal disclaimers, etc. from the original. Comments can always safely be inherited when deriving one module from another so it’s safest to copy all of the original comments.

Components and Libraries

Abject-oriented programming lends itself to using plug-in components – bits of code found in books or on the Internet. Using a search engine a smart programmer can save time by finding pre-made software components to do almost anything. The best components are black boxes: the programmer doesn’t know or care how the component works. Many large applications are built with a combination of inheritance from other applications and components gleaned from the web.

Encapsulation

The idea behind encapsulation is to keep the data separate from the code. This is sometimes called data hiding, but the data is not really hidden, just protected inside another layer of code. For example, it’s not a good practice to scatter database lookups all over the place. An abject practice is to wrap or hide the database in functions or subroutines, thereby encapsulating the database. In the getCustName function above the database is not queried directly – a function is called to read the database record. All getCustName and getCustEmail (and the many other functions like them) “know” is where in the customer record to find the bits of data they need. How the customer record is read is encapsulated in some other module.

Some programming languages make the programmer declare variables as private or public or protected. That is not an abject practice, though. There’s no way for the author of a module to know which internal variables of their module may be needed to implement features in the future. Programmers should make all variables public (or global), and let the rest of the code decide what should and shouldn’t be private.

Polymorphism

When learning abject-oriented techniques, programmers frequently get stuck on polymorphism. It sounds hard but the idea is simple and easy to implement. Code is polymorphic when it gives different outputs for different kinds of inputs.

To give an example, the functions above can be rewritten as a single polymorphic function by inheriting the code that already works and then encapsulating it into a new function:

function getCustData(custId, what)
{
    if (what == 'name') {
        custRec = readFromDB("customer", custId);
        fullname = custRec[1] + ' ' + custRec[2];
        return fullname;
    } else if (what == 'email') {
        custRec = readFromDB("customer", custId);
        fullname = custRec[1] + ' ' + custRec[2];
        /***************
        * 4/15/96 git : email address stored in
        * second fax field
        ***************/
        return custRec[17];
    }

    /* ... etc. */
}

Polymorphism is related to the idea of non-determinism and Turing’s finite state machines, which you may remember from your Comp Sci classes.

Is-A vs. Has-A

This is a subtlety of good abject-oriented design. When first learning abject principles programmers tend to do everything with inheritance (the is-a model). With more experience programmers find that the has-a relationship is often more appropriate. In the code example above, every customer has a name, but custRec is a database record.

Virtual Classes and Functions

A virtual class or function is code that the application will eventually need, but it isn’t written yet. This is commonly accomplished by providing a base class that the final code will be based on:

function calcSalesTax(price, isTaxable, state)
{
    /****************************************
    *
    * TO DO:
    *
    * get tax rate for the customer state
    * eventually from some table
    *
    *
    ****************************************/

    /** 02/07/99 git -- use WA rate for now **/
    return price * (7.25 / 100.0);
}

A fragile base class is a class or module that has been in the application for a long time, and any change to it will break the rest of the application.

Overloading

Overloading is when a module or chunk of code does more than one thing. An example would be a subroutine to get a customer’s name, email address, and state sales tax rate. Using overloaded functions cuts down on method dispatching, which is one of the reasons other programming styles can result in slow code.

Documentation

It’s said that code should be written for people to read, so it follows that documentation is written for no one to read. Documentation should be written for every new module and then maintained as changes are put into production, or at least the next time there’s a lull in the workload.

A good time to write documentation is when someone in the department gives two-weeks notice: use that time to make sure the departing team member documents all of their code.

Cluttering up the source code with lots of comments explaining what the code is trying to do is distracting and slows down the compiler. That’s why abject shops that follow best practices keep documentation in a document management system where programmers can’t accidentally delete it.

Version Control

Not really a programming practice per se, but abject shops tend to follow similar version control practices. Keeping previous versions of code around, and tracking changes to code, is important even if only one programmer works on the application. Experienced abject programmers follow a system similar to this:

  • Always add your initials and the date of the last revision to the source file’s header.
  • When you are editing a file and realize that your changes are big enough to make reverting hard, save a copy with a .bak extension.
  • Keep multiple backups around by appending your name or initials and the date to the backup file name: custdata_git20040321.bak.
  • Always store backups in the same directory or folder as the original code, to make it easier to see each file’s history.

Conclusion

You’ll probably find that most established shops already follow some or all of these abject-oriented practices. Fads like agile and “extreme” programming come and go, but the abject style has stood the test of time. Managers are familiar with abject practices and will expect you to be able to work with their abject-oriented code base.

Comments

Floyd, 14 June 2007 at 2:10 pm

I thought overloading was the practice of making all variables global so that they can be reused for a different purpose elsewhere in the program. Or is that garbage collection?

Unfortunately WordPress lost a lot of great comments right here.

admin, 14 June 2007 at 8:26 pm

Thanks for all the great comments. I’ve learned a few things today!

@Dave: Database design is a big subject that I would like to write about someday.

@Chetan: Thanks for mentioning the commenting out technique. That’s called making a method protected.

@Zach: I assume you are joking about subversion — this is a technical discussion, not about management.

@Onur Yalazi: Sorry, we’re not using Perl.

@A: One of my colleagues pointed out that overloading is when data is passed to a function or module in globals because too many function parameters overload the compiler. My mistake! And @Floyd — when variables are kept in globals there’s no need for garbage collection.

@Mark: I’m not familiar with the technique of making code explain itself. Is that the same as printing status messages from subroutines, like print “got here!” so you can tell where the crash happened? If that’s what you mean that is commonly done in AOP, and not just with C#.

@Mysingen: I worked at a place with an “expert consultant” who did a lot of code generation with awk and sed and “shell scripts.” Unfortunately he left before documenting his work but it still works most of the time.

@Ron: GREAT idea about the directories.

@booboo: Please no ad-hominy attacks, everyone has different opinions on programming. That’s why some programmers use Visual Basic and others use VBScript — it’s all about choice.

@Dumbo: I read somewhere (probably MSDN?) that GOTO is much faster than a loop or IF statement.

John, 15 June 2007 at 9:10 am

Wow – there are a lot of inaccuracies / bad practices put forth in this article. Make all variables global? Btw- it’s ad hominem – not ad hominey. I think once you’ve spent more time in an object oriented language you’ll get a better idea of concepts like overloading, encapsulation, inheritance – etc.

Wow, 15 June 2007 at 10:40 am

What the author has found by writing this article is the fact that a lot of people calling themselves professional developers don’t know anything about programming. If you can’t see the humor in this then you need to seriously go back to the books and just stay there while you are at it. He actually points fun at the people who made comments above by saying “Abject-oriented programming lends itself to using plug-in components — bits of code found in books or on the Internet.” too funny

Andrew E, 16 June 2007 at 9:30 am

I laughed and laughed at everything…until I got to Version Control. Then I encountered great shame.

Steve, 16 June 2007 at 9:44 am

It’s funny how many people are taking this seriously. Any “real world” programming department and any company is guilty of any or all of the above. If we can’t laugh at ourselves then who CAN we laugh at?

Graham, 16 June 2007 at 10:15 am

I have to object to the “Document the code” part. If someone is just leaving the company now, why would you get them to document at that point. In my experience if the code isn’t documented when its written, it’s garbage. How long did this person work with the code for? 2 weeks is likely inadequate. Document when you code – just answer “why” you did it that way, and we’re good to go.

Anton, 16 June 2007 at 11:35 am

Guys, this article is the biggest piece of crap I’ve every seen. No offense, but seriously. Make all members public? Comment out code? These are things I used to do when I just got out of college. Over time, you see why people tell to avoid these. I love the part about making code reusable. “Duuhhh” is the word that comes to mind. How is this different from what programmers have been trying to achieve since the first computer program took its first breath. If there was an easy way of having every piece of code be always easy to reuse, believe you me, it would have been a standard practice and would have been taught to the author of this redundency as a part of the curriculum of the school he seem to have recently graduated from. Alas, there isnt a simple way. Software is complicated. Some pieces can be made reusable, others cannot. Others can be made reusable, but are not because of various timeline and budget constraints imposed on programmers by the business types.

I say, let’s not beat the proverbial dead horse to the pulp, and let’s concentrate on figuring out how to apply what’s proven itself over time. And if someone with actual experience can suggest something really new, let her back it up with actual examples that proove why her way is better. Claiming that making all variables public is the way to go because you were able to hack code quicker is not what most of us look for when we spend our precious weekend time reading programming articles.

John Bokma, 16 June 2007 at 12:48 pm

Really good article.

What worries me though, is that some people take it very serious…

A, 16 June 2007 at 12:50 pm

You guys must be kidding. AO is against almost all the things I have ever learned about programming!!

You sure you guys are not kidding?

Henk, 16 June 2007 at 1:19 pm

It was a good laugh until I read the comments and realized that most of the people didn’t get the joke :S

I have to confess, tough: I have made some nasty Polymorphistic functions in my time 😀

F, 16 June 2007 at 1:58 pm

I don’t know what’s the most funny; the article or all the people not understanding the jokes in it.

Lance Walton, 5 July 2007 at 3:11 am

This is a work of satirical genius. However, as I read it, I got a horrible feeling that some people wouldn’t understand that it was meant to be humour and might take it as advice. When I read the comments, I see that the first part of my fear was real. I suspect the second part will be as well…

Ton, 24 July 2007 at 7:48 am

Abject-oriented programming sounds fantastic – why have I not heard of it before? I’ve been telling all my teammates about it, and we’re going to try it on our next project. Luckily, many of its proposals are quite close to practices we already follow. It seems our team has been doing a lot of things right – our management will be delighted to hear this!

pragma, 3 August 2007 at 12:00 pm

Ton, is your company hiring? I have been teaching some 20-odd students all about Abject-Oriented, imprinting it in their heads this perfect way of life. With these professionally-educated students, you could excel like never before!

😉