Core IDE - Part III - Refactoring Java applications

INTRODUCTION/OBJECTIVES

This workshop takes you through a demonstration of the WebSphere Studio Application Developer version 5.0 (hereafter called Application Developer) Core IDE. It focuses on the features in which a Java developer would be interested. The sample application is a simple on-line banking application represented by the Account project. We can withdraw funds from this account. This project has with two packages called com.ibm.demo.account and com.ibm.demo.account.testcases.

• Part I : Introduction to the Workbench for the Java Programmer
• Part II : Debugging Java applications
• Part III : Refactoring Java applications
• Part IV: ANT, JUnit and the Scrapbook in Application Developer
  

Section 1 - Refactoring

Refactoring is the process of redesigning the abstractions in a program to make the program easier to understand and maintain without changing the function of the program. Application Developer has excellent refactoring support allowing developers to refactor code with very little effort.

___ 1. Class Rename

a. The first type of refactoring covered is simple class rename.

b. If not already in a Java Perspective, open one by clicking on the Open Perspective button and selecting Java.

c. If CheckingAccount.java is not already open in the Java editor, double-click on CheckingAccount.java in the Package Explorer view of the Java perspective.

Examine the withdraw method. Note that it uses the Txn class. There is a requirement to rename this class to Transaction.

d. Select Txn in CheckingAccount.java by double-clicking on Txn. Click mouse-button 2 and select Refactor->Rename....



e. In the Refactoring - Rename Type dialog, enter Transaction as the new name. Note the various update options available to the developer.



Click the Next> button.

f. The Refactoring - Changes to be performed dialog displays the various changes to be made. Expand Txn.java and then Txn. Select the Type declaration update. The bottom panel displays the Original Source on the left and the Refactored Source on the right. Select the Txn(BigDecimal, Date, String) update to see that the Txn constructor will also be updated.



g. Expand CheckingAccount.java and then CheckingAccount. Select withdraw(BigDecimal) to see the change in that method.

Briefly examine the other changes. Click on the Finish button to refactor, save and compile the code.

h. Note that all of the changes have been made throughout the project without any coding!

i. If CheckingAccount.java is not already open in the Java editor, double-click on CheckingAccount.java in the Package Explorer view of the Java perspective.  To verify that the application still works, run MyTestClient.java by clicking the title tab for MyTestClient.java and click the Run button. Examine the console to verify the output is as expected.

___ 2. Package rename

a. There is a requirement to rename the com.ibm.demo.account package to com.ibm.account. In the Package Explorer view of the Java perspective, select the com.ibm.demo.account package. From the Workbench menu bar, click Refactor->Rename... .



b. In the Refactoring - Rename Type dialog, enter com.ibm.account as the new name. Click the Next> button.

c. The Refactoring - Changes to be performed dialog displays the various changes to be made. Expand MytestClient.java and select import declarations to verify that the import statements will be updated.

Click on the Finish button to refactor, save and compile the code.

d. All of the changes have been made throughout the project without any coding.

To verify that the application still works, run MyTestClient.java by clicking the title tab for MyTestClient.java and clicking the Run button. Examine the console to verify the output is as expected.

___ 3. Pullup

Pullup refactoring is the process of copying fields and methods from a given type to a supertype, making those fields and methods available to other subtypes of the supertype through inheritance. This is quite common when developing as the OO design shifts and changes.

a. If CheckingAccount.java is not already open in the Java editor, double-click on CheckingAccount.java in the Package Explorer view of the Java perspective.

b. In CheckingAccount.java there is a private variable called txnHistory, a linked list of all transactions. Display the inheritance hierarchy for CheckAccount.java by selecting the CheckingAccount class in the Outline view, clicking mouse-button 2 and selecting Open Type Hierarchy. CheckingAccount is a sub-class of Account. It would make more sense to have txnHistory defined in Account for use by other sub-classes of Account such as SavingsAccount. This is an example of what pullup refactoring is designed to do.

c. Highlight txnHistory by double-clicking on it in one of the views where it is displayed, for example the Outline view.  Click mouse-button 2 and select Refactor->Pullup....



d. The Refactoring - Changes to be performed dialog displays the various changes to be made. Expand CheckingAccount.java and select CheckingAccount.  The Original Source display shows the declaration of txnHistory and the Refactored Source shows it removed. Expand Account.java and select Account. The Original Source display shows no declaration of txnHistory and the Refactored Source shows it inserted, as well as the import declarations needed.



Click on the Finish button to refactor, save and compile the code.

e. In the Hierarchy view of the Java perspective, click on CheckingAccount. txnHistory is no longer displayed. Click on Account and notice that txnHistory is defined there. Double-click on Account to open it in the Java editor. Click on txnHistory on the Outline view to move the Java editor to the declaration of txnHistory.



Notice it is now a protected variable.



f. All of the changes have been made throughout the project without any coding. If you want to verify that the application still works, run MyTestClient.java by clicking the title tab for MyTestClient.java and clicking the Run button. Examine the console to verify the output is as expected.

___ 4. Self Encapsulation

Self Encapsulation is the process of removing direct access to an object’s fields and instead using accessor methods. Many times this is more robust code as we are then free to change the implementation of an object without changing how it is accessed.

a. Display CheckingAccount.java in the Java editor. The withdraw method adds transactions to the txnHistory object by directly accessing the txnHistory object and calling the add method.



A better object-oriented design would use getters and settors to access and set  this information.

b. Display Account.java in the Java editor. Highlight txnHistory by double-clicking on it. Click mouse-button 2 and select Refactor-> Self Encapsulate.



c. The Refactoring - Self Encapsulate Field dialog allows the names of the getter and setter to be modified. Click the Next> button.

d. The Refactoring - Changes to be performed dialog displays the various changes to be made. Expand Account.java and select Account.  Refactoring will change the declaration of txnHistory from protected to private and add the getter and setter methods.

Expand CheckingAccount.java and select CheckingAccount.  Refactoring will change the calls to txnHistory to the getter and setter methods as appropriate.



Click on the Finish button to refactor, save and compile the code.

e. In the Account class, notice that txnHistory is now private with appropriate getter and setter methods. In the CheckingAccount class in the withdraw method, note that getTxnHistory is called to add transactions.

f. All of the changes have been made throughout the project without any coding. If you want to verify that the application still works, run MyTestClient.java by clicking the title tab for MyTestClient.java and clicking the Run button. Examine the console to verify the output is as expected.

___ 5. Method Extraction

Method Extraction is the process of removing lines of code in a method and creating a new method from that code, as well as replacing the lines of code with a call to the new method. This can lead to higher code reuse.

a. Display CheckingAccount.java in the Java editor. The withdraw method adds transactions to the txnHistory object by creating a new Transaction object and adding it to the txnHistory object.. It might be better to have a method that does this instead.

Highlight the three lines of code in the Java editor.



b. Click mouse-button 2 and select Refactor->Extract Method....

c. In the Refactoring - Extract Method dialog. specify addToTxnHistory as the Method name. Select private as the Access modifier.



Click the Next> button.

d. The Refactoring - Changes to be performed dialog displays the various changes to be made. In the withdraw method, the original statements are replaced with a method call to addToTxnHistory. The new method addToTxnHistory is added to the CheckingAccount class.

Click on the Finish button to refactor, save and compile the code.

e. In the CheckingAccount class there is now a new private addToTxnHistory method and in the withdraw method, there is now a call to addToTxnHistory with the appropriate parameters.

f. All of the changes have been made throughout the project without any coding. If you want to verify that the application still works, run MyTestClient.java by clicking the title tab for MyTestClient.java and clicking the Run button. Examine the console to verify the output is as expected.