Home » Software Development » Page 2

Software Development

Object Cesspool Anti-Pattern

Object pools are a common pattern in development. The canonical example is probably a database connection pool.

If objects returning to the pool are not validated, the pool can gradually fill with garbage objects, turning it into a cesspool of unusable objects.

How to Identify

The two easiest ways to identify if your object pool may become a cesspool:
Read More »Object Cesspool Anti-Pattern

Input Kludge Anti-Pattern

As an anti-pattern, input kludge describes a poor user interface that either rejects or incorrectly handles valid input.

How to Identify

The most obvious code smell that may point to this pattern is ad-hoc input validation routines.

Look for:

  • JavaScript validation function defined directly in web page or view code.
  • Server-side validation routine defined in the presentation layer or the controller.

Example

$('form').on('submit', function(event) {
    if (!(/^.*@.*\.(com|edu|net|org)$/g.exec($('#email').val()))) {
        alert('You must enter a valid email address.');
        return false;
    }
})

Read More »Input Kludge Anti-Pattern

Code Smells and Anti-Patterns

What is an Anti-Pattern?

If you know what a pattern is, then you probably already know about anti-patterns, even if you didn’t know it! In a nutshell, a design pattern is an observed good method to solve a re-occurring problem. You have probably observed patterns in your own development.

For instance, maybe you have an object that needs to be accessed by multiple threads, but the integrity of the application requires that there be no more than one instance. In the countless times that this problem has been solved in the past, most “good” solutions have taken a similar form… what we now call the Singleton pattern.

Read More »Code Smells and Anti-Patterns

Critical Blocks and Improper Lock Objects

Quick catch-up… critical application blocks are blocks of code that can only be executed by one thread at a time. Stock example for illustration:

public static class SmackTracker {
    private static int smackCount = 0;
    private static object locker = new object();
 
    public static void HitItAgain() {
        lock (locker) {
            smackCount++;
        }
    }
}

No matter how many threads call this method, the smackCount will only be incremented by one thread at a time, but this is not a post on the value and usage of thread locking…

Read More »Critical Blocks and Improper Lock Objects

Order of Operations in nested try..catch..finally

Let’s dive in and take a look at some common and not-so-common exception handling arrangements.

Everyone should be familiar with the standard try..catch..finally construct:

try {
    //this code will run only until an exception is thrown
}
catch {
    //this code will run only IF and exception is thrown
}
finally {
    //this code will run always AFTER the try and/or catch blocks have been executed
}

Here is a less common arrangement. When might this be appropriate to use?

try {
    try {
    }
    catch {
    }
}
finally {
}

Now let’s look at some concrete examples. Consider this code snippet:

Read More »Order of Operations in nested try..catch..finally

Exceptional Introduction

There has been a lot of discussion over the years about when and how to use exception throwing and handling. The general consensus seems to shift every once in a while. The performance of exceptions is not the primary purpose of this article, but I felt the need to discuss it in order to truly address the role of exceptions in software troubleshooting.

Exceptions are Expensive, like Store Brand is Cheap

Maybe the best way to breach the topic of exception performance is to simply give you a short list of axioms that I believe to be true.

1. Exceptions are expensive

It has been proven many times that there is additional cost associated with constructing and throwing an exception. This seems to be exaggerated in managed applications (.NET, Java, etc.). That being said, this extra “cost” of constructing and throwing an exception would only be noticeable in time-critical real-time systems, or if they are used excessively. That brings me to my next axiom…

Read More »Exceptional Introduction