|
 Trouble
starts when experienced programmers have very little knowledge of
object-oriented techniques, warns Dr R Srinivasan. This ultimately
leads to Functional Decomposition Antipattern
"In
the software development life cycle, the most important aspect is
to have a clear understanding of software requirements and specifications"
Over
the last four decades we have come through different generations
in the methodology and languages in software development. Starting
off with machine code programming we have moved on to assembly language,
then to procedural programming using Fortran and COBOL and then
on to structural programming employing Pascal. Now we are in the
era of object orientation using OOP techniques. The development
of new language as well as new techniques have always been for the
sake of making programming and coding easy thereby increasing the
productivity of the developers. But, at times, we find some of the
programmers who are adapted to earlier schemes, try to employ the
same methods in the later ones. This is probably because they hesitate
to learn the advantages of the later systems.
One
such example is the ‘Functional Decomposition’, which
has been employed to split a large application into modules for
easy development and integration. However, some people who are used
to this, are not aware that this method cannot be directly translated
into the class hierarchy of OOP. These people may be very experienced
in procedural programming but may have very little knowledge in
object-oriented techniques. This is where the trouble starts resulting
in Functional Decomposition Antipattern. William Brown gives an
example that some developers try to make every sub routine under
a main routine as a class ignoring class hierarchy and object orientation.
This tendency is mainly because of the wrong notion of such people
who are experienced in their old methods but try to implement their
time-tested methods in the object-oriented architecture. The result
will be a software package with very complicated codes, which will
not only be very difficult at the time of system integration but
also for future maintenance. Because of their experience and seniority
there may not be any voice against what they have done and so the
organisation inadvertently ends up with this antipattern.
As
indicated by experts, there are many symptoms to identify this antipattern.
Some of them are: all class attributes are private and used only
inside the class, a very brittle architecture of the system, completely
missing OO Architecture deploying inheritance and polymorphism,
poor documentation on how the system works, software reuse is impossible
and very difficult to follow any maintenance procedure.
To
stress upon once again, all these things happen because of lack
of understanding of object-oriented technology and lack of knowledge
in software architecture. It is well known that in the software
development life cycle, the most important aspect is to have a clear
understanding of software requirements and specifications, followed
by a thorough analysis to decide the architecture. Whereas, if the
architectural commitments were made prior to the requirement analysis
it may lead to the Functional Decomposition Antipattern.
According
to Brown, et al, the refactored solution will be to ascertain the
basic requirements needed as part of the software to be developed.
The next step should be to come out clearly with an analysis model
taking into account the critical features of the software from the
user’s perspective. Another important factor is to make sure
that a clear documentation is made to explain the processes adopted
that would make maintenance simpler. After deciding the analysis
model, the next step would be to have a design model, which would
incorporate the essential pieces of the existing system, such that
this model will justify and rationalise the software modules.
There
may still be some classes falling outside the design model. The
solution for this will be: a class having a single method should
be modelled as part of an existing class, combine several classes
into new classes satisfying the design objective and a class that
does not have state information should be written as a function.
The refactored solution mentioned is only a suggestion. Actually
it is very difficult to implement a refactored solution for this
antipattern because there is no straightforward way to get a successful
solution. To put it simply, Non-OO design from the experience in
legacy systems is coded in OO language and notation.
(To
be continued) (The author is Chief Technology Officer, iCMG, Bangalore.
He can be contacted at r.srinivasan@icmg.nu)
|
