[ Pobierz całość w formacie PDF ]
.This process is shown in Figure 5.7.46 Figure 5.7 Removing transient associations.VariationsSometimes, with a system composed of the Blob class and its supporting data objects, toomuch work has been invested to enable a refactoring of the class architecture.An alternativeapproach may be available that provides an 80% solution.Instead of a bottom-uprefactoring of the entire class hierarchy, it may be possible to reduce the Blob class from acontroller to a coordinator class.The original Blob class manages the system s functionality;the data classes are extended with some of their own processing.The data classes operateat the direction of the modified coordinator class.This process may allow the retention of theoriginal class hierarchy, except for the migrations of processing functionality from the Blobclass to some of the encapsulated data classes.Riel identifies two major forms of the Blob AntiPattern.He calls these two forms GodClasses: Behavioral Form and Data Form [Riel 96].The Behavioral Form is an object thatcontains a centralized process that interacts with most other parts of the system.The DataForm is an object that contains shared data used by most other objects in the system.Rielintroduces a number of object-oriented heuristics for detect ing and refactoring God Classdesigns.Applicability To Other Viewpoints And ScalesBoth architectural and managerial viewpoints play key roles in the initial prevention of theBlob AntiPattern.Avoidance of the Blob may require ongoing policing of the architecture toassure adequate distribution of responsibilities.It is through an architectural viewpoint that anemerging Blob is recognized.With a mature object-oriented analysis and design process,and an alert manager who understands the design, developers can prevent the cultivation ofa Blob.The most important factor is that, in most cases, it s much less expensive to createappropriate design than to rework design after implementation.Up-front investment in goodarchitecture and team education can ensure a project against the Blob and most otherAntiPatterns.Ask any insurance salesperson, and he or she may tell you that most insuranceis purchased after it was needed by people who are poorer but wiser.ExampleA GUI module that is intended to interface to a processing module gradually takes on theprocessing functionality of background-processing modules.An example of this is aPowerBuilder screen for customer data entry/retrieval.The screen can:1.Display data.2.Edit data.3.Perform simple type validation.The developer then adds functionality to what wasintended to be the decision engine:47 " Complex validation." Algorithms that use the validated data to assess next actions.4.The developer then gets new requirements to:" Extend the GUI to three forms." Make it script-driven (including the development of a script engine)." Add new algorithms to the decision engine.The developer extends the current module to incorporate all of this functionality.So insteadof developing several modules, a single module is developed, as shown in Figure 5.8.If theintended application is architected and designed, it is easier to maintain and extend.Thiswould look like Figure 5.9.Figure 5.8 Life of a protoype GUI.Figure 5.9 Life of a protoype application.Mini-AntiPattern: Continuous ObsolescenceAntiPattern ProblemTechnology is changing so rapidly that developers have trouble keeping up with thecurrent versions of software and finding combinations of product releases that worktogether.Given that every commercial product line evolves through new productreleases, the situation has become increasingly difficult for developers to cope with.Finding compatible releases of products that successfully interoperate is even harder.48 Java is a well-known example of this phenomenom, with new versions coming outevery few months.For example, by the time a book on Java 1.X goes to press, a newJava Development Kit obsoletes the information.Java is not alone; many othertechnologies also participate in Continuous Obsolescence.The most flagrant examplesare products that embed the year in their brand names, such as Product98.In this way,these products flaunt the progression of their obsolescence.Another example is theprogression of Microsoft dynamic technologies:DDEOLE 1.0OLE 2.0COMActiveXDCOMCOM?From the technology marketers perspective, there are two key factors: mindshare andmarketshare.Rapid innovation requires the dedicated attention of consumers to staycurrent with the latest product features, announcements, and terminology.For thosefollowing the technology, rapid innovation contributes to mindshare; in other words,there is always new news about technology X.Once a dominant marketshare isobtained, the suppliers primary income is through obsolescence and replacement ofearlier product releases.The more quickly technologies obsolesce (or are perceived asobsolete), the higher the income.Refactored SolutionAn important stabilizing factor in the technology market is open systems standards.Aconsortium standard is the product of an industry concensus that requires time andinvestment.Joint marketing initiatives build user awareness and acceptance as thetechnologies move into the mainstream.There is an inherent inertia in this process thatbenefits consumers, for once a vendor product is conformant to a standard, themanufacturer is unlikely to change the conformant features of the product.The advantages of a rapidly obsolescing technology are transitive.Architects anddevelopers should depend upon interfaces that are stable or that they control.Opensystems standards give a measure of stability to an otherwise chaotic technologymarket.VariationsThe Wolf Ticket Mini-AntiPattern (Chapter 6) describes various approaches thatconsumers can use to influence product direction toward improved product quality.Lava FlowAntiPattern Name: Lava FlowAlso Known As: Dead CodeMost Frequent Scale: ApplicationRefactored Solution Name: Architectural Configuration ManagementRefactored Solution Type: ProcessRoot Causes: Avarice, Greed, SlothUnbalanced Forces: Management of Functionality, Performance, ComplexityAnecdotal Evidence: Oh that! Well Ray and Emil (they re no longer with thecompany) wrote that routine back when Jim (who left last month) was trying aworkaround for Irene s input processing code (she s in another department now, too).Idon t think it s used anywhere now, but I m not really sure.Irene didn t really documentit very clearly, so we figured we would just leave well enough alone for now.After all,the bloomin thing works doesn t it?! 49 BackgroundIn a data-mining expedition, we began looking for insight into developing a standardinterface for a particular kind of system.The system we were mining was very similar tothose we hoped would eventually support the standard we were working on.It was also aresearch-originated system and highly complex.As we delved into it, we interviewed manyof the developers concerning certain components of the massive number of pages of codeprinted out for us.Over and over, we got the same answer: I don t know what that class isfor; it was written before I got here. We gradually realized that between 30 and 50 percent ofthe actual code that comprised this complex system was not understood or documented byany one currently working on it.Furthermore, as we analyzed it, we learned that thequestionable code really served no purpose in the current system; rather, it was there fromprevious attempts or approaches by long-gone developers.The current staff, while verybright, was loath to modify or delete code that they didn t write or didn t know the purpose of,for fear of breaking something and not knowing why or how to fix it
[ Pobierz całość w formacie PDF ]