Vivek Soni

Introduction to Abject-Oriented Programming

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 [...]

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 is a kind 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.

Source: typicalprogrammer

(2) Comments Permalink