How to Avoid Anti-Patterns in iOS Apps

By Rajiv Ramnath

If you use the standard process and rules of Object-oriented (OO) design for iOS app creation, your designs should be robust; however, even with a sound process and appropriate guidelines you could create an anti-pattern. Anti- patterns occur when a class inherits functionality through an inappropriate connection.

Even if you’re an experienced developer, you could get things badly wrong resulting in a non functional design. The following covers specific ways you could get things wrong.

Anti-patterns cover a range of pitfalls from organizational design and project management to programming. Here are a couple of anti-patterns relevant to OO design:

  • The so-called Base Bean anti-pattern: This is where a class inherits from another class because the superclass contains functionality needed in the subclass.

    Suppose you’re implementing a dictionary class where you can look up the meanings of words. A hash table, where the words are hashed to locate their meanings is a reasonable data structure to use within a dictionary.

    However, making your dictionary inherit from a hash table isn’t good design. Your dictionary ends up having methods in its interface that have no connection with words and their meanings. Conversely, your class has methods that have everything to do with dictionaries, but nothing at all to do with hash tables.

    Base Bean usually occurs when a software developer confuses an IS-A relationship, which is appropriate for representing a true subclass via inheritance, with a HAS-A relationship, which is better served by a containment relationship. In other words, a Dictionary can have a Hash Table but is not a Hash Table.

    Note that the OO design process described requires you to try to agree on a short, crisp definition for every potential class before elevating it to become a candidate class. This helps you avoid the Base Bean anti-pattern.

  • The Anemic Domain Model: Some groups, particularly the Enterprise Java community, think of domain model classes as simply consisting of getters and setters for the attributes in the class, with no domain behavior in the class (for example, validations, calculations, business rules, and the like). This kind of design is contrary to OO thinking.