[ Pobierz całość w formacie PDF ]
.You will most likely encounter this AntiPattern in a C shop that has recently gone to C??, orhas tried to incorporate CORBA interfaces, or has just implemented some kind of object toolthat is supposed to help them.It s usually cheaper in the long run to spend the money onobject-oriented training or just hire new programmers who think in objects.Symptoms And Consequences" Classes with function names such as Calculate_Interest or Display_Table may indicatethe existence of this AntiPattern." All class attributes are private and used only inside the class." Classes with a single action such as a function." An incredibly degenerate architecture that completely misses the point of object-orientedarchitecture." Absolutely no leveraging of object-oriented principles such as inheritance andpolymorphism.This can be extremely expensive to maintain (if it ever worked in the firstplace; but never underestimate the ingenuity of an old programmer who s slowly losing therace to technology)." No way to clearly document (or even explain) how the system works.Class models makeabsolutely no sense." No hope of ever obtaining software reuse." Frustration and hopelessness on the part of testers.Typical Causes" Lack of object-oriented understanding.The implementers didn t get it. This is fairlycommon when developers switch from programming in a nonobject-orientedprogramming language to an object-oriented programming language.Because there arearchitecture, design, and implementation paradigm changes, object-orientation can takeup to three years for a company to fully achieve." Lack of architecture enforcement.When the implementers are clueless about objectorientation, it doesn t matter how well the architecture has been designed; they simplywon t understand what they re doing.And without the right supervision, they will usuallyfind a way to fudge something using the techniques they do know." Specified disaster.Sometimes, those who generate specifications and requirements don tnecessarily have real experience with object-oriented systems.If the system they specifymakes architectural commitments prior to requirements analysis, it can and often doeslead to AntiPatterns such as Functional Decomposition.Known ExceptionsThe Functional Decomposition AntiPattern is fine when an object-oriented solution is notrequired.This exception can be extended to deal with solutions that are purely functional innature but wrapped to provide an object-oriented interface to the implementation code.55 Refactored SolutionIf it is still possible to ascertain what the basic requirements are for the software, define ananalysis model for the software, to explain the critical features of the software from the user spoint of view.This is essential for discovering the underlying motivation for many of thesoftware constructs in a particular code base, which have been lost over time.For all of thesteps in the Functional Decomposition AntiPattern solution, provide detailed documentationof the processes used as the basis for future maintenance efforts.Next, formulate a design model that incorporates the essential pieces of the existing system.Do not focus on improving the model but on establishing a basis for explaining as much ofthe system as possible.Ideally, the design model will justify, or at least rationalize, most ofthe software modules.Developing a design model for an existing code base is enlightening; itprovides insight as to how the overall system fits together.It is reasonable to expect thatseveral parts of the system exist for reasons no longer known and for which no reasonablespeculation can be attempted.For classes that fall outside of the design model, use the following guidelines:1.If the class has a single method, try to better model it as part of an existing class.Frequently, classes designed as helper classes to another class are better off beingcombined into the base class they assist.2.Attempt to combine several classes into a new class that satisfies a design objective.Thegoal is to consolidate the functionality of several types into a single class that captures abroader domain concept than the previous finer-grained classes.For example, ratherthan have classes to manage device access, to filter information to and from the devices,and to control the device, combine them into a single device controller object withmethods that perform the activities previously spread out among several classes.3.If the class does not contain state information of any kind, consider rewriting it as afunction.Potentially, some parts of the system may be best modeled as functions thatcan be accessed throughout various parts of the system without restriction.Examine the design and find similar subsystems.These are reuse candidates.As part ofprogram maintenance, engage in refactoring of the code base to reuse code between similarsubsystems (see the Spaghetti Code solution for a detailed description of softwarerefactoring).ExampleFunctional Decomposition is based upon discrete functions for the purpose of datamanipulation, for example, the use of Jackson Structured Programming.Functions are oftenmethods within an object-oriented environment.The partitioning of functions is based upon adifferent paradigm, which leads to a different grouping of functions and associated data.The simple example in Figure 5.12 shows a functional version of a customer loan scenario:1.Adding a new customer.2.Updating a customer address.3.Calculating a loan to a customer.4.Calculating the interest on a loan.5.Calculating a payment schedule for a customer loan.6.Altering a payment schedule.56 Figure 5.12 Functional decomposition of a customer loan system.Figure 5.13 then shows the object-oriented view of a customer loan application.Theprevious functions map to object methods.Figure 5.13 Object-oriented model of a customer loan system.Related SolutionsIf too much work has already been invested in a system plagued by FunctionalDecomposition, you may be able to salvage things by taking an approach similar to thealternative approach addressed in the Blob AntiPattern.Instead of a bottom-up refactoring of the whole class hierarchy, you may be able to extendthe main routine class to a coordinator class that manages all or most of the system sfunctionality.Function classes can then be massaged into quasi-object-oriented classesby combining them and beefing them up to carry out some of their own processing at thedirection of the modified coordinator class.This process may result in a class hierarchy thatis more workable [Fowler 97].Applicability To Other Viewpoints And ScalesBoth architectural and managerial viewpoints play key roles in either initial prevention orongoing policing against the Functional Decomposition AntiPattern.If a correctobject-oriented architecture was initially planned and the problem occurred in thedevelopment stages, then it is a management challenge to enforce the initial architecture.Likewise, if the cause was a general lack of incorrect architecture initially, then it is still amanagement challenge to recognize this, put the brakes on, and get architectural help thesooner the cheaper [ Pobierz całość w formacie PDF ]