Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w19 is

2012-10-26T22:50:38Z

Smbuch: /* Problems Solved by this pattern */

<big>'''Template Method Pattern'''</big>

__TOC__

==Introduction==
A template is a previously set format that other applications use as a starting point, instead of redefining the format each time<ref>http://www.oodesign.com/template-method-pattern.html</ref>. As you can imagine, [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] contains many such patterns in order to develop software and applications. One such pattern is the Template Method Pattern<ref>http://en.wikipedia.org/wiki/Template_method_pattern</ref>. The Template Method Pattern is a [http://en.wikipedia.org/wiki/Behavioral_pattern behavioral design pattern] that defines an algorithm skeleton in a base class, with abstract definitions that derived classes can override to provide concrete behavior. The skeleton is called the template method and the subclasses or derived classes implement the algorithm, sometimes with minor modifications.

In object-oriented design, the base class defines the template by stating the steps of the algorithm using abstract methods that its derived classes implement in a more concrete manner. In this manner, the template method pattern stores the algorithm in one place while other classes implement it, which is good object-oriented(OO) design. Also, the designer can decide which of the algorithm steps are to be standard and which of these are to be customizable<ref>http://sourcemaking.com/design_patterns/template_method</ref>. These standard steps are implemented concretely in the derived classes using the abstract base class's definitions and the customizable steps are either implemented in the derived classes, or not at all. These customizable steps serve as placeholders, or ''hooks''<ref>http://en.wikipedia.org/wiki/Hook_method#Hook_methods</ref>, that the derived classes can supply or not, as they choose. So basically it is used when programmers want to fix the order of operations used in a method, but allow some amount of flexibility such that the subclasses can implement some of these operations in their own manner<ref>http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf</ref>.

The template method pattern thus, is fundamentally a code reuse technique. It is used whenever programmers want to localize common behavior in subclasses and place it in a super class to avoid code duplication. Hence it is an example of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring].

==Problems Solved by this pattern==
Template Method pattern is a type of a behavioral design pattern which defines a skeleton for an algorithm which cannot be implemented in that class due to calls to methods that are abstract but can be implemented in the child classes. The template method cannot be overridden in the child classes as it is defined as a final method in the parent class.

Suppose we have a portal where we allow users to book tickets to travel from source to destination. The problem we face here is that, we want all users to use a standard way of booking tickets and travelling. They could travel by bus, train or flight but we want them to follow a certain number of steps in the same order before they can see the confirmation page. We do not want one user to pay first and then select a date and time and a flight and the other user to do this the other way round. However, the mode of transport for the travel may be different for every user and the source and destination may also be different for each of them.

This is the ideal situation in which we would use the Template Method pattern. The parent class will have a template method defined with an algorithm skeleton that says that the steps to be followed will be select the mode of transport, then select the source, then destination and then the date of travel and finally mode of payment.

However, the methods defining the selection of these functionalities can be implemented in different ways depending on what the subclass is. These methods in the parent class are kept abstract but the template method in the parent is made final. The template method calls the functions in a certain order.

Let us show this with a concrete code.

:public class Portal
::{
:::public final void TicketBooking()
:::{
TransportMode();
if(int i < 4)
SourceAndDate();
else
DestinationAndDate();
Payment();
}

:abstract public MethodA();
:abstract public MethodB();
:abstract public MethodC();
}

public class Feedback_response extends Response
{
TransportMode() {
//some definition
}

SourceAndDate() {
//some definition
}

DestinationAndDate() {
//some definition
}

Payment() {
//some definition
}
}

Each of the sub classes inheriting from this class can then provide a concrete definition to these abstract methods in a way they but the method template is final and must be used in the same way.

==Structure and Protocol==

==Roles and Responsibilities==

==Benefits and Liabilities==

==Comparison with other design patterns==
===Comparison with Adapter Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Adapter Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural patterns, the focus is on relationships between objects and how they together form larger components whereas in Behavioral patterns, the focus is on communication between objects and what each object does <ref name='StructuralBehavioral'>Design Patterns: Structural and Behavioral http://twu.seanho.com/09spr/cmpt166/lectures/35-patterns.pdf </ref>
|-
! Purpose of Use
! Enables the use of two or more unrelated interfaces, together, as one unit. This can be done by converting one (or more) of the interfaces to adapt to the type of interface that is required by the client. thus, adapter pattern acts as a Wrapper, thus, also called, Wrapper Pattern. <ref name=''>JAVA DESIGN PATTERNS http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm </ref>
! This pattern is used to define and maintain an algorithm directed towards how you want the flow of execution to be. This template method is defined in the parent class and made final, so that all children have to follow the same flow.
! Purpose of Structural pattern is to act as a wrapper to make different interfaces ready for the client interface as against that of a Behavioral pattern is to define a common algorithm defining method as final in the parents class to act as a template for all the child classes to decide the flow of control.
|-
! Example
! public class SquarePeg {
public void insert(String str) {
System.out.println("SquarePeg insert(): " + str);
}
}

public class RoundPeg {
public void insertIntoHole(String msg) {
System.out.println("RoundPeg insertIntoHole(): " + msg);
}
}

public class PegAdapter extends SquarePeg {
private RoundPeg roundPeg;
public PegAdapter(RoundPeg peg) {this.roundPeg = peg;}
public void insert(String str) {roundPeg.insertIntoHole(str);}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Strategy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Behavioral Pattern
! Behavioral Pattern
! In Behavioral patterns, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow fo control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control.
|-
! Example
! interface myInterface {
int findSum(int x, inty, int z);
}

class A implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}

class B implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Proxy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural pattern, the focus is on creating ease of design by identifying a simple way to realize relationships between entities. In Behavioral patterns, on the other hand, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow of control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control. Purpose of the Proxy pattern is use a less complex object in place of the actual object until such a time that the actual object can be created. The less complex object is known as the proxy for the actual object.
|-
! Example
! inteface myInterface {
public abstract void display();
}

class classA implements myInterface {

private void loadImage() {
System.out.println("Loading in classA");
}

public void display() {
system.out.println("Displaying in classA");
}
}

class classB implements myInterface {

private void loadProxyImage(final Sting FILENAME) {
filename = FILENAME;
}

public void display() {
if(image == null) {
image = new classA(filename);
}

image.display();
}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

==Conclusion==
Behavioral design patterns, generally identify the communication between different objects and classes and how this can be made most efficiently. The behavioral design pattern, Template Method pattern, is one of the most important patterns in certain situations like in cases where we need a static algorithm defined for some purpose. Whenever we do not want the child classes to make a decision about the flow of the algorithm or we do not want the child class interfering with the parents decision, it would be ideal to use this design pattern. It also gives you a very easy way to maintain your code and make changes to it in the future as everything needs to be done only in one place. In conclusion, Template Method pattern can be explained as easily as defining a skeleton of an algorithm in an operation, deferring some steps to sub classes.

==References==

<references/>

CSC/ECE 517 Fall 2012/ch2a 2w19 is

2012-10-26T22:49:19Z

Smbuch: /* Problems Solved by this pattern */

<big>'''Template Method Pattern'''</big>

__TOC__

==Introduction==
A template is a previously set format that other applications use as a starting point, instead of redefining the format each time<ref>http://www.oodesign.com/template-method-pattern.html</ref>. As you can imagine, [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] contains many such patterns in order to develop software and applications. One such pattern is the Template Method Pattern<ref>http://en.wikipedia.org/wiki/Template_method_pattern</ref>. The Template Method Pattern is a [http://en.wikipedia.org/wiki/Behavioral_pattern behavioral design pattern] that defines an algorithm skeleton in a base class, with abstract definitions that derived classes can override to provide concrete behavior. The skeleton is called the template method and the subclasses or derived classes implement the algorithm, sometimes with minor modifications.

In object-oriented design, the base class defines the template by stating the steps of the algorithm using abstract methods that its derived classes implement in a more concrete manner. In this manner, the template method pattern stores the algorithm in one place while other classes implement it, which is good object-oriented(OO) design. Also, the designer can decide which of the algorithm steps are to be standard and which of these are to be customizable<ref>http://sourcemaking.com/design_patterns/template_method</ref>. These standard steps are implemented concretely in the derived classes using the abstract base class's definitions and the customizable steps are either implemented in the derived classes, or not at all. These customizable steps serve as placeholders, or ''hooks''<ref>http://en.wikipedia.org/wiki/Hook_method#Hook_methods</ref>, that the derived classes can supply or not, as they choose. So basically it is used when programmers want to fix the order of operations used in a method, but allow some amount of flexibility such that the subclasses can implement some of these operations in their own manner<ref>http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf</ref>.

The template method pattern thus, is fundamentally a code reuse technique. It is used whenever programmers want to localize common behavior in subclasses and place it in a super class to avoid code duplication. Hence it is an example of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring].

==Problems Solved by this pattern==
Template Method pattern is a type of a behavioral design pattern which defines a skeleton for an algorithm which cannot be implemented in that class due to calls to methods that are abstract but can be implemented in the child classes. The template method cannot be overridden in the child classes as it is defined as a final method in the parent class.

Suppose we have a portal where we allow users to book tickets to travel from source to destination. The problem we face here is that, we want all users to use a standard way of booking tickets and travelling. They could travel by bus, train or flight but we want them to follow a certain number of steps in the same order before they can see the confirmation page. We do not want one user to pay first and then select a date and time and a flight and the other user to do this the other way round. However, the mode of transport for the travel may be different for every user and the source and destination may also be different for each of them.

This is the ideal situation in which we would use the Template Method pattern. The parent class will have a template method defined with an algorithm skeleton that says that the steps to be followed will be select the mode of transport, then select the source, then destination and then the date of travel and finally mode of payment.

However, the methods defining the selection of these functionalities can be implemented in different ways depending on what the subclass is. These methods in the parent class are kept abstract but the template method in the parent is made final. The template method calls the functions in a certain order.

Let us show this with a concrete code.

:public class Portal
::{
:::public final void TicketBooking()
:::{
TransportMode();
if(int i < 4)
SourceAndDate();
else
DestinationAndDate();
Payment();
}

:abstract public MethodA();
:abstract public MethodB();
:abstract public MethodC();
}

public class Feedback_response extends Response
{
TransportMode() {
//some definition
}

SourceAndDate() {
//some definition
}

DestinationAndDate() {
//some definition
}

Payment() {
//some definition
}
}

==Structure and Protocol==

==Roles and Responsibilities==

==Benefits and Liabilities==

==Comparison with other design patterns==
===Comparison with Adapter Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Adapter Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural patterns, the focus is on relationships between objects and how they together form larger components whereas in Behavioral patterns, the focus is on communication between objects and what each object does <ref name='StructuralBehavioral'>Design Patterns: Structural and Behavioral http://twu.seanho.com/09spr/cmpt166/lectures/35-patterns.pdf </ref>
|-
! Purpose of Use
! Enables the use of two or more unrelated interfaces, together, as one unit. This can be done by converting one (or more) of the interfaces to adapt to the type of interface that is required by the client. thus, adapter pattern acts as a Wrapper, thus, also called, Wrapper Pattern. <ref name=''>JAVA DESIGN PATTERNS http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm </ref>
! This pattern is used to define and maintain an algorithm directed towards how you want the flow of execution to be. This template method is defined in the parent class and made final, so that all children have to follow the same flow.
! Purpose of Structural pattern is to act as a wrapper to make different interfaces ready for the client interface as against that of a Behavioral pattern is to define a common algorithm defining method as final in the parents class to act as a template for all the child classes to decide the flow of control.
|-
! Example
! public class SquarePeg {
public void insert(String str) {
System.out.println("SquarePeg insert(): " + str);
}
}

public class RoundPeg {
public void insertIntoHole(String msg) {
System.out.println("RoundPeg insertIntoHole(): " + msg);
}
}

public class PegAdapter extends SquarePeg {
private RoundPeg roundPeg;
public PegAdapter(RoundPeg peg) {this.roundPeg = peg;}
public void insert(String str) {roundPeg.insertIntoHole(str);}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Strategy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Behavioral Pattern
! Behavioral Pattern
! In Behavioral patterns, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow fo control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control.
|-
! Example
! interface myInterface {
int findSum(int x, inty, int z);
}

class A implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}

class B implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Proxy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural pattern, the focus is on creating ease of design by identifying a simple way to realize relationships between entities. In Behavioral patterns, on the other hand, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow of control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control. Purpose of the Proxy pattern is use a less complex object in place of the actual object until such a time that the actual object can be created. The less complex object is known as the proxy for the actual object.
|-
! Example
! inteface myInterface {
public abstract void display();
}

class classA implements myInterface {

private void loadImage() {
System.out.println("Loading in classA");
}

public void display() {
system.out.println("Displaying in classA");
}
}

class classB implements myInterface {

private void loadProxyImage(final Sting FILENAME) {
filename = FILENAME;
}

public void display() {
if(image == null) {
image = new classA(filename);
}

image.display();
}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

==Conclusion==
Behavioral design patterns, generally identify the communication between different objects and classes and how this can be made most efficiently. The behavioral design pattern, Template Method pattern, is one of the most important patterns in certain situations like in cases where we need a static algorithm defined for some purpose. Whenever we do not want the child classes to make a decision about the flow of the algorithm or we do not want the child class interfering with the parents decision, it would be ideal to use this design pattern. It also gives you a very easy way to maintain your code and make changes to it in the future as everything needs to be done only in one place. In conclusion, Template Method pattern can be explained as easily as defining a skeleton of an algorithm in an operation, deferring some steps to sub classes.

==References==

<references/>

CSC/ECE 517 Fall 2012/ch2a 2w19 is

2012-10-26T22:47:31Z

Smbuch: /* Problems Solved by this pattern */

<big>'''Template Method Pattern'''</big>

__TOC__

==Introduction==
A template is a previously set format that other applications use as a starting point, instead of redefining the format each time<ref>http://www.oodesign.com/template-method-pattern.html</ref>. As you can imagine, [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] contains many such patterns in order to develop software and applications. One such pattern is the Template Method Pattern<ref>http://en.wikipedia.org/wiki/Template_method_pattern</ref>. The Template Method Pattern is a [http://en.wikipedia.org/wiki/Behavioral_pattern behavioral design pattern] that defines an algorithm skeleton in a base class, with abstract definitions that derived classes can override to provide concrete behavior. The skeleton is called the template method and the subclasses or derived classes implement the algorithm, sometimes with minor modifications.

In object-oriented design, the base class defines the template by stating the steps of the algorithm using abstract methods that its derived classes implement in a more concrete manner. In this manner, the template method pattern stores the algorithm in one place while other classes implement it, which is good object-oriented(OO) design. Also, the designer can decide which of the algorithm steps are to be standard and which of these are to be customizable<ref>http://sourcemaking.com/design_patterns/template_method</ref>. These standard steps are implemented concretely in the derived classes using the abstract base class's definitions and the customizable steps are either implemented in the derived classes, or not at all. These customizable steps serve as placeholders, or ''hooks''<ref>http://en.wikipedia.org/wiki/Hook_method#Hook_methods</ref>, that the derived classes can supply or not, as they choose. So basically it is used when programmers want to fix the order of operations used in a method, but allow some amount of flexibility such that the subclasses can implement some of these operations in their own manner<ref>http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf</ref>.

The template method pattern thus, is fundamentally a code reuse technique. It is used whenever programmers want to localize common behavior in subclasses and place it in a super class to avoid code duplication. Hence it is an example of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring].

==Problems Solved by this pattern==
Template Method pattern is a type of a behavioral design pattern which defines a skeleton for an algorithm which cannot be implemented in that class due to calls to methods that are abstract but can be implemented in the child classes. The template method cannot be overridden in the child classes as it is defined as a final method in the parent class.

Suppose we have a portal where we allow users to book tickets to travel from source to destination. The problem we face here is that, we want all users to use a standard way of booking tickets and travelling. They could travel by bus, train or flight but we want them to follow a certain number of steps in the same order before they can see the confirmation page. We do not want one user to pay first and then select a date and time and a flight and the other user to do this the other way round. However, the mode of transport for the travel may be different for every user and the source and destination may also be different for each of them.

This is the ideal situation in which we would use the Template Method pattern. The parent class will have a template method defined with an algorithm skeleton that says that the steps to be followed will be select the mode of transport, then select the source, then destination and then the date of travel and finally mode of payment.

However, the methods defining the selection of these functionalities can be implemented in different ways depending on what the subclass is. These methods in the parent class are kept abstract but the template method in the parent is made final. The template method calls the functions in a certain order.

Let us show this with a concrete code.

public class Portal {
public final void TicketBooking()
{
TransportMode();
if(int i < 4)
SourceAndDate();
else
DestinationAndDate();
Payment();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
TransportMode() {
//some definition
}

SourceAndDate() {
//some definition
}

DestinationAndDate() {
//some definition
}

Payment() {
//some definition
}
}

==Structure and Protocol==

==Roles and Responsibilities==

==Benefits and Liabilities==

==Comparison with other design patterns==
===Comparison with Adapter Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Adapter Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural patterns, the focus is on relationships between objects and how they together form larger components whereas in Behavioral patterns, the focus is on communication between objects and what each object does <ref name='StructuralBehavioral'>Design Patterns: Structural and Behavioral http://twu.seanho.com/09spr/cmpt166/lectures/35-patterns.pdf </ref>
|-
! Purpose of Use
! Enables the use of two or more unrelated interfaces, together, as one unit. This can be done by converting one (or more) of the interfaces to adapt to the type of interface that is required by the client. thus, adapter pattern acts as a Wrapper, thus, also called, Wrapper Pattern. <ref name=''>JAVA DESIGN PATTERNS http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm </ref>
! This pattern is used to define and maintain an algorithm directed towards how you want the flow of execution to be. This template method is defined in the parent class and made final, so that all children have to follow the same flow.
! Purpose of Structural pattern is to act as a wrapper to make different interfaces ready for the client interface as against that of a Behavioral pattern is to define a common algorithm defining method as final in the parents class to act as a template for all the child classes to decide the flow of control.
|-
! Example
! public class SquarePeg {
public void insert(String str) {
System.out.println("SquarePeg insert(): " + str);
}
}

public class RoundPeg {
public void insertIntoHole(String msg) {
System.out.println("RoundPeg insertIntoHole(): " + msg);
}
}

public class PegAdapter extends SquarePeg {
private RoundPeg roundPeg;
public PegAdapter(RoundPeg peg) {this.roundPeg = peg;}
public void insert(String str) {roundPeg.insertIntoHole(str);}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Strategy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Behavioral Pattern
! Behavioral Pattern
! In Behavioral patterns, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow fo control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control.
|-
! Example
! interface myInterface {
int findSum(int x, inty, int z);
}

class A implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}

class B implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Proxy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural pattern, the focus is on creating ease of design by identifying a simple way to realize relationships between entities. In Behavioral patterns, on the other hand, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow of control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control. Purpose of the Proxy pattern is use a less complex object in place of the actual object until such a time that the actual object can be created. The less complex object is known as the proxy for the actual object.
|-
! Example
! inteface myInterface {
public abstract void display();
}

class classA implements myInterface {

private void loadImage() {
System.out.println("Loading in classA");
}

public void display() {
system.out.println("Displaying in classA");
}
}

class classB implements myInterface {

private void loadProxyImage(final Sting FILENAME) {
filename = FILENAME;
}

public void display() {
if(image == null) {
image = new classA(filename);
}

image.display();
}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

==Conclusion==
Behavioral design patterns, generally identify the communication between different objects and classes and how this can be made most efficiently. The behavioral design pattern, Template Method pattern, is one of the most important patterns in certain situations like in cases where we need a static algorithm defined for some purpose. Whenever we do not want the child classes to make a decision about the flow of the algorithm or we do not want the child class interfering with the parents decision, it would be ideal to use this design pattern. It also gives you a very easy way to maintain your code and make changes to it in the future as everything needs to be done only in one place. In conclusion, Template Method pattern can be explained as easily as defining a skeleton of an algorithm in an operation, deferring some steps to sub classes.

==References==

<references/>

CSC/ECE 517 Fall 2012/ch2a 2w19 is

2012-10-26T22:42:11Z

Smbuch: /* Problems Solved by this pattern */

<big>'''Template Method Pattern'''</big>

__TOC__

==Introduction==
A template is a previously set format that other applications use as a starting point, instead of redefining the format each time<ref>http://www.oodesign.com/template-method-pattern.html</ref>. As you can imagine, [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] contains many such patterns in order to develop software and applications. One such pattern is the Template Method Pattern<ref>http://en.wikipedia.org/wiki/Template_method_pattern</ref>. The Template Method Pattern is a [http://en.wikipedia.org/wiki/Behavioral_pattern behavioral design pattern] that defines an algorithm skeleton in a base class, with abstract definitions that derived classes can override to provide concrete behavior. The skeleton is called the template method and the subclasses or derived classes implement the algorithm, sometimes with minor modifications.

In object-oriented design, the base class defines the template by stating the steps of the algorithm using abstract methods that its derived classes implement in a more concrete manner. In this manner, the template method pattern stores the algorithm in one place while other classes implement it, which is good object-oriented(OO) design. Also, the designer can decide which of the algorithm steps are to be standard and which of these are to be customizable<ref>http://sourcemaking.com/design_patterns/template_method</ref>. These standard steps are implemented concretely in the derived classes using the abstract base class's definitions and the customizable steps are either implemented in the derived classes, or not at all. These customizable steps serve as placeholders, or ''hooks''<ref>http://en.wikipedia.org/wiki/Hook_method#Hook_methods</ref>, that the derived classes can supply or not, as they choose. So basically it is used when programmers want to fix the order of operations used in a method, but allow some amount of flexibility such that the subclasses can implement some of these operations in their own manner<ref>http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf</ref>.

The template method pattern thus, is fundamentally a code reuse technique. It is used whenever programmers want to localize common behavior in subclasses and place it in a super class to avoid code duplication. Hence it is an example of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring].

==Problems Solved by this pattern==
Template Method pattern is a type of a behavioral design pattern which defines a skeleton for an algorithm which cannot be implemented in that class due to calls to methods that are abstract but can be implemented in the child classes. The template method cannot be overridden in the child classes as it is defined as a final method in the parent class.

Suppose we have a portal where we allow users to book tickets to travel from source to destination. The problem we face here is that, we want all users to use a standard way of booking tickets and travelling. They could travel by bus, train or flight but we want them to follow a certain number of steps in the same order before they can see the confirmation page. We do not want one user to pay first and then select a date and time and a flight and the other user to do this the other way round. However, the mode of transport for the travel may be different for every user and the source and destination may also be different for each of them.

This is the ideal situation in which we would use the Template Method pattern. The parent class will have a template method defined with an algorithm skeleton that says that the steps to be followed will be select the mode of transport, then select the source, then destination and then the date of travel and finally mode of payment.

However, the methods defining the selection of these functionalities can be implemented in different ways depending on what the subclass is. These methods in the parent class are kept abstract but the template method in the parent is made final. The template method calls the functions in a certain order.

Let us show this with a concrete code.

==Structure and Protocol==

==Roles and Responsibilities==

==Benefits and Liabilities==

==Comparison with other design patterns==
===Comparison with Adapter Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Adapter Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural patterns, the focus is on relationships between objects and how they together form larger components whereas in Behavioral patterns, the focus is on communication between objects and what each object does <ref name='StructuralBehavioral'>Design Patterns: Structural and Behavioral http://twu.seanho.com/09spr/cmpt166/lectures/35-patterns.pdf </ref>
|-
! Purpose of Use
! Enables the use of two or more unrelated interfaces, together, as one unit. This can be done by converting one (or more) of the interfaces to adapt to the type of interface that is required by the client. thus, adapter pattern acts as a Wrapper, thus, also called, Wrapper Pattern. <ref name=''>JAVA DESIGN PATTERNS http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm </ref>
! This pattern is used to define and maintain an algorithm directed towards how you want the flow of execution to be. This template method is defined in the parent class and made final, so that all children have to follow the same flow.
! Purpose of Structural pattern is to act as a wrapper to make different interfaces ready for the client interface as against that of a Behavioral pattern is to define a common algorithm defining method as final in the parents class to act as a template for all the child classes to decide the flow of control.
|-
! Example
! public class SquarePeg {
public void insert(String str) {
System.out.println("SquarePeg insert(): " + str);
}
}

public class RoundPeg {
public void insertIntoHole(String msg) {
System.out.println("RoundPeg insertIntoHole(): " + msg);
}
}

public class PegAdapter extends SquarePeg {
private RoundPeg roundPeg;
public PegAdapter(RoundPeg peg) {this.roundPeg = peg;}
public void insert(String str) {roundPeg.insertIntoHole(str);}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Strategy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Behavioral Pattern
! Behavioral Pattern
! In Behavioral patterns, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow fo control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control.
|-
! Example
! interface myInterface {
int findSum(int x, inty, int z);
}

class A implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}

class B implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Proxy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural pattern, the focus is on creating ease of design by identifying a simple way to realize relationships between entities. In Behavioral patterns, on the other hand, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow of control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control. Purpose of the Proxy pattern is use a less complex object in place of the actual object until such a time that the actual object can be created. The less complex object is known as the proxy for the actual object.
|-
! Example
! inteface myInterface {
public abstract void display();
}

class classA implements myInterface {

private void loadImage() {
System.out.println("Loading in classA");
}

public void display() {
system.out.println("Displaying in classA");
}
}

class classB implements myInterface {

private void loadProxyImage(final Sting FILENAME) {
filename = FILENAME;
}

public void display() {
if(image == null) {
image = new classA(filename);
}

image.display();
}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

==Conclusion==
Behavioral design patterns, generally identify the communication between different objects and classes and how this can be made most efficiently. The behavioral design pattern, Template Method pattern, is one of the most important patterns in certain situations like in cases where we need a static algorithm defined for some purpose. Whenever we do not want the child classes to make a decision about the flow of the algorithm or we do not want the child class interfering with the parents decision, it would be ideal to use this design pattern. It also gives you a very easy way to maintain your code and make changes to it in the future as everything needs to be done only in one place. In conclusion, Template Method pattern can be explained as easily as defining a skeleton of an algorithm in an operation, deferring some steps to sub classes.

==References==

<references/>

CSC/ECE 517 Fall 2012/ch2a 2w19 is

2012-10-26T22:12:41Z

Smbuch: /* Conclusion */

<big>'''Template Method Pattern'''</big>

__TOC__

==Introduction==
A template is a previously set format that other applications use as a starting point, instead of redefining the format each time<ref>http://www.oodesign.com/template-method-pattern.html</ref>. As you can imagine, [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] contains many such patterns in order to develop software and applications. One such pattern is the Template Method Pattern<ref>http://en.wikipedia.org/wiki/Template_method_pattern</ref>. The Template Method Pattern is a [http://en.wikipedia.org/wiki/Behavioral_pattern behavioral design pattern] that defines an algorithm skeleton in a base class, with abstract definitions that derived classes can override to provide concrete behavior. The skeleton is called the template method and the subclasses or derived classes implement the algorithm, sometimes with minor modifications.

In object-oriented design, the base class defines the template by stating the steps of the algorithm using abstract methods that its derived classes implement in a more concrete manner. In this manner, the template method pattern stores the algorithm in one place while other classes implement it, which is good object-oriented(OO) design. Also, the designer can decide which of the algorithm steps are to be standard and which of these are to be customizable<ref>http://sourcemaking.com/design_patterns/template_method</ref>. These standard steps are implemented concretely in the derived classes using the abstract base class's definitions and the customizable steps are either implemented in the derived classes, or not at all. These customizable steps serve as placeholders, or ''hooks''<ref>http://en.wikipedia.org/wiki/Hook_method#Hook_methods</ref>, that the derived classes can supply or not, as they choose. So basically it is used when programmers want to fix the order of operations used in a method, but allow some amount of flexibility such that the subclasses can implement some of these operations in their own manner<ref>http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf</ref>.

The template method pattern thus, is fundamentally a code reuse technique. It is used whenever programmers want to localize common behavior in subclasses and place it in a super class to avoid code duplication. Hence it is an example of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring].

==Problems Solved by this pattern==

==Structure and Protocol==

==Roles and Responsibilities==

==Benefits and Liabilities==

==Comparison with other design patterns==
===Comparison with Adapter Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Adapter Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural patterns, the focus is on relationships between objects and how they together form larger components whereas in Behavioral patterns, the focus is on communication between objects and what each object does <ref name='StructuralBehavioral'>Design Patterns: Structural and Behavioral http://twu.seanho.com/09spr/cmpt166/lectures/35-patterns.pdf </ref>
|-
! Purpose of Use
! Enables the use of two or more unrelated interfaces, together, as one unit. This can be done by converting one (or more) of the interfaces to adapt to the type of interface that is required by the client. thus, adapter pattern acts as a Wrapper, thus, also called, Wrapper Pattern. <ref name=''>JAVA DESIGN PATTERNS http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm </ref>
! This pattern is used to define and maintain an algorithm directed towards how you want the flow of execution to be. This template method is defined in the parent class and made final, so that all children have to follow the same flow.
! Purpose of Structural pattern is to act as a wrapper to make different interfaces ready for the client interface as against that of a Behavioral pattern is to define a common algorithm defining method as final in the parents class to act as a template for all the child classes to decide the flow of control.
|-
! Example
! public class SquarePeg {
public void insert(String str) {
System.out.println("SquarePeg insert(): " + str);
}
}

public class RoundPeg {
public void insertIntoHole(String msg) {
System.out.println("RoundPeg insertIntoHole(): " + msg);
}
}

public class PegAdapter extends SquarePeg {
private RoundPeg roundPeg;
public PegAdapter(RoundPeg peg) {this.roundPeg = peg;}
public void insert(String str) {roundPeg.insertIntoHole(str);}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Strategy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Behavioral Pattern
! Behavioral Pattern
! In Behavioral patterns, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow fo control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control.
|-
! Example
! interface myInterface {
int findSum(int x, inty, int z);
}

class A implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}

class B implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Proxy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural pattern, the focus is on creating ease of design by identifying a simple way to realize relationships between entities. In Behavioral patterns, on the other hand, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow of control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control. Purpose of the Proxy pattern is use a less complex object in place of the actual object until such a time that the actual object can be created. The less complex object is known as the proxy for the actual object.
|-
! Example
! inteface myInterface {
public abstract void display();
}

class classA implements myInterface {

private void loadImage() {
System.out.println("Loading in classA");
}

public void display() {
system.out.println("Displaying in classA");
}
}

class classB implements myInterface {

private void loadProxyImage(final Sting FILENAME) {
filename = FILENAME;
}

public void display() {
if(image == null) {
image = new classA(filename);
}

image.display();
}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

==Conclusion==
Behavioral design patterns, generally identify the communication between different objects and classes and how this can be made most efficiently. The behavioral design pattern, Template Method pattern, is one of the most important patterns in certain situations like in cases where we need a static algorithm defined for some purpose. Whenever we do not want the child classes to make a decision about the flow of the algorithm or we do not want the child class interfering with the parents decision, it would be ideal to use this design pattern. It also gives you a very easy way to maintain your code and make changes to it in the future as everything needs to be done only in one place. In conclusion, Template Method pattern can be explained as easily as defining a skeleton of an algorithm in an operation, deferring some steps to sub classes.

==References==

<references/>

CSC/ECE 517 Fall 2012/ch2a 2w19 is

2012-10-26T21:55:18Z

Smbuch:

<big>'''Template Method Pattern'''</big>

__TOC__

==Introduction==
A template is a previously set format that other applications use as a starting point, instead of redefining the format each time<ref>http://www.oodesign.com/template-method-pattern.html</ref>. As you can imagine, [http://en.wikipedia.org/wiki/Software_engineering Software Engineering] contains many such patterns in order to develop software and applications. One such pattern is the Template Method Pattern<ref>http://en.wikipedia.org/wiki/Template_method_pattern</ref>. The Template Method Pattern is a [http://en.wikipedia.org/wiki/Behavioral_pattern behavioral design pattern] that defines an algorithm skeleton in a base class, with abstract definitions that derived classes can override to provide concrete behavior. The skeleton is called the template method and the subclasses or derived classes implement the algorithm, sometimes with minor modifications.

In object-oriented design, the base class defines the template by stating the steps of the algorithm using abstract methods that its derived classes implement in a more concrete manner. In this manner, the template method pattern stores the algorithm in one place while other classes implement it, which is good object-oriented(OO) design. Also, the designer can decide which of the algorithm steps are to be standard and which of these are to be customizable<ref>http://sourcemaking.com/design_patterns/template_method</ref>. These standard steps are implemented concretely in the derived classes using the abstract base class's definitions and the customizable steps are either implemented in the derived classes, or not at all. These customizable steps serve as placeholders, or ''hooks''<ref>http://en.wikipedia.org/wiki/Hook_method#Hook_methods</ref>, that the derived classes can supply or not, as they choose. So basically it is used when programmers want to fix the order of operations used in a method, but allow some amount of flexibility such that the subclasses can implement some of these operations in their own manner<ref>http://userpages.umbc.edu/~tarr/dp/lectures/Template.pdf</ref>.

The template method pattern thus, is fundamentally a code reuse technique. It is used whenever programmers want to localize common behavior in subclasses and place it in a super class to avoid code duplication. Hence it is an example of [http://en.wikipedia.org/wiki/Code_refactoring code refactoring].

==Problems Solved by this pattern==

==Structure and Protocol==

==Roles and Responsibilities==

==Benefits and Liabilities==

==Comparison with other design patterns==
===Comparison with Adapter Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Adapter Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural patterns, the focus is on relationships between objects and how they together form larger components whereas in Behavioral patterns, the focus is on communication between objects and what each object does <ref name='StructuralBehavioral'>Design Patterns: Structural and Behavioral http://twu.seanho.com/09spr/cmpt166/lectures/35-patterns.pdf </ref>
|-
! Purpose of Use
! Enables the use of two or more unrelated interfaces, together, as one unit. This can be done by converting one (or more) of the interfaces to adapt to the type of interface that is required by the client. thus, adapter pattern acts as a Wrapper, thus, also called, Wrapper Pattern. <ref name=''>JAVA DESIGN PATTERNS http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm </ref>
! This pattern is used to define and maintain an algorithm directed towards how you want the flow of execution to be. This template method is defined in the parent class and made final, so that all children have to follow the same flow.
! Purpose of Structural pattern is to act as a wrapper to make different interfaces ready for the client interface as against that of a Behavioral pattern is to define a common algorithm defining method as final in the parents class to act as a template for all the child classes to decide the flow of control.
|-
! Example
! public class SquarePeg {
public void insert(String str) {
System.out.println("SquarePeg insert(): " + str);
}
}

public class RoundPeg {
public void insertIntoHole(String msg) {
System.out.println("RoundPeg insertIntoHole(): " + msg);
}
}

public class PegAdapter extends SquarePeg {
private RoundPeg roundPeg;
public PegAdapter(RoundPeg peg) {this.roundPeg = peg;}
public void insert(String str) {roundPeg.insertIntoHole(str);}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Strategy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Behavioral Pattern
! Behavioral Pattern
! In Behavioral patterns, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow fo control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control.
|-
! Example
! interface myInterface {
int findSum(int x, inty, int z);
}

class A implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}

class B implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Proxy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural pattern, the focus is on creating ease of design by identifying a simple way to realize relationships between entities. In Behavioral patterns, on the other hand, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow of control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control. Purpose of the Proxy pattern is use a less complex object in place of the actual object until such a time that the actual object can be created. The less complex object is known as the proxy for the actual object.
|-
! Example
! inteface myInterface {
public abstract void display();
}

class classA implements myInterface {

private void loadImage() {
System.out.println("Loading in classA");
}

public void display() {
system.out.println("Displaying in classA");
}
}

class classB implements myInterface {

private void loadProxyImage(final Sting FILENAME) {
filename = FILENAME;
}

public void display() {
if(image == null) {
image = new classA(filename);
}

image.display();
}
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

==Conclusion==
==References==

<references/>

CSC/ECE 517 Fall 2012/ch2a 2w19 is

2012-10-24T05:18:30Z

Smbuch: Created page with "<big>'''Template Method Pattern'''</big> __TOC__ ==Introduction== ==Problems Solved by this pattern== ==Structure and Protocol== ==Roles and Responsibilities== ==Benefits a..."

<big>'''Template Method Pattern'''</big>

__TOC__

==Introduction==

==Problems Solved by this pattern==

==Structure and Protocol==

==Roles and Responsibilities==

==Benefits and Liabilities==

==Comparison with other design patterns==
===Comparison with Adapter Design Pattern===
{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Adapter Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Structural Pattern
! Behavioral Pattern
! In Structural patterns, the focus is on relationships between objects and how they together form larger components whereas in Behavioral patterns, the focus is on communication between objects and what each object does <ref name='StructuralBehavioral'>Design Patterns: Structural and Behavioral http://twu.seanho.com/09spr/cmpt166/lectures/35-patterns.pdf </ref>
|-
! Purpose of Use
! Enables the use of two or more unrelated interfaces, together, as one unit. This can be done by converting one (or more) of the interfaces to adapt to the type of interface that is required by the client. thus, adapter pattern acts as a Wrapper, thus, also called, Wrapper Pattern. <ref name=''>JAVA DESIGN PATTERNS http://www.allapplabs.com/java_design_patterns/adapter_pattern.htm </ref>
! This pattern is used to define and maintain an algorithm directed towards how you want the flow of execution to be. This template method is defined in the parent class and made final, so that all children have to follow the same flow.
! Purpose of Structural pattern is to act as a wrapper to make different interfaces ready for the client interface as against that of a Behavioral pattern is to define a common algorithm defining method as final in the parents class to act as a template for all the child classes to decide the flow of control.
|-
! Example
!
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

===Comparison with Strategy Design Pattern===

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! Characteristics
! Strategy Design Pattern
! Template Method Design Pattern
! Explanation
|-
! Design Pattern Category
! Behavioral Pattern
! Behavioral Pattern
! In Behavioral patterns, the focus is on communication between objects and what each object does. Thus, both these patterns enable user to define an algorithm of some form which determines the flow of control of the program. <ref name='Behavioral'>Strategy Pattern http://content.gpwiki.org/index.php/Strategy_pattern </ref>
|-
! Purpose of Use
! The algorithm defining the flow of control in a Strategy pattern can be changed even after a class that uses that algorithm has been finalized. Thus, the algorithm per say is not final and can be changed. In fact, the algorithm defining function may be declared as part of an interface and left to classes implementing that interface to implement.
! This template method is defined in the parent class and made final, so that all children have to follow the same flow. Thus, the algorithm defining flow fo control in this cannot cannot be changed under any circumstances. Once defined it is fixed for all children.
! Purpose of behavioral pattern is to define a common algorithm defining the flow of control of the program, to act as a template for all the child classes to decide their flow of control.
|-
! Example
! interface myInterface {
int findSum(int x, inty, int z);
}

class A implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}

class B implements myInterface {
public int findSum(int x, int y, int z) {
//some definition
}
! public class Response
public final void import_response()
{
template_method() {
MethodA();
if(int i < 4)
MethodB();
else
MethodC();
}

abstract public MethodA();
abstract public MethodB();
abstract public MethodC();
}

public class Feedback_response extends Response
{
MethodA() {
//some definition
}

MethodB() {
//some definition
}

MethodC() {
//some definition
}
}
! In the Strategy pattern as described, an interface myInterface has a declaration to the defining algorithm method. All the classes that implement this interface must provide a definition to this method findSum. Thus, each implementing class will provide its own way of defining the flow of control. Thus, this pattern although being a behavioral pattern, is different from template method pattern, in fact almost contrast to it.

In the template method pattern the Response class is the parent class with a final method import_response() which is the template defining the algorithm with the flow of method calls required. The methods, MethodA(), MethodB() and MethodC() are defined as abstract in the parent class and definitions are provided for these in the child class. Any class that extends Response class now has to follow the same algorithm as described in the method import_response().
|}

==References==

<references/>

CSC/ECE 517 Fall 2012

2012-10-18T22:12:50Z

Smbuch:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE 517 Fall 2012/ch 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]

CSC/ECE 517 Fall 2012/ch1b 1w45 is

2012-10-03T22:34:54Z

Smbuch:

<big>'''Automated Refactoring'''</big>

__TOC__

==Introduction==
Refactoring is a technique for restructuring existing code. It is defined as altering the code's internal structure without changing its external behavior. It is done as a series of small transformations which together produce significant restructuring. Since each transformation is small, it's less likely to go wrong. The system is also kept fully working after each small transformation, reducing the chances that a system can get seriously broken during the restructuring.<ref name="refone"> Refactoring Home Page http://refactoring.com/ </ref> When people make small changes to the code without fully understanding its design, the code loses its structure, which eventually has a cumulative effect. If the developer cannot understand the code design, then it becomes more difficult for him to preserve it. Timely refactoring helps the code to retain its shape. <ref name="reftwo"> Why should you Refactor http://sourcemaking.com/refactoring/why-should-you-refactor </ref>


Automated refactoring refers to refactoring which is under the developers control. What we mean by this is that, the system is not responsible for deciding what refactoring is required, rather this is the job of the developer. Automated refactoring is a feature of most widely used IDE's today, which helps expedite the task of refactoring for the developers. <ref name="refthree"> Refactoring for everyone http://www.ibm.com/developerworks/library/os-ecref/ </ref>
In this article, we are aiming at describing the various techniques for automated refactoring. This article gives a clear understanding of these techniques which are illustrated with examples. We have also given a comparison of the refactoring functionality provided by various frequently used IDE's.


==Common Refactoring Techniques==
===Extraction Refactoring===
There are several refactoring techniques related to extraction: Extract method, Extract local variables, Extract constants. The first method "Extract method will create a new method from code you've selected. Extract Local Variable refactoring takes an expression that is being used repeatedly and assigns it to a local variable. Extract constant refactoring is to select a static, constant expression, which the refactoring will convert to a static final constant. This is useful for removing hard-coded numbers and strings from your code

[[1) Extract method:]]

'''Before refactoring'''
:public void abc() {
::int x= 9;
::int y= 100;
::int z=x+y;
::int s=x +z;
:}

'''After refactoring'''
:public void abc() {
::int x=9;
::int y=50;
::int z= add(x,y);
::int s= add(x,z);
:}

:private int add(int x, int y) {
::return x+y;
:}

[[2) Extract local variable:]]
This refactoring technique takes out an expression and then assigns it to a variable.
This variable is then used in place of expression everywhere in the code where the
expression is present. It has several advantages. First of all it gives meaningful
name to an expression which helps in understanding what an expression does. It
helps in debugging of code and it makes code efficient.

'''Before refactoring'''

:void xyz() {
::int i=12;
::int j= 6;
::int k=15;
::int p=10;
::p+=i+j+k;
:}

In order to perform refactoring in eclipse or any other tool first we select the
expression (here i+j+k) or any other tool, it asks for name of new variable name.
Suppose we give it q.

'''After refactoring'''

:void xyz() {
::int i=12;
::int j= 6;
::int k=15;
::int p=10;
::p+=q;
:}

[[3) Extract constant:]]

'''Before refactoring'''
:void abc() {
::int a=100;
::int b=100;
::int z= a+b;
:}

Now if we want to extract the constant 100 we will select it and enter a name for it
say for example ‘num’. Now instead of using 100 we will use the variable ’num’

'''After refactoring'''

:void abc() {
::int a=num;
::int b=num;
::int c=num+num;
:}

===Inline Refactoring===
This type refactoring is the reverse of local variable extraction, in which we remove a local variable and use the value of the variable(typically an expression) in the place where the variable is used. This can be marginally more efficient than using a temporary variable and, by making the code terser, makes it either easier to read or more cryptic, depending on your point of view<ref name="reffour"> refactoring for everyone http://www.ibm.com/developerworks/library/os-ecref/ </ref>

Put in easy words, Inline refactoring is doing what an external method call does but without making the
actual call to an external method. This is as good as writing what a method does inline instead of calling
a method defined outside. Let us illustrate this with an example.

'''Before Inline Refactoring'''

:void funtion1(String msg) {
::Console.write(msg);
:}

:void function2() {
::function1(“someString”);
:}

'''After Inline refactoring'''

:void funtion2() {
::Console.write(“someString”);
:}

In this way we are shortening the code but can print statically only one value (in this case someString), each time.
<ref name="reffive"> Refactorings-Inline Method: http://www.skorkin.com/2011/02/refactorings-inline-method/</ref>

===Encapsulating Fields===
Generally its not a good practice to expose the class attributes through public interface. Thus, Encapsulating such fields will make such fields as private or protected as appropriate and generate getters and setters for the associated field.

Consider the following piece of code. This class has an attribute which is public and can be accessed by any object directly.

'''Before Encapsulating Fields'''

:public class Class1 {
::public String attr1;
:}

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.attr1 = “var”;
:::System.out.println(“Value of attr1 is” + obj.attr1);
::}
:}

On making attr1 private, we need to add getter and setter method to access it outside the class. This can be done using automated refactoring technique called Encapsulating a field technique. Now the object obj can access the attribute attr1 only through the defined getter and setter method.

'''After Encapsulating Fields'''

:public class Class1 {
::private String attr1;

::public String getAttr1() {
:::return attr1;
::}

::public setAttr1(String newAttr1Value) {
:::attr1 = newAttr1Value;
::}
:}

:public class Class2 {
::public static void main (String [] args) {
:::Class1 obj = new Class1();
:::obj.setAttr1(“var”);
:::System.out .println(“Value of Attr1 is” + obj.getAttr1());
::}
:}

===Changing Method Signature===
Here we change the change the parameters, visibility, and return type of a method.
 
'''Before Refactoring'''
Suppose our class Class1 is defined as below and it has a function funtion1 as shown:

:public class Class1 {
::public void funtion1(int a) {
::://do something
::}
:}

The method call to function1 will be as follows:

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.function1(5);
::}
:}

 
'''After Refactoring'''
On change the number of arguments in function1 to 2 instead of 1 the function call should also change. This is done by a concept called Automated refactoring technique for changing method signature.

:public class Class1 {
::public void funtion1(int a, double b) {
::://do something
::}
:}

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.function1(5, 0.0);
::}
:}

When performing the refactoring a default value of 0.0 will be passed to the function as a parameter.

== Other Refactorings ==

There are a multitude of refactorings. Those that are included with RubyMine<ref name="refsix">RubyMine :: Ruby and Ruby on Rails IDE with smart code completion, syntax highlighting and refactoring http://www.jetbrains.com/ruby/features/ruby_ide.html#Refactorings</ref> include:

<ul>
<li>[[Rename refactoring]]
 
This refactoring technique allows renaming symbols. There
are several rename refactoring available. These are rename package, rename class,
rename method, rename variable etc.
 
'''Before refactoring'''
:class abc() {
::puts “hello”
:}

:def message() {
::a= new abc()
:}

In order to rename the class ‘abc’ select it, choose rename option from the tool and give a new name.
 
'''After refactoring'''

:class xyz() {
::puts “hello”
:}

:def message() {
::a= new xyz()
:}

<li>[[Extract Module]]
 
This refactoring technique creates a module from the methods of a ruby class.
 
'''Before refactoring'''

:class abc() {
::def total_cost(item1, item2) {
:::return(item1 +item2)
::}
:}
 
'''After refactoring:''' in the abc.rb file we will have

:class abc()
::include total_cost
:end

in total_cost.rb file we will have

:module total_cost

::def total_cost(item1, item2) {
:::return(item1 +item2)
::}
<li>[[Extract Superclass]]
 
It extract certain methods from a class in a superclass.
For example if a class B contains two methods abc and xyz. We can do refactoring and move method xyz into superclass A.
 
'''Before refactoring'''

:class B
::def abc
::://some code
::end

::def xyz
::://some code
::end
:end
 
'''After refactoring'''

:class B<A
::def abc
::://some code
::end

A.rb file

::def xyz
::://some code
::end
<li>[[Introduce Variable]]
 
This is when an expression is replaced by a variable and the variable is used in place of the expression each time. A change to the expression will mean a change only at one place.
Eg.
:puts “My favorite team is #{get_team()}”
But if, ::myTeam = get_team();
 
Then, :puts “My favorite team is #{myTeam}”
<li>[[Introduce Constant]]
 
This is when a new constant is defined and initialized and that constant is used instead of a value.
Eg. :a = b +3; CONSTANT = 3; a = b + CONSTANT;
<li>[[Introduce Field]]
 
This is when a new field is defined and initialized and then that field is used instead of
the value.
Eg. :a = b + 3; @field = 3; a = b + @field;
<li>[[Introduce Parameter]]
 
This type simply adds a new parameter to a function and updates the method calls according to that.
Eg.
:Method signature changes from def function1() to def function1(pass)
:Method call will change from a=function1() to a=funtion1(something)
<li>[[Inline Variable]]
 
This works similar to Inline refactoring explained above.
Eg. Instead of writing a variable’s value to console, we will write a constant to the console, which is basically hard coding the value written to the console.
<li>[[Pull Up Members]]
 
Refers to moving a field x from a class A to its superclass. Thus, x will be moved out of all of A’s siblings and will have just one copy in A’s superclass.
Eg. If ‘type’ is an attribute of class Leopard and class Cheetah, then moving ‘type’ to super class of Leopard and Cheetah, that is, class Cat will result into one copy of ‘type’ being in class Cat and ‘type’ will get removed from both Cheetah and Leopard.
<li>[[Push Down Members]]
 
These work opposite of pull up members: If ‘type’ is part of class Cat then it will be moved individually to class Cheetah and class Leopard and now no existence of ‘type’ will be found in class Cat.
<li>[[Override Method]]
</ul>

==Refactoring support in popular IDE(s)==

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! IDE
! Language(s)
! Refactoring Support
! Automated Refactoring?
! Number of Refactoring support
! Support for Pattern
! Example
|-
! Borland Delphi
! Object Oriented Pascal
! Rename refactoring, Refactor driven “Find References”, Introduce Variable refactoring, Introduce Field refactoring, Inline Variable refactoring, Change Parameters refactoring, Safe Delete refactoring, Push Members Up / Down refactoring, Pull Members Up refactoring, Extract Superclass refactoring, Extract Interface refactoring, Move Members refactoring, Declare variable refactoring, Declare field refactoring, Extract method refactoring, Find unit/import namespace refactoring, Refactor driven “Find in Files”, Extract to resource string refactoring<ref name="borlandrefactorings>Leveraging What You Have: 10 Top Things Added to Delphi Since Delphi 7 http://edn.embarcadero.com/article/37416</ref>
! Yes
! 17
! Declare Variable<ref name="borlanddecvar">Increased Productivity with Refactoring, Unit Testing, Help Insight, Error Insight, and Sync Edit in Borland Delphi 2005 http://edn.embarcadero.com/article/33278</ref>
!
---- Before Refactoring
<pre>
procedure TWinForm1.btnOpen_Click(sender: System.Object;
e: System.EventArgs);
begin
if (OpenFileDialog1.ShowDialog =
System.Windows.Forms.DialogResult.OK) then
begin
Assign(f,OpenFileDialog1.FileName);
Reset(f);
try
finally
CloseFile(f);
end;
end;
end;
</pre>
---- After Refactoring
<pre>
procedure TWinForm1.btnOpen_Click(sender: System.Object;
e: System.EventArgs);
var
f: TextFile;
begin
if (OpenFileDialog1.ShowDialog =
System.Windows.Forms.DialogResult.OK) then
begin
Assign(f,OpenFileDialog1.FileName);
Reset(f);
try
finally
CloseFile(f);
end;
end;
end;
</pre>
|-
! Eclipse <ref name='refeclipse'>Eclipse Refactoring Actions http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm </ref>
! C, C++, Java
! Rename selected Elements, Move selected elements, Change Method Signature, Extraction, Convert Anonymous Class to Nested, Convert Local Variable to Field, Extract Super class and Interface, push down, pull up, Introduce Indirection, Encapsulate Field, Migrate JAR File, Create & Apply Refatoring Scripts
! Yes
! 27
! Introduce Factory
!
---- Before Refactoring
int x= p * 5;
p.x;
---- After Refactoring
int x= getFoo(p); (Method Extraction)
p.getX() (Encapsulate Field)
|-
! Kdevelop
! C, C++
! Several<ref name="kdeveloprefactorings">Kdevelop4: Now with refactoring! http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/</ref>. Project wide search/replace and local search/replace.
! Yes but very limited.
! 2
! Rename Class
! Right click on class name and select Rename
|-
! NetBeans <ref name="refnetbeans">Refactoring in NetBeans 4.1 http://java.sun.com/developer/technicalArticles/tools/refactoring/</ref>
! Java
! Renaming fields, methods, classes, or packages, Encapsulating fields, Changing method parameters, Moving classes,
! Yes but very limited
! 4
! No
!
---- Before Refactoring
<pre>
public class Foo{
public int n;
public int Compute(int val);
}
</pre>
---- After Refactoring (Encapsulating field)
<pre>
pubic class Foo{
private int n;
public int getN();
public void setN(int val);
public int Compute(int arg);
}
</pre>
|-
! Padre
! Perl
! Lexically Rename Variable, Introduce Temporary Variable<ref name="padrerefactorings" >How to do it in Padre http://padre.perlide.org/howto.html</ref>
! Yes
! Unknown
!
! Right click on item to refactor and select refactoring choice from the context menu
|-
! RubyMine
! Ruby
! Safe Delete, Rename Refactorings, Push Members Down, Pull Members Up, Move Refactorings, Introduce Variable, Introduce Parameter, Introduce Field, Introduce Constant, Inline, Extract Superclass, Extract Module, Extract Partial, Extract Method, Copy / Clone.
! Yes
! 15
! Introduce Temporary
!
---- Before Refactoring
<pre>
c = a * b + 5
d = 2 * a * b
</pre>
---- After Refactoring
<pre>
t = a * b
c = t + 5
d = 2 * t
</pre>
|-
! Visual Studio <ref name="refvstudio">7 Refactoring Methods in Visual Studio 2010 http://p2p.wrox.com/content/articles/7-refactoring-methods-visual-studio-2010 </ref>
! C, C++, Java, C#
! Extract Method, Encapsulate Field, Extract Interface, Rename, Promote Variable to Parameter(Changing method signature), Generate Method Stub(Used for testing purposes)
! Yes
! 7
! No
! Promoting Variable to Parameter
---- Before Refactoring
public void MethodA()
{
MethodB();
}
public void MethodB()
{
string output = "Test String";
MessageBox.Show( output);
}
---- After Refactoring
public void MethodA()
{
MethodB("Test String");
}
public void MethodB(string output)
{
MessageBox.Show( output);
}
|}

==References==

<references/>

CSC/ECE 517 Fall 2012/ch1b 1w45 is

2012-10-03T22:29:12Z

Smbuch:

<big>'''Automated Refactoring'''</big>

__TOC__

==Introduction==
Refactoring is a technique for restructuring existing code. It is defined as altering the code's internal structure without changing its external behavior. It is done as a series of small transformations which together produce significant restructuring. Since each transformation is small, it's less likely to go wrong. The system is also kept fully working after each small transformation, reducing the chances that a system can get seriously broken during the restructuring.<ref name="refone"> Refactoring Home Page http://refactoring.com/ </ref> When people make small changes to the code without fully understanding its design, the code loses its structure, which eventually has a cumulative effect. If the developer cannot understand the code design, then it becomes more difficult for him to preserve it. Timely refactoring helps the code to retain its shape. <ref name="reftwo"> Why should you Refactor http://sourcemaking.com/refactoring/why-should-you-refactor </ref>


Automated refactoring refers to refactoring which is under the developers control. What we mean by this is that, the system is not responsible for deciding what refactoring is required, rather this is the job of the developer. Automated refactoring is a feature of most widely used IDE's today, which helps expedite the task of refactoring for the developers. <ref name="refthree"> Refactoring for everyone http://www.ibm.com/developerworks/library/os-ecref/ </ref>
In this article, we are aiming at describing the various techniques for automated refactoring. This article gives a clear understanding of these techniques which are illustrated with examples. We have also given a comparison of the refactoring functionality provided by various frequently used IDE's.


==Common Refactoring Techniques==
===Extraction Refactoring===
There are several refactoring techniques related to extraction: Extract method, Extract local variables, Extract constants. The first method "Extract method will create a new method from code you've selected. Extract Local Variable refactoring takes an expression that is being used repeatedly and assigns it to a local variable. Extract constant refactoring is to select a static, constant expression, which the refactoring will convert to a static final constant. This is useful for removing hard-coded numbers and strings from your code

[[1) Extract method:]]

'''Before refactoring'''
:public void abc() {
::int x= 9;
::int y= 100;
::int z=x+y;
::int s=x +z;
:}

'''After refactoring'''
:public void abc() {
::int x=9;
::int y=50;
::int z= add(x,y);
::int s= add(x,z);
:}

:private int add(int x, int y) {
::return x+y;
:}

[[2) Extract local variable:]]
This refactoring technique takes out an expression and then assigns it to a variable.
This variable is then used in place of expression everywhere in the code where the
expression is present. It has several advantages. First of all it gives meaningful
name to an expression which helps in understanding what an expression does. It
helps in debugging of code and it makes code efficient.

'''Before refactoring'''

:void xyz() {
::int i=12;
::int j= 6;
::int k=15;
::int p=10;
::p+=i+j+k;
:}

In order to perform refactoring in eclipse or any other tool first we select the
expression (here i+j+k) or any other tool, it asks for name of new variable name.
Suppose we give it q.

'''After refactoring'''

:void xyz() {
::int i=12;
::int j= 6;
::int k=15;
::int p=10;
::p+=q;
:}

[[3) Extract constant:]]

'''Before refactoring'''
:void abc() {
::int a=100;
::int b=100;
::int z= a+b;
:}

Now if we want to extract the constant 100 we will select it and enter a name for it
say for example ‘num’. Now instead of using 100 we will use the variable ’num’

'''After refactoring'''

:void abc() {
::int a=num;
::int b=num;
::int c=num+num;
:}

===Inline Refactoring===
This type refactoring is the reverse of local variable extraction, in which we remove a local variable and use the value of the variable(typically an expression) in the place where the variable is used. This can be marginally more efficient than using a temporary variable and, by making the code terser, makes it either easier to read or more cryptic, depending on your point of view<ref name="refthree"> refactoring for everyone http://www.ibm.com/developerworks/library/os-ecref/ </ref>

Inline Refactoring

Put in easy words, Inline refactoring is doing what an external method call does but without making the
actual call to an external method. This is as good as writing what a method does inline instead of calling
a method defined outside. Let us illustrate this with an example.

'''Before Inline Refactoring'''

:void funtion1(String msg) {
::Console.write(msg);
:}

:void function2() {
::function1(“someString”);
:}

'''After Inline refactoring'''

:void funtion2() {
::Console.write(“someString”);
:}

In this way we are shortening the code but can print statically only one value (in this case someString), each time.
<ref name="reffour"> Refactorings-Inline Method: http://www.skorkin.com/2011/02/refactorings-inline-method/</ref>

===Encapsulating Fields===
Generally its not a good practice to expose the class attributes through public interface. Thus, Encapsulating such fields will make such fields as private or protected as appropriate and generate getters and setters for the associated field.

Consider the following piece of code. This class has an attribute which is public and can be accessed by any object directly.

'''Before Encapsulating Fields'''

:public class Class1 {
::public String attr1;
:}

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.attr1 = “var”;
:::System.out.println(“Value of attr1 is” + obj.attr1);
::}
:}

On making attr1 private, we need to add getter and setter method to access it outside the class. This can be done using automated refactoring technique called Encapsulating a field technique. Now the object obj can access the attribute attr1 only through the defined getter and setter method.

'''After Encapsulating Fields'''

:public class Class1 {
::private String attr1;

::public String getAttr1() {
:::return attr1;
::}

::public setAttr1(String newAttr1Value) {
:::attr1 = newAttr1Value;
::}
:}

:public class Class2 {
::public static void main (String [] args) {
:::Class1 obj = new Class1();
:::obj.setAttr1(“var”);
:::System.out .println(“Value of Attr1 is” + obj.getAttr1());
::}
:}

===Changing Method Signature===
Here we change the change the parameters, visibility, and return type of a method.
 
'''Before Refactoring'''
Suppose our class Class1 is defined as below and it has a function funtion1 as shown:

:public class Class1 {
::public void funtion1(int a) {
::://do something
::}
:}

The method call to function1 will be as follows:

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.function1(5);
::}
:}

 
'''After Refactoring'''
On change the number of arguments in function1 to 2 instead of 1 the function call should also change. This is done by a concept called Automated refactoring technique for changing method signature.

:public class Class1 {
::public void funtion1(int a, double b) {
::://do something
::}
:}

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.function1(5, 0.0);
::}
:}

When performing the refactoring a default value of 0.0 will be passed to the function as a parameter.

== Other Refactorings ==

There are a multitude of refactorings. Those that are included with RubyMine<ref name="reffive">RubyMine :: Ruby and Ruby on Rails IDE with smart code completion, syntax highlighting and refactoring http://www.jetbrains.com/ruby/features/ruby_ide.html#Refactorings</ref> include:

<ul>
<li>[[Rename refactoring]]
 
This refactoring technique allows renaming symbols. There
are several rename refactoring available. These are rename package, rename class,
rename method, rename variable etc.
 
'''Before refactoring'''
:class abc() {
::puts “hello”
:}

:def message() {
::a= new abc()
:}

In order to rename the class ‘abc’ select it, choose rename option from the tool and give a new name.
 
'''After refactoring'''

:class xyz() {
::puts “hello”
:}

:def message() {
::a= new xyz()
:}

<li>[[Extract Module]]
 
This refactoring technique creates a module from the methods of a ruby class.
 
'''Before refactoring'''

:class abc() {
::def total_cost(item1, item2) {
:::return(item1 +item2)
::}
:}
 
'''After refactoring:''' in the abc.rb file we will have

:class abc()
::include total_cost
:end

in total_cost.rb file we will have

:module total_cost

::def total_cost(item1, item2) {
:::return(item1 +item2)
::}
<li>[[Extract Superclass]]
 
It extract certain methods from a class in a superclass.
For example if a class B contains two methods abc and xyz. We can do refactoring and move method xyz into superclass A.
 
'''Before refactoring'''

:class B
::def abc
::://some code
::end

::def xyz
::://some code
::end
:end
 
'''After refactoring'''

:class B<A
::def abc
::://some code
::end

A.rb file

::def xyz
::://some code
::end
<li>[[Introduce Variable]]
 
This is when an expression is replaced by a variable and the variable is used in place of the expression each time. A change to the expression will mean a change only at one place.
Eg.
:puts “My favorite team is #{get_team()}”
But if, ::myTeam = get_team();
 
Then, :puts “My favorite team is #{myTeam}”
<li>[[Introduce Constant]]
 
This is when a new constant is defined and initialized and that constant is used instead of a value.
Eg. :a = b +3; CONSTANT = 3; a = b + CONSTANT;
<li>[[Introduce Field]]
 
This is when a new field is defined and initialized and then that field is used instead of
the value.
Eg. :a = b + 3; @field = 3; a = b + @field;
<li>[[Introduce Parameter]]
 
This type simply adds a new parameter to a function and updates the method calls according to that.
Eg.
:Method signature changes from def function1() to def function1(pass)
:Method call will change from a=function1() to a=funtion1(something)
<li>[[Inline Variable]]
 
This works similar to Inline refactoring explained above.
Eg. Instead of writing a variable’s value to console, we will write a constant to the console, which is basically hard coding the value written to the console.
<li>[[Pull Up Members]]
 
Refers to moving a field x from a class A to its superclass. Thus, x will be moved out of all of A’s siblings and will have just one copy in A’s superclass.
Eg. If ‘type’ is an attribute of class Leopard and class Cheetah, then moving ‘type’ to super class of Leopard and Cheetah, that is, class Cat will result into one copy of ‘type’ being in class Cat and ‘type’ will get removed from both Cheetah and Leopard.
<li>[[Push Down Members]]
 
These work opposite of pull up members: If ‘type’ is part of class Cat then it will be moved individually to class Cheetah and class Leopard and now no existence of ‘type’ will be found in class Cat.
<li>[[Override Method]]
</ul>

==Refactoring support in popular IDE(s)==

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! IDE
! Language(s)
! Refactoring Support
! Automated Refactoring?
! Number of Refactoring support
! Support for Pattern
! Example
|-
! Borland Delphi
! Object Oriented Pascal
! Rename refactoring, Refactor driven “Find References”, Introduce Variable refactoring, Introduce Field refactoring, Inline Variable refactoring, Change Parameters refactoring, Safe Delete refactoring, Push Members Up / Down refactoring, Pull Members Up refactoring, Extract Superclass refactoring, Extract Interface refactoring, Move Members refactoring, Declare variable refactoring, Declare field refactoring, Extract method refactoring, Find unit/import namespace refactoring, Refactor driven “Find in Files”, Extract to resource string refactoring<ref name="borlandrefactorings>Leveraging What You Have: 10 Top Things Added to Delphi Since Delphi 7 http://edn.embarcadero.com/article/37416</ref>
! Yes
! 17
! Declare Variable<ref name="borlanddecvar">Increased Productivity with Refactoring, Unit Testing, Help Insight, Error Insight, and Sync Edit in Borland Delphi 2005 http://edn.embarcadero.com/article/33278</ref>
!
---- Before Refactoring
<pre>
procedure TWinForm1.btnOpen_Click(sender: System.Object;
e: System.EventArgs);
begin
if (OpenFileDialog1.ShowDialog =
System.Windows.Forms.DialogResult.OK) then
begin
Assign(f,OpenFileDialog1.FileName);
Reset(f);
try
finally
CloseFile(f);
end;
end;
end;
</pre>
---- After Refactoring
<pre>
procedure TWinForm1.btnOpen_Click(sender: System.Object;
e: System.EventArgs);
var
f: TextFile;
begin
if (OpenFileDialog1.ShowDialog =
System.Windows.Forms.DialogResult.OK) then
begin
Assign(f,OpenFileDialog1.FileName);
Reset(f);
try
finally
CloseFile(f);
end;
end;
end;
</pre>
|-
! Eclipse <ref name='refeclipse'>Eclipse Refactoring Actions http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm </ref>
! C, C++, Java
! Rename selected Elements, Move selected elements, Change Method Signature, Extraction, Convert Anonymous Class to Nested, Convert Local Variable to Field, Extract Super class and Interface, push down, pull up, Introduce Indirection, Encapsulate Field, Migrate JAR File, Create & Apply Refatoring Scripts
! Yes
! 27
! Introduce Factory
!
---- Before Refactoring
int x= p * 5;
p.x;
---- After Refactoring
int x= getFoo(p); (Method Extraction)
p.getX() (Encapsulate Field)
|-
! Kdevelop
! C, C++
! Several<ref name="kdeveloprefactorings">Kdevelop4: Now with refactoring! http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/</ref>. Project wide search/replace and local search/replace.
! Yes but very limited.
! 2
! Rename Class
! Right click on class name and select Rename
|-
! NetBeans <ref name="refnetbeans">Refactoring in NetBeans 4.1 http://java.sun.com/developer/technicalArticles/tools/refactoring/</ref>
! Java
! Renaming fields, methods, classes, or packages, Encapsulating fields, Changing method parameters, Moving classes,
! Yes but very limited
! 4
! No
!
---- Before Refactoring
<pre>
public class Foo{
public int n;
public int Compute(int val);
}
</pre>
---- After Refactoring (Encapsulating field)
<pre>
pubic class Foo{
private int n;
public int getN();
public void setN(int val);
public int Compute(int arg);
}
</pre>
|-
! Padre
! Perl
! Lexically Rename Variable, Introduce Temporary Variable<ref name="padrerefactorings" >How to do it in Padre http://padre.perlide.org/howto.html</ref>
! Yes
! Unknown
!
! Right click on item to refactor and select refactoring choice from the context menu
|-
! RubyMine
! Ruby
! Safe Delete, Rename Refactorings, Push Members Down, Pull Members Up, Move Refactorings, Introduce Variable, Introduce Parameter, Introduce Field, Introduce Constant, Inline, Extract Superclass, Extract Module, Extract Partial, Extract Method, Copy / Clone.
! Yes
! 15
! Introduce Temporary
!
---- Before Refactoring
<pre>
c = a * b + 5
d = 2 * a * b
</pre>
---- After Refactoring
<pre>
t = a * b
c = t + 5
d = 2 * t
</pre>
|-
! Visual Studio <ref name="refvstudio">7 Refactoring Methods in Visual Studio 2010 http://p2p.wrox.com/content/articles/7-refactoring-methods-visual-studio-2010 </ref>
! C, C++, Java, C#
! Extract Method, Encapsulate Field, Extract Interface, Rename, Promote Variable to Parameter(Changing method signature), Generate Method Stub(Used for testing purposes)
! Yes
! 7
! No
! Promoting Variable to Parameter
---- Before Refactoring
public void MethodA()
{
MethodB();
}
public void MethodB()
{
string output = "Test String";
MessageBox.Show( output);
}
---- After Refactoring
public void MethodA()
{
MethodB("Test String");
}
public void MethodB(string output)
{
MessageBox.Show( output);
}
|}

==References==

<references/>

CSC/ECE 517 Fall 2012/ch1b 1w45 is

2012-09-27T23:34:10Z

Smbuch: Created page with "<big>'''Automated Refactoring'''</big> __TOC__ ==Introduction== Refactoring is a technique for restructuring existing code. It is defined as altering the code's internal struct..."

<big>'''Automated Refactoring'''</big>

__TOC__

==Introduction==
Refactoring is a technique for restructuring existing code. It is defined as altering the code's internal structure without changing its external behavior. It is done as a series of small transformations which together produce significant restructuring. Since each transformation is small, it's less likely to go wrong. The system is also kept fully working after each small transformation, reducing the chances that a system can get seriously broken during the restructuring.<ref name="refone"> Refactoring Home Page http://refactoring.com/ </ref> When people make small changes to the code without fully understanding its design, the code loses its structure, which eventually has a cumulative effect. If the developer cannot understand the code design, then it becomes more difficult for him to preserve it. Timely refactoring helps the code to retain its shape. <ref name="reftwo"> Why should you Refactor http://sourcemaking.com/refactoring/why-should-you-refactor </ref>


Automated refactoring refers to refactoring which is under the developers control. What we mean by this is that, the system is not responsible for deciding what refactoring is required, rather this is the job of the developer. Automated refactoring is a feature of most widely used IDE's today, which helps expedite the task of refactoring for the developers. <ref name="refthree"> Refactoring for everyone http://www.ibm.com/developerworks/library/os-ecref/ </ref>
In this article, we are aiming at describing the various techniques for automated refactoring. This article gives a clear understanding of these techniques which are illustrated with examples. We have also given a comparison of the refactoring functionality provided by various frequently used IDE's.


==Common Refactoring Techniques==
===Extraction Refactoring===
There are several refactoring techniques related to extraction: Extract method, Extract local variables, extract constants. The first method "Extract method will create a new method from code you've selected. Extract Local Variable refactoring takes an expression that is being used repeatedly and assigns it to a local variable. Extract constant refactoring is to select a static, constant expression, which the refactoring will convert to a static final constant. This is useful for removing hard-coded numbers and strings from your code

1) Extract method:

Before refactoring

:public void abc() {
::int x= 9;
::int y= 100;
::int z=x+y;
::int s=x +z;
:}

After refactoring

:public void abc() {
::int x=9;
::int y=50;
::int z= add(x,y);
::int s= add(x,z);
:}

:private int add(int x, int y) {
::return x+y;
:}

2) extract local variable
This refactoring technique takes out an expression and then assigns it to a variable.
This variable is then used in place of expression everywhere in the code where the
expression is present. It has several advantages. First of all it gives meaningful
name to an expression which helps in understanding what an expression does. It
helps in debugging of code and it makes code efficient.

Before refactoring

:void xyz() {
::int i=12;
::int j= 6;
::int k=15;
::int p=10;
::p+=i+j+k;
:}

In order to perform refactoring in eclipse or any other tool first we select the
expression (here i+j+k) or any other tool it asks for name of new variable name.
Suppose we give it q.

After refactoring

:void xyz() {
::int i=12;
::int j= 6;
::int k=15;
::int p=10;
::p+=q;
:}

3) Extract constant

:void abc() {
::int a=100;
::int b=100;
::int z= a+b;
:}

Now if we want to extract the constant 100 we will select it and enter a name for it
say for example ‘num’. Now instead of using 100 we will use the variable ’num’
So after refactoring

:void abc() {
::int a=num;
::int b=num;
::int c=num+num;
:}

===Inline Refactoring===
This type refactoring is the reverse of local variable extraction, in which we remove a local variable and use the value of the variable(typically an expression) in the place where the variable is used. This can be marginally more efficient than using a temporary variable and, by making the code terser, makes it either easier to read or more cryptic, depending on your point of view<ref name="refthree"> refactoring for everyone http://www.ibm.com/developerworks/library/os-ecref/ </ref>

Inline Refactoring

Put in easy words, Inline refactoring is doing what an external method call does but without making the
actual call to an external method. This is as good as writing what a method does inline instead of calling
a method defined outside. Let us illustrate this with an example.

Before Inline Refactoring

:void funtion1(String msg) {
::Console.write(msg);
:}

:void function2() {
::function1(“someString”);
:}

After Inline refactoring:

:void funtion2() {
::Console.write(“someString”);
:}

In this way we are shortening the code but can print statically only one value (in this case someString), each time.
<ref name="reffour"> Refactorings-Inline Method: http://www.skorkin.com/2011/02/refactorings-inline-method/</ref>

===Encapsulating Fields===
Generally its not a good practice to expose the class attributes through public interface. Thus, Encapsulating such fields will make such fields as private or protected as appropriate and generate getters and setters for the associated field.

Consider the following piece of code. This class has an attribute which is public and can be accessed by any object directly.

Before Encapsulating Fields

:public class Class1 {
::public String attr1;
:}

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.attr1 = “var”;
:::System.out.println(“Value of attr1 is” + obj.attr1);
::}
:}

On making attr1 private, we need to add getter and setter method to access it outside the class. This can be done using automated refactoring technique called Encapsulating a field technique. Now the object obj can access the attribute attr1 only through the defined getter and setter method.

After Encapsulating Fields

:public class Class1 {
::private String attr1;

::public String getAttr1() {
:::return attr1;
::}

::public setAttr1(String newAttr1Value) {
:::attr1 = newAttr1Value;
::}
:}

:public class Class2 {
::public static void main (String [] args) {
:::Class1 obj = new Class1();
:::obj.setAttr1(“var”);
:::System.out .println(“Value of Attr1 is” + obj.getAttr1());
::}
:}

===Changing Method Signature===
Here we change the change the parameters, visibility, and return type of a method.

Suppose our class Class1 is defined as below and it has a function funtion1 as shown:

:public class Class1 {
::public void funtion1(int a) {
::://do something
::}
:}

The method call to function1 will be as follows:

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.function1(5);
::}
:}

On change the number of arguments in function1 to 2 instead of 1 the function call should also change. This is done by a concept called Automated refactoring technique for changing method signature.

:public class Class1 {
::public void funtion1(int a, double b) {
::://do something
::}
:}

:public class Class2 {
::public static void main(String [] args) {
:::Class1 obj = new Class1();
:::Obj.function1(5, 0.0);
::}
:}

When performing the refactoring a default value of 0.0 will be passed to the function as a parameter.

== Other Refactorings ==

There are a multitude of refactorings. Those that are included with RubyMine<ref name="reffive">RubyMine :: Ruby and Ruby on Rails IDE with smart code completion, syntax highlighting and refactoring http://www.jetbrains.com/ruby/features/ruby_ide.html#Refactorings</ref> include:

<ul>
<li>Rename refactoring
 
This refactoring technique allows renaming symbols. There
are several rename refactoring available. These are rename package, rename class,
rename method, rename variable etc.
Before refactoring

:class abc() {
::puts “hello”
:}

:def message() {
::a= new abc()
:}

In order to rename the class ‘abc’ select it, choose rename option from the tool and give a new name.

After refactoring

:class xyz() {
::puts “hello”
:}

:def message() {
::a= new xyz()
:}

<li>Extract Module
 
This refactoring technique creates a module from the methods of a ruby class.

Before refactoring

:class abc() {
::def total_cost(item1, item2) {
:::return(item1 +item2)
::}
:}

After refactoring: in the abc.rb file we will have

:class abc()
::include total_cost
:end

in total_cost.rb file we will have

:module total_cost

::def total_cost(item1, item2) {
:::return(item1 +item2)
::}
<li>Extract Superclass
 
It extract certain methods from a class in a superclass.
For example if a class B contains two methods abc and xyz. We can do refactoring and move method xyz into superclass A.

Before refactoring

:class B
::def abc
::://some code
::end

::def xyz
::://some code
::end
:end

After refactoring

:class B<A
::def abc
::://some code
::end

A.rb file

::def xyz
::://some code
::end
<li>Introduce Variable
 
This is when an expression is replaced by a variable and the variable is used in place of the expression each time. A change to the expression will mean a change only at one place.
Eg.
:puts “My favorite team is #{get_team()}”
But if, ::myTeam = get_team();
 
Then, :puts “My favorite team is #{myTeam}”
<li>Introduce Constant
 
This is when a new constant is defined and initialized and that constant is used instead of a value.
Eg. :a = b +3; CONSTANT = 3; a = b + CONSTANT;
<li>Introduce Field
 
This is when a new field is defined and initialized and then that field is used instead of
the value.
Eg. :a = b + 3; @field = 3; a = b + @field;
<li>Introduce Parameter
 
This type simply adds a new parameter to a function and updates the method calls according to that.
Eg.
:Method signature changes from def function1() to def function1(pass)
:Method call will change from a=function1() to a=funtion1(something)
<li>Inline Variable
 
This works similar to Inline refactoring explained above.
Eg. Instead of writing a variable’s value to console, we will write a constant to the console, which is basically hard coding the value written to the console.
<li>Pull Up Members
 
Refers to moving a field x from a class A to its superclass. Thus, x will be moved out of all of A’s siblings and will have just one copy in A’s superclass.
Eg. If ‘type’ is an attribute of class Leopard and class Cheetah, then moving ‘type’ to super class of Leopard and Cheetah, that is, class Cat will result into one copy of ‘type’ being in class Cat and ‘type’ will get removed from both Cheetah and Leopard.
<li>Push Down Members
 
These work opposite of pull up members: If ‘type’ is part of class Cat then it will be moved individually to class Cheetah and class Leopard and now no existence of ‘type’ will be found in class Cat.
<li>Override Method
</ul>

==Refactoring support in popular IDE(s)==

{| class="wikitable sortable" style="font-size: 90%; text-align: center; width: auto;"
|-
! IDE
! Language(s)
! Refactoring Support
! Automated Refactoring?
! Number of Refactoring support
! Support for Pattern
! Example
|-
! Borland Delphi
! Object Oriented Pascal
! Rename refactoring, Refactor driven “Find References”, Introduce Variable refactoring, Introduce Field refactoring, Inline Variable refactoring, Change Parameters refactoring, Safe Delete refactoring, Push Members Up / Down refactoring, Pull Members Up refactoring, Extract Superclass refactoring, Extract Interface refactoring, Move Members refactoring, Declare variable refactoring, Declare field refactoring, Extract method refactoring, Find unit/import namespace refactoring, Refactor driven “Find in Files”, Extract to resource string refactoring<ref name="borlandrefactorings>Leveraging What You Have: 10 Top Things Added to Delphi Since Delphi 7 http://edn.embarcadero.com/article/37416</ref>
! Yes
! 17
! Declare Variable<ref name="borlanddecvar">Increased Productivity with Refactoring, Unit Testing, Help Insight, Error Insight, and Sync Edit in Borland Delphi 2005 http://edn.embarcadero.com/article/33278</ref>
!
---- Before Refactoring
<pre>
procedure TWinForm1.btnOpen_Click(sender: System.Object;
e: System.EventArgs);
begin
if (OpenFileDialog1.ShowDialog =
System.Windows.Forms.DialogResult.OK) then
begin
Assign(f,OpenFileDialog1.FileName);
Reset(f);
try
finally
CloseFile(f);
end;
end;
end;
</pre>
---- After Refactoring
<pre>
procedure TWinForm1.btnOpen_Click(sender: System.Object;
e: System.EventArgs);
var
f: TextFile;
begin
if (OpenFileDialog1.ShowDialog =
System.Windows.Forms.DialogResult.OK) then
begin
Assign(f,OpenFileDialog1.FileName);
Reset(f);
try
finally
CloseFile(f);
end;
end;
end;
</pre>
|-
! Eclipse <ref name='refeclipse'>Eclipse Refactoring Actions http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm </ref>
! C, C++, Java
! Rename selected Elements, Move selected elements, Change Method Signature, Extraction, Convert Anonymous Class to Nested, Convert Local Variable to Field, Extract Super class and Interface, push down, pull up, Introduce Indirection, Encapsulate Field, Migrate JAR File, Create & Apply Refatoring Scripts
! Yes
! 27
! Introduce Factory
!
---- Before Refactoring
int x= p * 5;
p.x;
---- After Refactoring
int x= getFoo(p); (Method Extraction)
p.getX() (Encapsulate Field)
|-
! Kdevelop
! C, C++
! Several<ref name="kdeveloprefactorings">Kdevelop4: Now with refactoring! http://zwabel.wordpress.com/2008/11/05/kdevelop4-now-with-refactoring/</ref>. Project wide search/replace and local search/replace.
! Yes but very limited.
! 2
! Rename Class
! Right click on class name and select Rename
|-
! NetBeans <ref name="refnetbeans">Refactoring in NetBeans 4.1 http://java.sun.com/developer/technicalArticles/tools/refactoring/</ref>
! Java
! Renaming fields, methods, classes, or packages, Encapsulating fields, Changing method parameters, Moving classes,
! Yes but very limited
! 4
! No
!
---- Before Refactoring
<pre>
public class Foo{
public int n;
public int Compute(int val);
}
</pre>
---- After Refactoring (Encapsulating field)
<pre>
pubic class Foo{
private int n;
public int getN();
public void setN(int val);
public int Compute(int arg);
}
</pre>
|-
! Padre
! Perl
! Lexically Rename Variable, Introduce Temporary Variable<ref name="padrerefactorings" >How to do it in Padre http://padre.perlide.org/howto.html</ref>
! Yes
! Unknown
!
! Right click on item to refactor and select refactoring choice from the context menu
|-
! RubyMine
! Ruby
! Safe Delete, Rename Refactorings, Push Members Down, Pull Members Up, Move Refactorings, Introduce Variable, Introduce Parameter, Introduce Field, Introduce Constant, Inline, Extract Superclass, Extract Module, Extract Partial, Extract Method, Copy / Clone.
! Yes
! 15
! Introduce Temporary
!
---- Before Refactoring
<pre>
c = a * b + 5
d = 2 * a * b
</pre>
---- After Refactoring
<pre>
t = a * b
c = t + 5
d = 2 * t
</pre>
|-
! Visual Studio <ref name="refvstudio">7 Refactoring Methods in Visual Studio 2010 http://p2p.wrox.com/content/articles/7-refactoring-methods-visual-studio-2010 </ref>
! C, C++, Java, C#
! Extract Method, Encapsulate Field, Extract Interface, Rename, Promote Variable to Parameter(Changing method signature), Generate Method Stub(Used for testing purposes)
! Yes
! 7
! No
! Promoting Variable to Parameter
---- Before Refactoring
public void MethodA()
{
MethodB();
}
public void MethodB()
{
string output = "Test String";
MessageBox.Show( output);
}
---- After Refactoring
public void MethodA()
{
MethodB("Test String");
}
public void MethodB(string output)
{
MessageBox.Show( output);
}
|}

==References==

<references/>