Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T17:01:15Z

Sjames3: /* See Also */

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* assignment_team.rb
* course_team.rb
* team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself")<ref>http://en.wikipedia.org/wiki/Don%27t_Repeat_Yourself</ref> principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
This project took a two-stage approach. The first stage involved renaming methods and variables, but largely avoiding invasive code changes that could have an impact on the functionality. The second stage separately made changes like merging or removing duplicate functions.

Several main goals were kept in mind throughout this process:
# DRY
# Ruby naming conventions
# Project style conventions
# Good design cosiderations, such as high cohesion and low coupling.

=UML Class Diagram=
[[File:Writing 2 UML.png]]
=Team Model: team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_participants
| Removed more complex version of two duplicate functions.
| Adherence to the DRY principle.
|-
| add_member
| Renamed to 'add_participant'
| Enforce consistency in how we refer to users in a team.
|-
| copy_members
| Renamed to 'copy_participants'
| Enforce consistency in how we refer to users in a team.
|-
| delete_all_by_parent
| Changed logic from 'for team in teams ... end' to 'teams.each { |team| ... }'
| Consistency in accessing collection members.
|-
| delete_all_by_parent
| Changed logic from 'for i in 1..no_of_teams' to '(1..no_of_teams).each { |i|'
| Consistency in accessing collection members.
|-
|}

=AssignmentTeam Model: assignment_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_first_member
| Renamed to get_first_participant
| Enforce consistency in how we refer to users in a team.
|-
| includes?
| Renamed to has_participant
| Enforce consistency in how we refer to users in a team.
|-
| get_participants
| Renamed to participants
| Enforce consistency in how we name Ruby functions.
|-
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| remove_team_by_id
| Renamed to delete
| Enforce consistency in how we name Ruby functions.
|-
| reviewed_contributor?
| Changed logic from '(...) == false' to '!(...)'
| Legibility.
|-
| get_hyperlinks
| Renamed team_member local variable to 'participant'
| Enforce consistency in how we refer to users in a team.
|-
|}

=CourseTeam Model: course_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| copy_members
| Renamed to copy_participants
| Enforce consistency in how we refer to users in a team.
|-
|}

=Considerations for Future Work=
* The import/export functionality for different team participants could be combined and simplified. This responsibility could probably be broken out into separate classes so that this responsiblity is encapsulated better.
* Rather than extending the Team class to create separate classes to capture related functionality when teams are associated with assignments or courses, it might be better to just associate teams with courses or assignments directly and then delegate related functionality (like importing/exporting data) to separate helper classes.

=Conclusion=
* The renaming and refactoring was performed as suggested in the given requirements. These changes helped enforce consistency and common conventions.
* Some common functionality was combined to adhere to the DRY principle.
* Methods were grouped and organized within their model classes to make them easier to read and mentally consume, and to suggest groups of responsibilities for potential future work.

=References=

<references/>

=See Also=

* '''OSS - E1452 project on GitHub:''' https://github.com/sjames3/expertiza
* '''Expertiza Project Documentation:''' http://wikis.lib.ncsu.edu/index.php/Expertiza
* '''Working Expertiza Site:''' http://expertiza.ncsu.edu/
* '''Expertiza on GitHub:''' https://github.com/expertiza/expertiza

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T17:00:57Z

Sjames3: /* See Also */

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* assignment_team.rb
* course_team.rb
* team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself")<ref>http://en.wikipedia.org/wiki/Don%27t_Repeat_Yourself</ref> principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
This project took a two-stage approach. The first stage involved renaming methods and variables, but largely avoiding invasive code changes that could have an impact on the functionality. The second stage separately made changes like merging or removing duplicate functions.

Several main goals were kept in mind throughout this process:
# DRY
# Ruby naming conventions
# Project style conventions
# Good design cosiderations, such as high cohesion and low coupling.

=UML Class Diagram=
[[File:Writing 2 UML.png]]
=Team Model: team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_participants
| Removed more complex version of two duplicate functions.
| Adherence to the DRY principle.
|-
| add_member
| Renamed to 'add_participant'
| Enforce consistency in how we refer to users in a team.
|-
| copy_members
| Renamed to 'copy_participants'
| Enforce consistency in how we refer to users in a team.
|-
| delete_all_by_parent
| Changed logic from 'for team in teams ... end' to 'teams.each { |team| ... }'
| Consistency in accessing collection members.
|-
| delete_all_by_parent
| Changed logic from 'for i in 1..no_of_teams' to '(1..no_of_teams).each { |i|'
| Consistency in accessing collection members.
|-
|}

=AssignmentTeam Model: assignment_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_first_member
| Renamed to get_first_participant
| Enforce consistency in how we refer to users in a team.
|-
| includes?
| Renamed to has_participant
| Enforce consistency in how we refer to users in a team.
|-
| get_participants
| Renamed to participants
| Enforce consistency in how we name Ruby functions.
|-
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| remove_team_by_id
| Renamed to delete
| Enforce consistency in how we name Ruby functions.
|-
| reviewed_contributor?
| Changed logic from '(...) == false' to '!(...)'
| Legibility.
|-
| get_hyperlinks
| Renamed team_member local variable to 'participant'
| Enforce consistency in how we refer to users in a team.
|-
|}

=CourseTeam Model: course_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| copy_members
| Renamed to copy_participants
| Enforce consistency in how we refer to users in a team.
|-
|}

=Considerations for Future Work=
* The import/export functionality for different team participants could be combined and simplified. This responsibility could probably be broken out into separate classes so that this responsiblity is encapsulated better.
* Rather than extending the Team class to create separate classes to capture related functionality when teams are associated with assignments or courses, it might be better to just associate teams with courses or assignments directly and then delegate related functionality (like importing/exporting data) to separate helper classes.

=Conclusion=
* The renaming and refactoring was performed as suggested in the given requirements. These changes helped enforce consistency and common conventions.
* Some common functionality was combined to adhere to the DRY principle.
* Methods were grouped and organized within their model classes to make them easier to read and mentally consume, and to suggest groups of responsibilities for potential future work.

=References=

<references/>

=See Also=

* '''OSS - E1452 project on GitHub:''' https://github.com/sjames3/expertiza
* '''Expertiza project documentation:''' http://wikis.lib.ncsu.edu/index.php/Expertiza
* '''Working Expertiza site:''' http://expertiza.ncsu.edu/
* '''Expertiza on GitHub:''' https://github.com/expertiza/expertiza

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T17:00:06Z

Sjames3:

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* assignment_team.rb
* course_team.rb
* team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself")<ref>http://en.wikipedia.org/wiki/Don%27t_Repeat_Yourself</ref> principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
This project took a two-stage approach. The first stage involved renaming methods and variables, but largely avoiding invasive code changes that could have an impact on the functionality. The second stage separately made changes like merging or removing duplicate functions.

Several main goals were kept in mind throughout this process:
# DRY
# Ruby naming conventions
# Project style conventions
# Good design cosiderations, such as high cohesion and low coupling.

=UML Class Diagram=
[[File:Writing 2 UML.png]]
=Team Model: team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_participants
| Removed more complex version of two duplicate functions.
| Adherence to the DRY principle.
|-
| add_member
| Renamed to 'add_participant'
| Enforce consistency in how we refer to users in a team.
|-
| copy_members
| Renamed to 'copy_participants'
| Enforce consistency in how we refer to users in a team.
|-
| delete_all_by_parent
| Changed logic from 'for team in teams ... end' to 'teams.each { |team| ... }'
| Consistency in accessing collection members.
|-
| delete_all_by_parent
| Changed logic from 'for i in 1..no_of_teams' to '(1..no_of_teams).each { |i|'
| Consistency in accessing collection members.
|-
|}

=AssignmentTeam Model: assignment_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_first_member
| Renamed to get_first_participant
| Enforce consistency in how we refer to users in a team.
|-
| includes?
| Renamed to has_participant
| Enforce consistency in how we refer to users in a team.
|-
| get_participants
| Renamed to participants
| Enforce consistency in how we name Ruby functions.
|-
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| remove_team_by_id
| Renamed to delete
| Enforce consistency in how we name Ruby functions.
|-
| reviewed_contributor?
| Changed logic from '(...) == false' to '!(...)'
| Legibility.
|-
| get_hyperlinks
| Renamed team_member local variable to 'participant'
| Enforce consistency in how we refer to users in a team.
|-
|}

=CourseTeam Model: course_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| copy_members
| Renamed to copy_participants
| Enforce consistency in how we refer to users in a team.
|-
|}

=Considerations for Future Work=
* The import/export functionality for different team participants could be combined and simplified. This responsibility could probably be broken out into separate classes so that this responsiblity is encapsulated better.
* Rather than extending the Team class to create separate classes to capture related functionality when teams are associated with assignments or courses, it might be better to just associate teams with courses or assignments directly and then delegate related functionality (like importing/exporting data) to separate helper classes.

=Conclusion=
* The renaming and refactoring was performed as suggested in the given requirements. These changes helped enforce consistency and common conventions.
* Some common functionality was combined to adhere to the DRY principle.
* Methods were grouped and organized within their model classes to make them easier to read and mentally consume, and to suggest groups of responsibilities for potential future work.

=References=

<references/>

=See Also=

* OSS - E1452 project on GitHub https://github.com/sjames3/expertiza
* Expertiza project documentation can be found at http://wikis.lib.ncsu.edu/index.php/Expertiza
* The working Expertiza site is accessible at link http://expertiza.ncsu.edu/
* Expertiza on GitHub https://github.com/expertiza/expertiza

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:58:26Z

Sjames3:

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* assignment_team.rb
* course_team.rb
* team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("[http://en.wikipedia.org/wiki/Don%27t_Repeat_Yourself Don't Repeat Yourself]") principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
This project took a two-stage approach. The first stage involved renaming methods and variables, but largely avoiding invasive code changes that could have an impact on the functionality. The second stage separately made changes like merging or removing duplicate functions.

Several main goals were kept in mind throughout this process:
# DRY
# Ruby naming conventions
# Project style conventions
# Good design cosiderations, such as high cohesion and low coupling.

=UML Class Diagram=
[[File:Writing 2 UML.png]]
=Team Model: team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_participants
| Removed more complex version of two duplicate functions.
| Adherence to the DRY principle.
|-
| add_member
| Renamed to 'add_participant'
| Enforce consistency in how we refer to users in a team.
|-
| copy_members
| Renamed to 'copy_participants'
| Enforce consistency in how we refer to users in a team.
|-
| delete_all_by_parent
| Changed logic from 'for team in teams ... end' to 'teams.each { |team| ... }'
| Consistency in accessing collection members.
|-
| delete_all_by_parent
| Changed logic from 'for i in 1..no_of_teams' to '(1..no_of_teams).each { |i|'
| Consistency in accessing collection members.
|-
|}

=AssignmentTeam Model: assignment_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_first_member
| Renamed to get_first_participant
| Enforce consistency in how we refer to users in a team.
|-
| includes?
| Renamed to has_participant
| Enforce consistency in how we refer to users in a team.
|-
| get_participants
| Renamed to participants
| Enforce consistency in how we name Ruby functions.
|-
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| remove_team_by_id
| Renamed to delete
| Enforce consistency in how we name Ruby functions.
|-
| reviewed_contributor?
| Changed logic from '(...) == false' to '!(...)'
| Legibility.
|-
| get_hyperlinks
| Renamed team_member local variable to 'participant'
| Enforce consistency in how we refer to users in a team.
|-
|}

=CourseTeam Model: course_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| copy_members
| Renamed to copy_participants
| Enforce consistency in how we refer to users in a team.
|-
|}

=Considerations for Future Work=
* The import/export functionality for different team participants could be combined and simplified. This responsibility could probably be broken out into separate classes so that this responsiblity is encapsulated better.
* Rather than extending the Team class to create separate classes to capture related functionality when teams are associated with assignments or courses, it might be better to just associate teams with courses or assignments directly and then delegate related functionality (like importing/exporting data) to separate helper classes.

=Conclusion=
* The renaming and refactoring was performed as suggested in the given requirements. These changes helped enforce consistency and common conventions.
* Some common functionality was combined to adhere to the DRY principle.
* Methods were grouped and organized within their model classes to make them easier to read and mentally consume, and to suggest groups of responsibilities for potential future work.

=References=

<references/>

=See Also=

* OSS - E1452 project on GitHub https://github.com/sjames3/expertiza
* Expertiza project documentation can be found at http://wikis.lib.ncsu.edu/index.php/Expertiza
* The working Expertiza site is accessible at link http://expertiza.ncsu.edu/
* Expertiza on GitHub https://github.com/expertiza/expertiza

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:55:43Z

Sjames3: /* Conclusion */

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* assignment_team.rb
* course_team.rb
* team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself") principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
This project took a two-stage approach. The first stage involved renaming methods and variables, but largely avoiding invasive code changes that could have an impact on the functionality. The second stage separately made changes like merging or removing duplicate functions.

Several main goals were kept in mind throughout this process:
# DRY
# Ruby naming conventions
# Project style conventions
# Good design cosiderations, such as high cohesion and low coupling.

=UML Class Diagram=
[[File:Writing 2 UML.png]]
=Team Model: team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_participants
| Removed more complex version of two duplicate functions.
| Adherence to the DRY principle.
|-
| add_member
| Renamed to 'add_participant'
| Enforce consistency in how we refer to users in a team.
|-
| copy_members
| Renamed to 'copy_participants'
| Enforce consistency in how we refer to users in a team.
|-
| delete_all_by_parent
| Changed logic from 'for team in teams ... end' to 'teams.each { |team| ... }'
| Consistency in accessing collection members.
|-
| delete_all_by_parent
| Changed logic from 'for i in 1..no_of_teams' to '(1..no_of_teams).each { |i|'
| Consistency in accessing collection members.
|-
|}

=AssignmentTeam Model: assignment_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_first_member
| Renamed to get_first_participant
| Enforce consistency in how we refer to users in a team.
|-
| includes?
| Renamed to has_participant
| Enforce consistency in how we refer to users in a team.
|-
| get_participants
| Renamed to participants
| Enforce consistency in how we name Ruby functions.
|-
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| remove_team_by_id
| Renamed to delete
| Enforce consistency in how we name Ruby functions.
|-
| reviewed_contributor?
| Changed logic from '(...) == false' to '!(...)'
| Legibility.
|-
| get_hyperlinks
| Renamed team_member local variable to 'participant'
| Enforce consistency in how we refer to users in a team.
|-
|}

=CourseTeam Model: course_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| copy_members
| Renamed to copy_participants
| Enforce consistency in how we refer to users in a team.
|-
|}

=Considerations for Future Work=
* The import/export functionality for different team participants could be combined and simplified. This responsibility could probably be broken out into separate classes so that this responsiblity is encapsulated better.
* Rather than extending the Team class to create separate classes to capture related functionality when teams are associated with assignments or courses, it might be better to just associate teams with courses or assignments directly and then delegate related functionality (like importing/exporting data) to separate helper classes.

=Conclusion=
* The renaming and refactoring was performed as suggested in the given requirements. These changes helped enforce consistency and common conventions.
* Some common functionality was combined to adhere to the DRY principle.
* Methods were grouped and organized within their model classes to make them easier to read and mentally consume, and to suggest groups of responsibilities for potential future work.

=References=
=See Also=

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:53:13Z

Sjames3: /* Considerations for Future Work */

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* assignment_team.rb
* course_team.rb
* team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself") principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
This project took a two-stage approach. The first stage involved renaming methods and variables, but largely avoiding invasive code changes that could have an impact on the functionality. The second stage separately made changes like merging or removing duplicate functions.

Several main goals were kept in mind throughout this process:
# DRY
# Ruby naming conventions
# Project style conventions
# Good design cosiderations, such as high cohesion and low coupling.

=UML Class Diagram=
[[File:Writing 2 UML.png]]
=Team Model: team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_participants
| Removed more complex version of two duplicate functions.
| Adherence to the DRY principle.
|-
| add_member
| Renamed to 'add_participant'
| Enforce consistency in how we refer to users in a team.
|-
| copy_members
| Renamed to 'copy_participants'
| Enforce consistency in how we refer to users in a team.
|-
| delete_all_by_parent
| Changed logic from 'for team in teams ... end' to 'teams.each { |team| ... }'
| Consistency in accessing collection members.
|-
| delete_all_by_parent
| Changed logic from 'for i in 1..no_of_teams' to '(1..no_of_teams).each { |i|'
| Consistency in accessing collection members.
|-
|}

=AssignmentTeam Model: assignment_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_first_member
| Renamed to get_first_participant
| Enforce consistency in how we refer to users in a team.
|-
| includes?
| Renamed to has_participant
| Enforce consistency in how we refer to users in a team.
|-
| get_participants
| Renamed to participants
| Enforce consistency in how we name Ruby functions.
|-
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| remove_team_by_id
| Renamed to delete
| Enforce consistency in how we name Ruby functions.
|-
| reviewed_contributor?
| Changed logic from '(...) == false' to '!(...)'
| Legibility.
|-
| get_hyperlinks
| Renamed team_member local variable to 'participant'
| Enforce consistency in how we refer to users in a team.
|-
|}

=CourseTeam Model: course_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| copy_members
| Renamed to copy_participants
| Enforce consistency in how we refer to users in a team.
|-
|}

=Considerations for Future Work=
* The import/export functionality for different team participants could be combined and simplified. This responsibility could probably be broken out into separate classes so that this responsiblity is encapsulated better.
* Rather than extending the Team class to create separate classes to capture related functionality when teams are associated with assignments or courses, it might be better to just associate teams with courses or assignments directly and then delegate related functionality (like importing/exporting data) to separate helper classes.

=Conclusion=
=References=
=See Also=

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:49:36Z

Sjames3:

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* assignment_team.rb
* course_team.rb
* team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself") principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
This project took a two-stage approach. The first stage involved renaming methods and variables, but largely avoiding invasive code changes that could have an impact on the functionality. The second stage separately made changes like merging or removing duplicate functions.

Several main goals were kept in mind throughout this process:
# DRY
# Ruby naming conventions
# Project style conventions
# Good design cosiderations, such as high cohesion and low coupling.

=UML Class Diagram=
[[File:Writing 2 UML.png]]
=Team Model: team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_participants
| Removed more complex version of two duplicate functions.
| Adherence to the DRY principle.
|-
| add_member
| Renamed to 'add_participant'
| Enforce consistency in how we refer to users in a team.
|-
| copy_members
| Renamed to 'copy_participants'
| Enforce consistency in how we refer to users in a team.
|-
| delete_all_by_parent
| Changed logic from 'for team in teams ... end' to 'teams.each { |team| ... }'
| Consistency in accessing collection members.
|-
| delete_all_by_parent
| Changed logic from 'for i in 1..no_of_teams' to '(1..no_of_teams).each { |i|'
| Consistency in accessing collection members.
|-
|}

=AssignmentTeam Model: assignment_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| get_first_member
| Renamed to get_first_participant
| Enforce consistency in how we refer to users in a team.
|-
| includes?
| Renamed to has_participant
| Enforce consistency in how we refer to users in a team.
|-
| get_participants
| Renamed to participants
| Enforce consistency in how we name Ruby functions.
|-
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| remove_team_by_id
| Renamed to delete
| Enforce consistency in how we name Ruby functions.
|-
| reviewed_contributor?
| Changed logic from '(...) == false' to '!(...)'
| Legibility.
|-
| get_hyperlinks
| Renamed team_member local variable to 'participant'
| Enforce consistency in how we refer to users in a team.
|-
|}

=CourseTeam Model: course_team.rb=
{| class="wikitable"
|-
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
| create_team_and_node
| Renamed to create
| Enforce consistency in how we name Ruby functions.
|-
| copy_members
| Renamed to copy_participants
| Enforce consistency in how we refer to users in a team.
|-
|}

=Considerations for Future Work=

=Conclusion=
=References=
=See Also=

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:43:35Z

Sjames3: /* CourseTeam Model: course_team.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:42:26Z

Sjames3: /* AssignmentTeam Model: AssignmentTeam.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:38:32Z

Sjames3: /* CourseTeam Model: CourseTeam.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:36:36Z

Sjames3: /* AssignmentTeam Model: AssignmentTeam.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T16:36:03Z

Sjames3: /* AssignmentTeam Model: AssignmentTeam.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:57:33Z

Sjames3: /* Scope for future work */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:57:20Z

Sjames3: /* AssignmentTeam Model: AssignmentTeam.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:57:15Z

Sjames3: /* CourseTeam Model: CourseTeam.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:57:01Z

Sjames3: /* Team Model: Team.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:56:32Z

Sjames3: /* Team Model: Team.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:55:30Z

Sjames3: /* Project Design and Approach */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:23:20Z

Sjames3: /* Project Design and Approach */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:09:20Z

Sjames3:

File:Writing 2 UML.png

2014-10-31T02:08:54Z

Sjames3:

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T02:02:35Z

Sjames3:

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T01:59:16Z

Sjames3: /* Introduction */

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* AssignmentTeam.rb
* CourseTeam.rb
* Team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself") principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names. Some preliminary suggestions were run past the point of contact for this section of the codebase. They are summarized as follows:

* The 'participants' and 'get_participants' methods in AssignmentTeam appear to have the same functionality, so these should be refactored into a single method.
* The 'create_team_and_node' method will be renamed to 'create' to better follow accepted Ruby conventions.
** A few other methods that could also be named better. For example, 'remove_team_by_id(id)' could be 'delete(id)'.
* The 'includes?' method will be renamed to 'has_participant?'
* There are some common responsibilities in both AssignmentTeam and CourseTeam, so that code will be pushed up into the superclass Team.

=Project Design and Approach=
=UML Class Diagram=
=Team Model: Team.rb=
=AssignmentTeam Model: AssignmentTeam.rb=

=CourseTeam Model: CourseTeam.rb=
=Scope for future work=
=Conclusion=
=References=
=See Also=

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T01:56:18Z

Sjames3: /* Introduction */

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
* AssignmentTeam.rb
* CourseTeam.rb
* Team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
The AssignmentTeam and CourseTeam models, as sibling subclasses of the Team model, tended to share certain functionality. This assignment called for refactoring those classes to make them better conform to ruby convention and to support the DRY ("Don't Repeat Yourself") principle of avoiding duplicate code.

A quick skim of the code turned up a few places where the AssignmentTeam and CourseTeam models had similar functionality, as well as multiple methods and variables that needed better names.

=Project Design and Approach=
=UML Class Diagram=
=Team Model: Team.rb=
=AssignmentTeam Model: AssignmentTeam.rb=

=CourseTeam Model: CourseTeam.rb=
=Scope for future work=
=Conclusion=
=References=
=See Also=

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T00:13:52Z

Sjames3: /* Team Model: Team.rb */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T00:13:38Z

Sjames3: /* E1452: Refactoring AssignmentTeam and CourseTeam models */

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T00:13:16Z

Sjames3:

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows:

'''Classes:'''
AssignmentTeam.rb
CourseTeam.rb
Team.rb

'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.

'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

__TOC__

=Introduction=
=Project Design and Approach=
=UML Class Diagram=
=Team Model: Team.rb=
=AssignmentTeam Model: AssignmentTeam.rb
=CourseTeam Model: CourseTeam.rb=
=Scope for future work=
=Conclusion=
=References=
=See Also=

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T00:10:49Z

Sjames3:

CSC/ECE 517 Fall 2014/OSS E1452 slj

2014-10-31T00:09:39Z

Sjames3: Created page with "=E1452: Refactoring AssignmentTeam and CourseTeam models= The requirements provided for the Open Source System project of Expertiza were as follows : '''Classes:''' AssignmentTe..."

=E1452: Refactoring AssignmentTeam and CourseTeam models=
The requirements provided for the Open Source System project of Expertiza were as follows :
'''Classes:'''
AssignmentTeam.rb
CourseTeam.rb
Team.rb
'''What they do:'''
The AssignmentTeam model checks whether a team has participants for an assignment, whether a topic has been picked by the team and reviews has be given for a particular team and adds, deletes and retrieves participants in a team.
The CourseTeam model gives the paticipants in a course and allows to add and delete participants in a course. This is for the use by the instructor.
'''What is needed:'''
Check if we need two methods participant and get_participant as they may be similar. If so, refactor to make one method.
Rename create_team_and_node method as create method (follow Ruby style)
Rename includes? method to has_participant?
Remove duplicate code from these 2 sublcasses of Team.
Assignment_Team class too long (235 lines)

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:35:07Z

Sjames3: /* Examples of Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-paste the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make an egregious mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort of class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
Almost all major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.</ref>

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:33:56Z

Sjames3: /* How to Use Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-paste the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make an egregious mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort of class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.</ref>

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:33:22Z

Sjames3: /* Why should refactoring browsers be used? */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-paste the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make an egregious mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.</ref>

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:33:09Z

Sjames3: /* Why should refactoring browsers be used? */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-paste the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make an ergregious mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.</ref>

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:32:13Z

Sjames3: /* A Brief History */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-paste the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.</ref>

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:31:21Z

Sjames3: /* What are refactoring browsers? */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-paste the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.</ref>

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:31:04Z

Sjames3: /* Examples of Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.</ref>

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:30:50Z

Sjames3: /* Examples of Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans<ref>[https://ui.netbeans.org/docs/ui/code_navigator/Navigator%20spec.html "Code Navigator"], ''Netbeans.org''. 14 January 2005. Accessed 6 October 2014.

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:28:31Z

Sjames3: /* Examples of Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse"/>
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.</ref>
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans
* Red Gate .NET Reflector
* Squeak Smalltalk
* Step Ahead Javelin [1]
* Visual Prolog

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:28:04Z

Sjames3:

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref name="Eclipse">[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk<ref name="Smalltalk"/>
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse<ref name="Eclipse">
* Embarcadero Delphi<ref>[http://www.modelmakertools.com/code-explorer/index.html "ModelMaker Code Explorer"], ''ModelMaker Tools''. 2014. Accessed 6 October 2014.</ref>
* Embarcadero JBuilder
* IBM WebSphere<ref>[http://www.tlcc.com/admin/tips.nsf/0/C9408FEF495D6AD985256E40005172AA "Refactor your Java Code in WebSphere Studio"], ''The Learning Continuum Company''. 23 February 2004. Accessed 6 October 2014.</ref>
* IntelliJ IDEA<ref>[http://www.jetbrains.com/idea/webhelp/refactoring-source-code.html "Refactoring Source Code"], ''IntelliJ IDEA 13.1.0 Web Help''. 4 July 2014. Accessed 6 October 2014.
* KDevelop<ref>[http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/ "KDevelop4: Now with refactoring!"], ''Zwabel’s Weblog''. 5 November 2008. Accessed 6 October 2014.</ref>
* Microsoft Visual Studio<ref>[http://msdn.microsoft.com/en-us/library/whks02wf.aspx#BKMK_ObjectBrowser "Viewing the Structure of Code"], ''Microsoft Developer Network''. 2014. Accessed 6 October 2014.</ref>
* NetBeans
* Red Gate .NET Reflector
* Squeak Smalltalk
* Step Ahead Javelin [1]
* Visual Prolog

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:07:41Z

Sjames3: /* Examples of Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref>[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.</ref>
* Cincom Smalltalk
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse
* Embarcadero Delphi
* Embarcadero JBuilder
* IBM WebSphere
* IntelliJ IDEA
* KDevelop
* Microsoft Visual Studio
* NetBeans
* Red Gate .NET Reflector
* Squeak Smalltalk
* Step Ahead Javelin [1]
* Visual Prolog

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:07:31Z

Sjames3: /* Examples of Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref>[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X<ref>[http://blog.ittybittyapps.com/blog/2013/09/24/refactoring-in-xcode-5/ "Refactoring in Xcode 5"], ''Itty Bitty Labs''. 24 September 2013. Accessed 6 October 2014.
* Cincom Smalltalk
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse
* Embarcadero Delphi
* Embarcadero JBuilder
* IBM WebSphere
* IntelliJ IDEA
* KDevelop
* Microsoft Visual Studio
* NetBeans
* Red Gate .NET Reflector
* Squeak Smalltalk
* Step Ahead Javelin [1]
* Visual Prolog

==References==
<references/>

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:05:16Z

Sjames3: /* A Brief History */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A side-by-side comparison of a Smalltalk refactoring browser<ref>[http://onsmalltalk.com/on-the-smalltalk-browser "On the Smalltalk Browser"], ''On Smalltalk''. 17 June 2007. Accessed 6 October 2014.</ref> and the modern Eclipse Java 'browsing perspective'<ref>[http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2FgettingStarted%2Fqs-Browsing.htm "Using the Java Browsing Perspective"], ''Eclipse documentation - Current Release''. Accessed 6 October 2014.</ref>.]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X
* Cincom Smalltalk
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse
* Embarcadero Delphi
* Embarcadero JBuilder
* IBM WebSphere
* IntelliJ IDEA
* KDevelop
* Microsoft Visual Studio
* NetBeans
* Red Gate .NET Reflector
* Squeak Smalltalk
* Step Ahead Javelin [1]
* Visual Prolog

==References==
<references/>

File:Netbeans refactoring browser.png

2014-10-07T02:01:11Z

Sjames3: uploaded a new version of "File:Netbeans refactoring browser.png"

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T02:00:12Z

Sjames3: /* How to Use Refactoring Browsers */

==Refactoring Browsers in Popular IDEs==

===What are refactoring browsers?===
Have you ever extracted a method by hand? To do so, you might pick out the code you want to extract into a separate method, type out a method declaration for it, copy-pastie the code, and tweak the parameters to get everything just right. What about renaming a method by hand, or copy-pasting a method or variable from one class to another?

Refactoring browsers greatly simplify the work of these and many other common types of refactoring operations by providing a graphical interface that programmers can interact with directly to perform these actions. Usually, this interface takes the form of a class browser, which lists out the members and methods of different classes.

[[File:Netbeans_refactoring_browser.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

====A Brief History====
If we trace recognizable versions of refactoring browsers back far enough, we eventually end up with Smalltalk in the early 70's. Smalltalk is one of the earliest object oriented languages and development environments, and it provided a graphical interface that could be used to browse and refactor Smalltalk code. This idea of using a graphical interface to interact with a class hierarchy quickly caught on, and it persisted through the C++ era in the late 80's and into the introduction of Java in the mid 90's. Now all major IDEs are expected to have at least some sort of graphical class browser, usually with at least rudimentary refactoring capabilites (renaming, etc.)<ref name="Class browser">[http://en.wikipedia.org/wiki/Class_browser "Class browser"], ''Wikipedia''. 3 April 2014. Retrieved 6 October 2014.</ref><ref name="IDE">[http://en.wikipedia.org/wiki/Integrated_development_environment "Integrated development environment"], ''Wikipedia''. 2 September 2014. Retrieved 6 October 2014.</ref>.

[[File:Smalltalk eclipse.png|frame|alt=A refactoring browser in a modern IDE.|A refactoring browser in a modern IDE (Netbeans).]]

===Why should refactoring browsers be used?===
Refactoring browsers should be used for several reasons:
# They are faster and easier to use than keyboard-initiated refactoring operations.
# They are safe - unless you make a mistake like moving a method to the wrong class, you are nearly guaranteed not to change the behavior of your program.<ref name="Smalltalk">[http://c2.com/cgi/wiki?RefactoringBrowser "Refactoring Browser"], ''Cunningham & Cunningham, Inc.''. 10 April 2012. Retrieved 6 October 2014.</ref>
# They allow you to bravely perform various logic organizing experiments, undoing those whose results aren't satisfactory.<ref name="Smalltalk"/>

==How to Use Refactoring Browsers==
Because the whole idea behind refactoring browsers is to make refactoring easier and more intuitive, most modern IDEs will make it easy to perform refactoring using some sort f class browser. Although different applications may have different supported operations, most refactoring browsers should allow you to:
# Click and drag to move classes from package to package, or class members and methods from class to class.
# Rename a package, file, method, or member by right-clicking it and selecting the appropriate 'rename' menu item.

==Glossary==
; [http://en.wikipedia.org/wiki/Class_browser Class browser]
: A class browser is a feature of an integrated development environment (IDE) that allows the programmer to browse, navigate, or visualize the structure of object-oriented programming code.
; [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]
: An IDE, or integrated development environment, is a software application that provides extensive functionality to simplify the process of software creation and modification.
; Refactoring browser
: A refactoring browser allows the programmer to use a graphical interface (usually some form of a class browser) to manipulate, combine, and separate code elements.
; [http://en.wikipedia.org/wiki/Smalltalk Smalltalk]
: One of the earliest object oriented languages. Also a development environment that is regarded as a well-known ancestor of modern class and refactoring browsers.

==Examples of Refactoring Browsers==
All major development environments supply some manner of class browser, including:<ref name="Class browser"/>

* Apple Xcode for Mac OS X
* Cincom Smalltalk
* CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
* Eclipse
* Embarcadero Delphi
* Embarcadero JBuilder
* IBM WebSphere
* IntelliJ IDEA
* KDevelop
* Microsoft Visual Studio
* NetBeans
* Red Gate .NET Reflector
* Squeak Smalltalk
* Step Ahead Javelin [1]
* Visual Prolog

==References==
<references/>

File:Smalltalk eclipse.png

2014-10-07T01:56:14Z

Sjames3: uploaded a new version of "File:Smalltalk eclipse.png"

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T01:55:10Z

Sjames3:

File:Smalltalk eclipse.png

2014-10-07T01:54:40Z

Sjames3:

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T01:44:03Z

Sjames3: /* Examples of Refactoring Browsers */

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T01:43:22Z

Sjames3: /* Glossary */

CSC/ECE 517 Fall 2014/ch1b 32 sj

2014-10-07T01:41:08Z

Sjames3: /* A Brief History */