Refactoring: Improving the Design of Existing Code
Martin Fowler, Kent Beck
Language: English
Pages: 464
ISBN: 0201485672
Format: PDF / Kindle (mobi) / ePub
As the application of object technology--particularly the Java programming language--has become commonplace, a new problem has emerged to confront the software development community. Significant numbers of poorly designed programs have been created by less-experienced developers, resulting in applications that are inefficient and hard to maintain and extend. Increasingly, software system professionals are discovering just how difficult it is to work with these inherited, non-optimal applications. For several years, expert-level object programmers have employed a growing collection of techniques to improve the structural integrity and performance of such existing software programs. Referred to as refactoring, these practices have remained in the domain of experts because no attempt has been made to transcribe the lore into a form that all developers could use. . .until now. In Refactoring: Improving the Design of Existing Software, renowned object technology mentor Martin Fowler breaks new ground, demystifying these master practices and demonstrating how software practitioners can realize the significant benefits of this new process. With proper training a skilled system designe
Beginning SQL Server 2012 for Developers
Linux Device Drivers (3rd Edition)
Test-Driven Infrastructure with Chef: Bring Behavior-Driven Development to Infrastructure as Code
Why Nations Fail: The Origins of Power, Prosperity, and Poverty
Message Chains Middle Man Inappropriate Intimacy Alternative Classes with Different Interfaces Incomplete Library Class Data Class Refused Bequest Comments Chapter 4. Building Tests The Value of Self-testing Code The JUnit Testing Framework Adding More Tests Chapter 5. Toward a Catalog of Refactorings Format of the Refactorings Finding References How Mature Are These Refactorings? Chapter 6. Composing Methods Extract Method Inline Method Inline Temp Replace Temp with Query
because it allows you to have separate locks on the two resulting classes. If you don't need to lock both objects you don't have to. For more on this see section 3.3 in Lea [Lea]. However, there is a danger there. If you need to ensure that both objects are locked together, you get into the area of transactions and other kinds of shared locks. As discussed in Lea by section 8.1 [Lea], this is complex territory and requires heavier machinery than it is typically worth. Transactions are very
EndField_FocusLost(java.awt.event.FocusEvent event) { if (isNotInteger(_endField.getText())) _endField.setText("0"); calculateLength(); } void LengthField_FocusLost(java.awt.event.FocusEvent event) { if (isNotInteger(_lengthField.getText())) _lengthField.setText("0"); calculateEnd(); } If you are wondering why I did the window this way, I just did it the easiest way my IDE (Cafe) encouraged me to. All fields insert a zero if any noninteger characters appear and call the relevant calculation
the subclass method and adjust it to fit. ?rarr; You may need to make some private members of the superclass protected in order to do this. Compile and test. Remove the copied leg of the conditional statement. Compile and test. Repeat with each leg of the conditional statement until all legs are turned into subclass methods. Make the superclass method abstract. Example I use the tedious and simplistic example of employee payment. I'm using the classes after using
same. I need to build a solid set of tests for that section of code. The tests are essential because even though I follow refactorings structured to avoid most of the opportunities for introducing bugs, I'm still human and still make mistakes. Thus I need solid tests. Because the statement result produces a string, I create a few customers, give each customer a few rentals of various kinds of films, and generate the statement strings. I then do a string comparison between the new string and some