Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:53:46Z

NCS: /* References */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== [http://en.wikipedia.org/wiki/Composability Composability and Decomposability]==
Using simple interfaces to define behaviors helps us break the program down to smaller pieces that are easier to understand and manage. This also allows us to share this behavior across different classes there by increasing code reuseability. And since these behaviors are well understood it is easy to understand the behavior of objects that implement these behaviors.

It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with the specifications and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense probably a specialized object with a specialized behavior that doesn't really make sense to be defined as an interface. For example

<code>
class LocalGreeter {
public void greet () {
System.out.println (Localizer.getLocalized("hello");
}
}
</code>

We could define a greeter interface but then we don't see any reuse for it.

= Conclusion =
Bertrand Meyer's principle of explicit interfaces helps us in the following ways
* Decomposability - helps us make easier subprograms
* Composability - helps reuse of code
* Understandability - makes it easier and helps us better understand the programs
* Continuity - improves coupling

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]
* [http://www.uta.edu/cse/levine/fall99/cse5324/senotes3.pdf Software Engineering Analysis, Design, Creation]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:49:30Z

NCS: /* Continuity */

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:49:04Z

NCS: /* Understandability */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== [http://en.wikipedia.org/wiki/Composability Composability and Decomposability]==
Using simple interfaces to define behaviors helps us break the program down to smaller pieces that are easier to understand and manage. This also allows us to share this behavior across different classes there by increasing code reuseability. And since these behaviors are well understood it is easy to understand the behavior of objects that implement these behaviors.

It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with the specifications and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense probably a specialized object with a specialized behavior that doesn't really make sense to be defined as an interface. For example

<code>
class LocalGreeter {
public void greet () {
System.out.println (Localizer.getLocalized("hello");
}
}
</code>

We could define a greeter interface but then we don't see any reuse for it.

= Conclusion =
Bertrand Meyer's principle of explicit interfaces helps us in the following ways
* Decomposability - helps us make easier subprograms
* Composability - helps reuse of code
* Understandability - makes it easier and helps us better understand the programs
* Continuity - improves coupling

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:46:32Z

NCS: /* Composability and Decomposability */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== [http://en.wikipedia.org/wiki/Composability Composability and Decomposability]==
Using simple interfaces to define behaviors helps us break the program down to smaller pieces that are easier to understand and manage. This also allows us to share this behavior across different classes there by increasing code reuseability. And since these behaviors are well understood it is easy to understand the behavior of objects that implement these behaviors.

It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with the specifications and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense probably a specialized object with a specialized behavior that doesn't really make sense to be defined as an interface. For example

<code>
class LocalGreeter {
public void greet () {
System.out.println (Localizer.getLocalized("hello");
}
}
</code>

We could define a greeter interface but then we don't see any reuse for it.

= Conclusion =
Bertrand Meyer's principle of explicit interfaces helps us in the following ways
* Decomposability - helps us make easier subprograms
* Composability - helps reuse of code
* Understandability - makes it easier and helps us better understand the programs
* Continuity - improves coupling

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:40:10Z

NCS: /* Conclusion */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with the specifications and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only. Using simple interfaces to define behaviors also allows us to share this behavior across different classes there by increasing code reuseability. And since these behaviors are well understood it is easy to understand the behavior of objects that implement these behaviors.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense probably a specialized object with a specialized behavior that doesn't really make sense to be defined as an interface. For example

<code>
class LocalGreeter {
public void greet () {
System.out.println (Localizer.getLocalized("hello");
}
}
</code>

We could define a greeter interface but then we don't see any reuse for it.

= Conclusion =
Bertrand Meyer's principle of explicit interfaces helps us in the following ways
* Decomposability - helps us make easier subprograms
* Composability - helps reuse of code
* Understandability - makes it easier and helps us better understand the programs
* Continuity - improves coupling

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:39:48Z

NCS: /* Conclusion */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with the specifications and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only. Using simple interfaces to define behaviors also allows us to share this behavior across different classes there by increasing code reuseability. And since these behaviors are well understood it is easy to understand the behavior of objects that implement these behaviors.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense probably a specialized object with a specialized behavior that doesn't really make sense to be defined as an interface. For example

<code>
class LocalGreeter {
public void greet () {
System.out.println (Localizer.getLocalized("hello");
}
}
</code>

We could define a greeter interface but then we don't see any reuse for it.

= Conclusion =
Bertrand Meyer's principle of explicit interfaces helps us
* Decomposability - helps us make easier subprograms
* Composability - helps reuse of code
* Understandability - makes it easier and helps us better understand the programs
* Continuity - improves coupling

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:37:25Z

NCS: /* Not really any */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with the specifications and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only. Using simple interfaces to define behaviors also allows us to share this behavior across different classes there by increasing code reuseability. And since these behaviors are well understood it is easy to understand the behavior of objects that implement these behaviors.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense probably a specialized object with a specialized behavior that doesn't really make sense to be defined as an interface. For example

<code>
class LocalGreeter {
public void greet () {
System.out.println (Localizer.getLocalized("hello");
}
}
</code>

We could define a greeter interface but then we don't see any reuse for it.

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:27:45Z

NCS: /* Composability and Decomposability */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with the specifications and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only. Using simple interfaces to define behaviors also allows us to share this behavior across different classes there by increasing code reuseability. And since these behaviors are well understood it is easy to understand the behavior of objects that implement these behaviors.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:23:17Z

NCS: /* Interface (Implicit vs Explicit) */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects. For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement.

For example If we wish to implement the behavior of automobile we could let each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:21:52Z

NCS: /* Introduction */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Interface_(computer_science) interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:20:17Z

NCS: /* Introduction */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/interface interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:19:03Z

NCS: /* Introduction */

= Introduction =

[http://en.wikipedia.org/wiki/Bertrand_Meyer Bertrand Meyer]'s principle of explicit [http://en.wikipedia.org/wiki/Bertrand_Meyer interface] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:17:46Z

NCS: /* Introduction */

= Introduction =

[[Bertrand Meyer]]'s principle of explicit [[interface]] states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-18T01:12:22Z

NCS:

= Introduction =

Bertrand Meyer's principle of explicit interface states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>
class Automobile {

public String getMake() {}

public String getModel() {}

public String getYear() {}

public String getLicensePlate() {}

public String getLicenseExpiration() {}

public void turn() {}

public void accelerate() {}

public void stop() {}

public String getSpeed() {}

public String getRPM() {}

public String getFuelLevel() {}

}
</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>

interface Autospec{

public String getMake();

public String getModel();

public String getYear();

public String getLicensePlate();

public String getLicenseExpiration();

}

interface OperateAuto {

public void turn();

public void accelerate();

public void stop();

}

interface AutoDashboard{

public String getSpeed();

public String getRPM();

public String getFuelLevel();

}

class Automobile implements Autospec, OperateAuto, AutoDashboard{

// AutoSpec

public String getMake(){...}

public String getModel(){...}

public String getYear(){...}

public String getOwner() {...}

public String getLicensePlate(){...}

public String getLicenseExpiration(){...}

// OperateAuto

public void turn(){...}

public void accelerate(){...}

public void stop(){...}

// AutoDash

public String getSpeed(){...}

public String getRPM(){...}

public String getFuelLevel(){...}

}

</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

= References =
* [http://www.eoinwoods.info/doc/spa2009_patterns_session.pdf Design Principles Mining Pattern DNA]
* [http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf PROGRAMMING FOR REUSABILITY AND EXTENDIBILITY]

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-17T01:33:45Z

NCS: /* Code example */

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-17T01:25:12Z

NCS: /* Code example */

= Introduction =

Bertrand Meyer's principle of explicit interface states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the Automobile class. We can either define all the shared methods and behaviors implicitly as methods within the class

<source lang="java">

class Automobile {
public Automobile () {}
public String getMake() {}
public String getModel() {}
public String getYear() {}
public String getLicensePlate() {}
public String getLicenseExpiration() {}

public void turn() {}
public void accelerate() {}
public void stop() {}

public String getSpeed() {}
public String getRPM() {}
public String getFuelLevel() {}
}

</source>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<source lang="java">
interface Autospec{
public String getMake();
public String getModel();
public String getYear();
public String getLicensePlate();
public String getLicenseExpiration();

}

interface OperateAuto {
public void turn();
public void accelerate();
public void stop();
}

interface AutoDashboard{
public String getSpeed();
public String getRPM();
public String getFuelLevel();
}

class Automobile implements Autospec, OperateAuto, AutoDashboard{
// AutoSpec
public String getMake(){...}
public String getModel(){...}
public String getYear(){...}
public String getOwner() {...}
public String getLicensePlate(){...}
public String getLicenseExpiration(){...}

// OperateAuto
public void turn(){...}
public void accelerate(){...}
public void stop(){...}

// AutoDash
public String getSpeed(){...}
public String getRPM(){...}
public String getFuelLevel(){...}
}
</source>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

CSC/ECE 517 Fall 2009/wiki3 13 ncs

2009-11-17T01:04:26Z

NCS:

= Introduction =

Bertrand Meyer's principle of explicit interface states that when 2 modules A and B communicate, this must be obvious from the text of A or B or both.

In this article we will consider the Pro's and cons of this approach. When it does and does not make sense to follow this principle.

= Interface (Implicit vs Explicit)=
A generic definition of an interface in programming context can be defined as a set of methods exposed that can be invoked by other objects.

For most object oriented languages all protected and public methods of the Object will constitute to be the Object's interface.

Most object oriented languages provide a means to specify a specific behavior that the objects can implement. For example If we wish to implement the behavior of automobile we could let

each class that is an automobile have all the methods implemented without using an explicit interface or have a formal explicit interface defined that defines the automobile behavior

and have each automobile object implement the well defined Automobile interface.

== Code example ==

Let us consider the automobiles car and truck. We can either define all the shared methods and behaviors implicitly as methods within the class

<code>class Automobile {
public String getMake() {...}
public String getModel() {...}
public String getYear() {...}
public String getLicensePlate() {...}
public String getLicenseExpiration(){...}

public void turn(){...}
public void accelerate(){...}
public void stop(){...}

public String getSpeed(){...}
public String getRPM(){...}
public String getFuelLevel(){...}
}</code>

Alternatively define behaviors explicitly and have the car and truck class implement them.

<code>
public interface Autospec{
public String getMake();
public String getModel();
public String getYear();
public String getLicensePlate();
public String getLicenseExpiration();

}

public interface OperateAuto {
public void turn();
public void accelerate();
public void stop();
}

public interface AutoDashboard{
public String getSpeed();
public String getRPM();
public String getFuelLevel();
}

class Automobile implements Autospec, OperateAuto, AutoDashboard{
// AutoSpec
public String getMake(){...}
public String getModel(){...}
public String getYear(){...}
public String getOwner() {...}
public String getLicensePlate(){...}
public String getLicenseExpiration(){...}

// OperateAuto
public void turn(){...}
public void accelerate(){...}
public void stop(){...}

// AutoDash
public String getSpeed(){...}
public String getRPM(){...}
public String getFuelLevel(){...}
}
</code>

= Advantages of using explicit interface =
Let us consider the advantages of having explicit interfaces

== Understandability ==
The behaviors are well understood and helps us understand the functionality as a set of smaller related operations. By documenting the behaviors it is easier to understand each set and

the behavior individually and it is clear by looking at the Auto class that it implements these behavior. The interface exposed by the auto class can be easily understood.

== Continuity ==
It is very easy to find the elements that a potential change can effect. In our example above if we have explicit interfaces to determine the impact of change in any of the interface

methods or modifying an interface itself can be easily determined by the determining the sets of elements that either implement the interface or invoke it.

== Composability and Decomposability ==
It is easy to determine the impact if we have the need to decompose a module further. For example if we feel the need to split the specification interface into two one that deals with

the specs and the other that deals with DMV then any and all outside dependencies are clearly visible. We simply need to look at elements that use the Autospec interface only.

=Disadvantages of using explicit interfaces =
== Not really any ==
The only case it might not make sense is if the class itself has only one

= Conclusion =
Bertrand Meyer's principle does help us understand the code better and makes it easier to identify the impacted elements much more easily if there are any changes in the interface or we intend to compose or decompose the objects in smaller pieces.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-14T01:21:27Z

NCS: /* Iterators */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;
// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}
</code>

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential object in the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-14T01:21:04Z

NCS: /* Conclusion */

=Introduction=

[http://en.wikipedia.org/wiki/Ruby_language Ruby] offers more concise implementations of certain [http://en.wikipedia.org/wiki/Design_pattern design patterns] than [http://en.wikipedia.org/wiki/Java_language Java] does. We will look at some design patterns and compare the implementation in '''Ruby vs Java''' with the goal to answer the following:
* Is this typical of [http://en.wikipedia.org/wiki/Dynamic_language dynamic] object-oriented languages?

* Are there design patterns that any dynamically typed language can realize better than a statically typed language?

* Are there instances when a different pattern should be used in a dynamic language than a static language?

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==

[http://en.wikipedia.org/wiki/Singleton_pattern Singleton pattern] is a design pattern used to restrict the instantiation of the class to one object.

The implementation of the pattern involves:
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Below is the comparison between singleton class written in Java and Ruby.

It is clear that Ruby provides a more concise way of implementing the singleton pattern. Ruby uses the singleton module which automatically provides all the functionality that we need to write manually in Java. By writing "include singleton" in Ruby, we prevent ourselves from having to repeat writing the same code for each class that we wish to make singleton. In contrast, we need to write the Java class below for every singleton objects we create.

'''Java'''

<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonEx;
// Make the constructor is private
private SingletonExample() {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonEx == null) {
singletonEx = new SingletonExample();
}
return singletonEx;
}
}
</code>

'''Ruby''' (using singleton module)

<code>
require singleton
class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific pattern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support meta-programming and reflection via Modules and Mixins and support extending/reopening classes and redefining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on solving the problem at hand rather than spending time implementing the design patterns.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-09T00:25:17Z

NCS: /* Conclusion */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==
Singleton pattern is used when we wish to restict the instantiation of the class to a single pattern.

The implementation of the pattern involves
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Singleton Class example in JAVA
<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonExample;
// Make the constructor is private
private SingletonExample () {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonExample == null) {
singletonExample = new SingletonExample ();
}
return singletonExample ;
}
}
</code>
In JAVA we would need to take the above steps for every class that we want to make singleton.

In ruby we can do what we did in JAVA above or simply use the singleton module that automatically gets us the functionality listed above.

Singleton example in Ruby using the singleton module.

<code>
require singleton
Class SingletonExample
include singleton
end
</code>

Ruby provides a more concise way of implementing the singleton pattern and prevents us from havin to repeat ourselves for each class that we wish to make singleton. We can simply include the singleton module. In JAVA we will have to repeat the code from the JAVA example for each class we wish to make singleton.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with fewer lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton" statement. You can make factories that look exactly like ordinary classes. These features in Ruby do make implementing design patterns very easy and let a programmer focus on soving the problem at hand rather than spending time implementing the design patterns.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-09T00:22:36Z

NCS: /* Iterators */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==
Singleton pattern is used when we wish to restict the instantiation of the class to a single pattern.

The implementation of the pattern involves
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Singleton Class example in JAVA
<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonExample;
// Make the constructor is private
private SingletonExample () {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonExample == null) {
singletonExample = new SingletonExample ();
}
return singletonExample ;
}
}
</code>
In JAVA we would need to take the above steps for every class that we want to make singleton.

In ruby we can do what we did in JAVA above or simply use the singleton module that automatically gets us the functionality listed above.

Singleton example in Ruby using the singleton module.

<code>
require singleton
Class SingletonExample
include singleton
end
</code>

Ruby provides a more concise way of implementing the singleton pattern and prevents us from havin to repeat ourselves for each class that we wish to make singleton. We can simply include the singleton module. In JAVA we will have to repeat the code from the JAVA example for each class we wish to make singleton.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection
* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection and cast the objects to the right type to use them whereas in Ruby iterators are built right in. Here are some examples that show the ease with which we can use iterators in Ruby

<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-09T00:18:39Z

NCS: /* Factory Pattern */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==
Singleton pattern is used when we wish to restict the instantiation of the class to a single pattern.

The implementation of the pattern involves
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Singleton Class example in JAVA
<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonExample;
// Make the constructor is private
private SingletonExample () {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonExample == null) {
singletonExample = new SingletonExample ();
}
return singletonExample ;
}
}
</code>
In JAVA we would need to take the above steps for every class that we want to make singleton.

In ruby we can do what we did in JAVA above or simply use the singleton module that automatically gets us the functionality listed above.

Singleton example in Ruby using the singleton module.

<code>
require singleton
Class SingletonExample
include singleton
end
</code>

Ruby provides a more concise way of implementing the singleton pattern and prevents us from havin to repeat ourselves for each class that we wish to make singleton. We can simply include the singleton module. In JAVA we will have to repeat the code from the JAVA example for each class we wish to make singleton.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}
class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}
class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in Ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory
def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end
end
</code>

Our client class now becomes:

<code>
class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end
</code>

Ruby lets us redefine the new method and this allows us to implement the Factory pattern with a class that looks very much like an ordinary class. The client does not need to know about the special createObject methods.

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby
<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>
=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-09T00:15:32Z

NCS: /* Singleton Pattern */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==
Singleton pattern is used when we wish to restict the instantiation of the class to a single pattern.

The implementation of the pattern involves
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Singleton Class example in JAVA
<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonExample;
// Make the constructor is private
private SingletonExample () {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonExample == null) {
singletonExample = new SingletonExample ();
}
return singletonExample ;
}
}
</code>
In JAVA we would need to take the above steps for every class that we want to make singleton.

In ruby we can do what we did in JAVA above or simply use the singleton module that automatically gets us the functionality listed above.

Singleton example in Ruby using the singleton module.

<code>
require singleton
Class SingletonExample
include singleton
end
</code>

Ruby provides a more concise way of implementing the singleton pattern and prevents us from havin to repeat ourselves for each class that we wish to make singleton. We can simply include the singleton module. In JAVA we will have to repeat the code from the JAVA example for each class we wish to make singleton.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}

class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}

class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory

def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end

end

<source>

Our client class now becomes:

<code>

class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end

</code>

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby
<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>
=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-09T00:12:24Z

NCS: /* Singleton Pattern */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==
Singleton pattern is used when we wish to restict the instantiation of the class to a single pattern.

The implementation of the pattern involves
* making the constructor private
* declare a instance variable
* implement a getInstance method and make the it thread safe.

Singleton Class example in JAVA
<code>
public class SingletonExample {
// declare instance variable
private static SingletonExample singletonExample;
// Make the constructor is private
private SingletonExample () {
}
// make this thread safe use synchronize
synchronize public static SingletonExample getSingletonObject() {
if (singletonExample == null) {
singletonExample = new SingletonExample ();
}
return singletonExample ;
}
}
</code>
In JAVA we would need to take the above steps for every class that we want to make singleton.

In ruby we can do what we did in JAVA above or simply use the singleton module that automatically gets us the functionality listed above.

Singleton example in Ruby using the singleton module.

<code>
require singleton
Class SingletonExample
include singleton
end
</code>

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}

class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}

class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory

def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end

end

<source>

Our client class now becomes:

<code>

class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end

</code>

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby
<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>
=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-08T23:55:34Z

NCS:

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns in JAVA vs Ruby=

==Singleton Pattern==
Resticting the instantiation of the class to a single pattern.

The implementation of the pattern in JAV And Ruby is identical. We need to

* make the constructor private

* declare a instance variable

* implement a getInstance method and make the it thread safe.

However in JAVA we would need to redo these steps for all classes that we want to be singleton whereas in Ruby we can simply include the singleton module that automatically gets us the functionality listed above.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<code>

interface IObjectFactory {
IGear createObject();
}

class ConcreteObjectFactory implements IObjectFactory{
IObject createObject() {
if ( some condition )
return new XObject();
else
return new YObject();
}

class ObjectUser {
public void doSomething(IObjectFactory factory ) {
IObject my_Object = factory.createObject();
}
}
</code>

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in ruby. Ruby allows us to rename our factory method to be called new.

<code>
class ObjectFactory

def new()
if ( ... some condition )
return XObject.new()
else
return YObject().new()
end

end

<source>

Our client class now becomes:

<code>

class ObjectUser
def doSomething(factory )
...
my_object = factory.new()
...
end
end

</code>

==Iterators==
Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby
<code>
a = [ 10, 20, 30, 40 ]
a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

</code>
=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-08T23:26:00Z

NCS: /* Factory Pattern */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns Analysis=

==Singleton Pattern==
Resticting the instantiation of the class to a single pattern.

The implementation of the pattern in JAV And Ruby is identical. We need to

* make the constructor private

* declare a instance variable

* implement a getInstance method and make the it thread safe.

<todo> JAVA and ruby singletone examples here. </todo>

However in JAVA we would need to redo these steps for all classes that we want to be singleton whereas in Ruby we can simply include the singleton module that automatically gets us the functionality listed above.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<source lang="java">

interface IObjectFactory {

IGear createObject();

}

class ConcreteObjectFactory implements IObjectFactory{

IObject createObject() {

if ( some condition )

return new XObject();

else

return new YObject();

}

class ObjectUser {

public void doSomething(IObjectFactory factory ) {

IObject my_Object = factory.createObject();

}

}
</source>
We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in ruby. Ruby allows us to rename our factory method to be called new

<source lang="Ruby">
class ObjectFactory

def new()

if ( ... some condition )

return XObject.new()

else

return YObject().new()

end

end

end
<source>
Our client class now becomes:

<source lang="Ruby">
class ObjectUser

def doSomething(factory )

...

my_object = factory.new()

...

end

end
<source>

=Iterators= Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby

a = [ 10, 20, 30, 40 ]

a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

<TODO> Some more patterns

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-08T23:22:31Z

NCS: /* Factory Pattern */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns Analysis=

==Singleton Pattern==
Resticting the instantiation of the class to a single pattern.

The implementation of the pattern in JAV And Ruby is identical. We need to

* make the constructor private

* declare a instance variable

* implement a getInstance method and make the it thread safe.

<todo> JAVA and ruby singletone examples here. </todo>

However in JAVA we would need to redo these steps for all classes that we want to be singleton whereas in Ruby we can simply include the singleton module that automatically gets us the functionality listed above.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

<source lang="JAVA">
interface IObjectFactory {

IGear createObject();

}

class ConcreteObjectFactory implements IObjectFactory{

IObject createObject() {

if ( ... some condition... )

return new XObject();

else

return new YObject();

}

class ObjectUser {

public void doSomething(IObjectFactory factory ) {

...

IObject my_Object = factory.createObject();

...

}

}
</source>
We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in ruby. Ruby allows us to rename our factory method to be called new

<source lang="Ruby">
class ObjectFactory

def new()

if ( ... some condition )

return XObject.new()

else

return YObject().new()

end

end

end
<source>
Our client class now becomes:

<source lang="Ruby">
class ObjectUser

def doSomething(factory )

...

my_object = factory.new()

...

end

end
<source>

=Iterators= Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby

a = [ 10, 20, 30, 40 ]

a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

<TODO> Some more patterns

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-08T23:21:15Z

NCS: /* Factory Pattern */

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns Analysis=

==Singleton Pattern==
Resticting the instantiation of the class to a single pattern.

The implementation of the pattern in JAV And Ruby is identical. We need to

* make the constructor private

* declare a instance variable

* implement a getInstance method and make the it thread safe.

<todo> JAVA and ruby singletone examples here. </todo>

However in JAVA we would need to redo these steps for all classes that we want to be singleton whereas in Ruby we can simply include the singleton module that automatically gets us the functionality listed above.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like
<source lang="JAVA">
interface IObjectFactory {

IGear createObject();

}

class ConcreteObjectFactory implements IObjectFactory{

IObject createObject() {

if ( ... some condition... )

return new XObject();

else

return new YObject();

}

class ObjectUser {

public void doSomething(IObjectFactory factory ) {

...

IObject my_Object = factory.createObject();

...

}

}
</source>
We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in ruby. Ruby allows us to rename our factory method to be called new

<source lang="Ruby">
class ObjectFactory

def new()

if ( ... some condition )

return XObject.new()

else

return YObject().new()

end

end

end
<source>
Our client class now becomes:

<source lang="Ruby">
class ObjectUser

def doSomething(factory )

...

my_object = factory.new()

...

end

end
<source>

=Iterators= Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby

a = [ 10, 20, 30, 40 ]

a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

<TODO> Some more patterns

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki2 13 ncs

2009-10-08T23:18:43Z

NCS:

=Introduction=

Ruby allows much more concise implementations of design patterns for example a single line of code is enough to implement the singleton pattern. We will look at some design patterns and compare the implementation in Ruby vs Java with the goal to determine the following

* can dynamic typed languages realize the design patterns more effectively than statically typed languages

* Are there instances where a design pattern should be used in a dynamic language than a static language

=Design Patterns Analysis=

==Singleton Pattern==
Resticting the instantiation of the class to a single pattern.

The implementation of the pattern in JAV And Ruby is identical. We need to

* make the constructor private

* declare a instance variable

* implement a getInstance method and make the it thread safe.

<todo> JAVA and ruby singletone examples here. </todo>

However in JAVA we would need to redo these steps for all classes that we want to be singleton whereas in Ruby we can simply include the singleton module that automatically gets us the functionality listed above.

==Factory Pattern==
Isolate the code to create an object from the concrete implementation of the class.

In JAVA we typically do something like

interface IObjectFactory {

IGear createObject();

}

class ConcreteObjectFactory implements IObjectFactory{

IObject createObject() {

if ( ... some condition... )

return new XObject();

else

return new YObject();

}

class ObjectUser {

public void doSomething(IObjectFactory factory ) {

...

IObject my_Object = factory.createObject();

...

}

}

We can technically do the exact same thing in Ruby however Ruby being a dynamic language there are no special classes or class methods in ruby. Ruby allows us to rename our factory method to be called new

class ObjectFactory

def new()

if ( ... some condition )

return XObject.new()

else

return YObject().new()

end

end

end

Our client class now becomes:

class ObjectUser

def doSomething(factory )

...

my_object = factory.new()

...

end

end

=Iterators= Iterators are design patterns used to access the elements of an aggregate object sequentially without exposing its underlying representation. To use iterators we need

* An iterator declared and initialized to point to the collection

* Write a loop and use the iterator to get the value of the next sequential objec tin the collection.

In JAVA we will need to know the type of objects in the collection whereas in ruby iterators are built right in. here are some examples that show the ease with which we can use iterators in Ruby

a = [ 10, 20, 30, 40 ]

a.each { |element| print "The element is #{element}\n" }

Thread.list.each { |t| print "Thread: #{t}\n" }

ObjectSpace.each_object { |o| print "Object: #{o}\n" }

open("data.txt").each_line { |line| print "The line is #{line}\n" }

<TODO> Some more patterns

=Conclusion=

Design patterns are concepts that are equally applicable to solve problems regardless of the language we use to implement the solution. So I cannot think of a case where a specific apttern will be more useful or pertinent to be used in a dynamic language than a static language. However given the features of dynamic languages like Ruby that support metaprogramming and reflection via Modules and Mixins and support extending/reopening classes and redfining methods at run time definitely make it easier to implement patterns with less lines of code. Ruby lets us hide the details of implementations of design patterns much more effectively. You can make a class a singleton with a simple "include Singleton". You can make factories that look exactly like ordinary classes. You can define visitors with a couple of curly braces. All of this allows you to compress out the details and simply say more interesting things in each line of code.

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:30:55Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked vs Unchecked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown. Unchecked exceptions extend the java.lang.RuntimeException. [http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html Checked vs Unchecked] the Controversy.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.

=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

==References==
[http://portal.acm.org/citation.cfm?id=130948] Exception handling in Object Oriented Systems

[http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html ]Sun Java Tutorial

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:26:23Z

NCS: /* References */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

==References==
[http://portal.acm.org/citation.cfm?id=130948] Exception handling in Object Oriented Systems

[http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html ]Sun Java Tutorial

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:26:12Z

NCS: /* References */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

==References==
[http://portal.acm.org/citation.cfm?id=130948] Exception handling in Object Oriented Systems
[http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html ]Sun Java Tutorial

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:21:47Z

NCS: /* References */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

==References==
[http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html ]Sun Java Tutorial

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:21:18Z

NCS: /* References */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

==References==
[http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html Sun Java Tutorial]

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:20:47Z

NCS: /* Try catch and finally blocks */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

==References==
[http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html]

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:20:01Z

NCS: /* Propagating an exception */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:19:34Z

NCS: /* Propagating an exception */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>
void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}

...

try {
% code calling updateNameInDBFile
} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:17:51Z

NCS: /* Propagating an exception */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

You can also catch the exception and throw a new exception that the calling layer can understand and recover from.

<code>

void updateNameInDBFile(String Name) throws IOException {
% Performs some file IO operation and propagates the IOException to calling function
}
try {

} catch (IOException e) {
throw new NameNotUpdatedException(e); // maps IOException to NameNotUpdatedException
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T15:04:57Z

NCS: /* Example: Exception handling in JAVA */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Propagating an exception ===
You don't have to catch exceptions thrown from other methods. If you cannot do anything about the exception where the method throwing it is called, you can just let the method propagate the exception up the call stack to the method that called this method. If you do so the method calling the method that throws the exception must also declare to throw the exception.

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:59:13Z

NCS: /* Throwing an Exception */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:58:43Z

NCS: /* Throwing an Exception */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>

Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException, ArrayIndexOutOfBoundsException {
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:58:14Z

NCS: /* Throwing an Exception */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

<code>
throw someThrowableObject;
</code>
Specifying exceptions thrown by an Method

<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:57:50Z

NCS: /* Example: Exception handling in JAVA */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.
<code>
throw someThrowableObject;
</code>
Specifying exceptions thrown by an Method
<code>
public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}
</code>

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:53:12Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.
Example NullPointerException.

=== Try catch and finally blocks ===

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>
=== Throwing an Exception ===
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. Here's an example of a throw statement.

throw someThrowableObject;

Specifying exceptions thrown by an Method

public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:49:22Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object. 
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.

Try catch and finally blocks

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>
Throwing an Exception
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. (subclass of the Throwable class). Here's an example of a throw statement.

throw someThrowableObject;

Specifying exceptions thrown by an Method

public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:48:59Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object.
http://www.artima.com/designtechniques/images/exceptFig1.gif

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.

Try catch and finally blocks

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>
Throwing an Exception
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. (subclass of the Throwable class). Here's an example of a throw statement.

throw someThrowableObject;

Specifying exceptions thrown by an Method

public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:46:19Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object.
<center> Object 
| 
Throwable 
| 
__________________________________ 
| | 
Error Exception 
... | 
___________________ 
| | 
...... RunTimeException 
..... 
</center>

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.

Try catch and finally blocks

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>
Throwing an Exception
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. (subclass of the Throwable class). Here's an example of a throw statement.

throw someThrowableObject;

Specifying exceptions thrown by an Method

public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:43:02Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object.

<center> Object 
| 
Throwable 
| 
__________________________________ 
| | 
Error Exception 
... | 
___________________ 
| | 
...... RunTimeException 
..... 
</center>

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.

Try catch and finally blocks

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch (SomeException se)
{
% code that handles this exception
}
catch (SomeOtherException soe)
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>
Throwing an Exception
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. (subclass of the Throwable class). Here's an example of a throw statement.

throw someThrowableObject;

Specifying exceptions thrown by an Method

public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:41:53Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object.

<center> Object 
| 
Throwable 
| 
__________________________________ 
| | 
Error Exception 
... | 
___________________ 
| | 
...... RunTimeException 
..... 
</center>

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.

Try catch and finally blocks

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try
{
% code that might throw an exception
}
catch SomeError:
{
% code that handles this exception
}
catch SomeOtherError:
{
% code that handles this exception
}
finally % optional block
{
% This code will always get executed
}
</code>
Throwing an Exception
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. (subclass of the Throwable class). Here's an example of a throw statement.

throw someThrowableObject;

Specifying exceptions thrown by an Method

public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html

CSC/ECE 517 Fall 2009/wiki1b 3 NCS

2009-09-20T14:40:31Z

NCS: /* Exception hierarchy */

=Exception handling in Object Oriented Languages=

An exception is an abnormal event, which occurs during the execution of a program that interrupts the normal flow of the program. [http://en.wikipedia.org/wiki/Exception_handling Exception handling] is the programming constructs a language provides to handle exceptions.

== Programming Constructs for exception handling ==

Exception handling systems in general strive to improve software reliability, readability, usability, maintainability and easier debugging.

Most modern Object Oriented Language exception handling systems provide the programmers a means to
=== Raising an exception ===
When an error occurs within a method, the method creates an object and hands it off to the runtime system. Creating an exception object and handing it to the run time system is called throwing an exception. This done typically using either a throw or raise statement. This statement takes the exception object as an argument.

=== Create Exception Objects ===
The Exception Object typically contains the following information about the error
* Type of error
* State of the program
* Where the error occurred

Object Oriented languages also allow the programmer to organize the exceptions objects in an inheritance hierarchy allowing the sharing of common behaviors and actions for a set of exceptions.

=== Write Exception handlers ===
Exception handlers are generally written as blocks of code ( catch/rescue/except blocks ) that can specify the types of exceptions they can handle along with a means to specify the scope of the handler ( try block ). Multiple exceptions can be caught with a single handler.

Using the above statements a programmer can specify a stack of handlers that can be traversed to match an exception with an appropriate handler

=== Match Exceptions with exceptions handlers ===
Once an exception is raised the run time system will traverse the stack backwards to find an exception handler that can handle the raised exception. Once a handler is found that can handle the raised exception the run time system passes control to the handler along with the exception object.

=== Handling Exceptions ===
The exception handler routine can look at the exception caught and may decide to perform one of the following actions
* Resume the program or retry the failed operation
* Propagate the exception
* Terminate the program
* Spawn a debug process

== Example: Exception handling in JAVA ==
=== Exception hierarchy ===
All Exception objects in JAVA are sub classed from the Exception Object.

<center> Object 
| 
Throwable 
| 
__________________________________ 
| | 
Error Exception 
... | 
___________________ 
| | 
...... RunTimeException 
..... 
</center>

* Checked Exceptions
Checked exceptions must be explicitly caught or propagated as described in Basic try-catch-finally Exception Handling. Unchecked exceptions do not have this requirement. They don't have to be caught or declared thrown.

* Unchecked Exceptions
Unchecked exceptions extend the java.lang.RuntimeException.

* Errors
Errors are hard errors within the JVM. Applications typically do not handle or throw Errors. Errors are unchecked exceptions.

Try catch and finally blocks

The first step for writing exception handlers is to specify the scope of the handler using a try block. the try block encloses the code that can throw exceptions that the exception handler plans on handling. The exception handler itself is specified within the catch block. Each catch block handles the type of exception as specified by the argument of the catch block. Finally the finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs. The finally block also serves the purpose of avoiding bypassing the clean up code accidentally in the case of an exception or accidentally by a return or a break statement.
<code>
try {
% code
} catch (ArrayIndexOutOfBoundsException e) {
% handler for ArrayIndexOutOfBoundsException
} catch (IOException e) {
% handler for IO exception
} finally {
% clean up
}
<code>
Throwing an Exception
The throw statement is used to throw an exception. The throw statement requires a single argument: a throwable object. (subclass of the Throwable class). Here's an example of a throw statement.

throw someThrowableObject;

Specifying exceptions thrown by an Method

public void foo() throws IOException,
ArrayIndexOutOfBoundsException {
}

* Small talk allows exception handlers to be only associated with classes and when an exception is raised it searches for the handler in the class where the exception was raised.

http://java.sun.com/docs/books/tutorial/essential/exceptions/index.html