|
 Poltergeist
antipatterns consume unnecessary resources every time they appear
and waste useful energy by traversing redundant navigation paths,
explains Dr R Srinivasan
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, iCMG, Bangalore.
He can be contacted at r.srinivasan@icmg.nu)
|
