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, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)