'Poltergeist antipatterns consume unnecessary resources every time they appear and waste useful energy by traversing redundant navigation paths, explains DR. R. SRINIVASAN.

" Poltergeists introduce ghostlike apparition classes which very briefly initiate action in another permanent class"

We will now move to describe another important antipattern, known as "Poltergeists". This name is derived from "Antipattern Session Notes" presented in the Object World West conference in 1996 by Michael Akroyd. He called these as Gypsy AntiPattern because they are like the gypsy wagon of early days, which would be seen one day and will be gone the next day. The question is how does this happen in software development and why this type of similarity is drawn into the picture. Under the parlance of object-oriented programming, Poltergeists depict type of classes that have very limited responsibilities in the system function and they will have very brief life-cycle. This type of antipattern is due to the inefficiency of certain developers in object-oriented programming and because of this they introduce ghostlike apparition classes which would very briefly initiate action in another permanent class. William Brown attributes another reason for introducing such an antipattern. According to him, "certain pure-evil programmers exist who take great glee in leveraging the side effects of certain language functions to mysteriously perform key functionality in their systems". Quite naturally, any transient phenomenon either in hardware or software is very difficult to handle and so with the presence of this type of antipattern, it is extremely difficult to understand and analyse such a system and hence impossible to reuse. Unnecessary and redundant navigation paths in the course of development, highly transient associations of a particular class with another one, presence of stateless classes, occurrence of temporary and short duration objects/classes or classes that exist only to invoke other classes through temporary associations are the true symptoms of the presence of 'Poltergeist Antipattern'. The typical causes for introducing this are, lack of sufficient knowledge and experience in object-oriented architecture of the developers or due to imposition of architectural commitments by the management of the organisation, or even deploying object orientation itself may be a wrong choice for the solution of a specific job.

Poltergeists are one of the most unwanted antipatterns because they consume unnecessary resources every time they appear, they waste useful energy by traversing redundant navigation paths and they clutter object models introducing unnecessary confusion in the course of system analysis. A suggested refactored solution to come out of this situation is to remove Poltergeists from the so called class hierarchy once for all and then taking care to replace its functionality through appropriate changes in the architecture. However, as a proactive action, the project managers should implement strict procedures to get the object-oriented architectures reviewed by expert architects in this field and also avoid deploying developers who do not have sufficient knowledge and experience in object-oriented design in a software development project.

In contrast to Poltergeists, is the "Boat Anchor" antipattern, which is a small portion of software that has no useful purpose in the project. Normally this small segment is purchased at the design stage of the project thinking that it will be very useful during the development stage. But unfortunately, it may result in late realisation by the project team that they have to expend lot of efforts and energy to implement this piece of software during development cycle; the team, after several attempts, would ultimately abandon this software. If this Boat Anchor happens to be a piece of hardware it may go to the extent of collecting dust with a hope of being useful in future.

The refactored solution for this is to have a good technical back-up associated with efficient engineering practices that would provide the appropriate advice in the selection of software or hardware packages needed for the project. Many experts recommend prototyping with evaluation licenses from the vendors to take care of both critical path and back up technologies. From the management point of view, rational decision making is a must as part of the selection process in object technology to identify Boat Anchors before purchasing such packages.

( To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)