Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T01:56:59Z

Stphung: /* Invariants */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle is a object oriented design principle was introduced by Barbara Liskov in 1987 and is concerned with subtyping and contractual adherence. This principle is part of the [http://en.wikipedia.org/wiki/Solid_%28Object_Oriented_Design%29 SOLID] principles of object oriented design which is an acronym for the five basic class design principles and relates to many object oriented design principles. The basic idea behind the object oriented design principles is to create and apply proper [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstractions]. Based on a paper from 1994 the principle states,

<pre>
"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.".
</pre>

This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider implements LocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

In this example, a GpsLocationProvider is a subtype to LocationProvider. However, the GpsLocationProvider has a precondition which the LocationProvider does not which is that it requires a GPS fix to get a location. This creates a new precondition which LocationProvider does not require. Liskov substitution would not be possible here since you could not treat a GpsLocationProvider as a LocationProvider.

==Postconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Postcondition postconditions] cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

MyList<T> implements List<T> {
...
public boolean contains(T element) {
this.remove(t)
// -- Wait! I can't do that, a postcondition to calling contains is that the list is unmodified.
// The removal of this postcondition in this list would mean this class has less postconditions then the parent.
// This is not good!
...
}
...
}

</pre>

In this example, we have a MyList which is a subtype to List. For one reason or another we want to also remove the element if we call contains on it. This violates a postcondition that the list must remain unmodified when calling contains. Due to this violation, we would not be able to use Liskov substitution here. In fact, substituting this List implementation into a program which uses List could be disastrous!

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

class Rectangle {
private double width;
private double height;

public Rectangle(double width, double height) {
this.width = width;
this.height = height;
}

public double getWidth() {return this.width;}
public double getHeight() {return this.height;}

public double setWidth(int width) {this.width= width;}
public double setHeight(int height) {this.height = height;}
}

class Square extends Rectangle {
private double width;
private double height;

public Square(double side) {
super(side, side);
}

public double setSide(int side) {
super.setWidth(side);
super.setHeight(side);
}
}

</pre>

This example is a classic example used when discussing Liskov substitution. There is a Rectangle class which has two data members, the height and width, constructors, getters, and setters are provided. In the subtype, Square, we want to have the sides be equal, therefore we delegate calls to the parent in order to do so. In this naive example, if a programmer does not have access to the source code they can violate an invariant of the Square class which is that the sides must be equal. Continuing our example this would look like the following.

<pre>

Rectangle square = new Square(1);
square.setSide(5); // This is ok, both our sides are equal to 5 now!
square.setWidth(2); // This is not ok, both height and width of the Square are not equal at this point.

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be substituted for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T01:50:15Z

Stphung: /* Postconditions */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle is a object oriented design principle was introduced by Barbara Liskov in 1987 and is concerned with subtyping and contractual adherence. This principle is part of the [http://en.wikipedia.org/wiki/Solid_%28Object_Oriented_Design%29 SOLID] principles of object oriented design which is an acronym for the five basic class design principles and relates to many object oriented design principles. The basic idea behind the object oriented design principles is to create and apply proper [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstractions]. Based on a paper from 1994 the principle states,

<pre>
"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.".
</pre>

This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider implements LocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

In this example, a GpsLocationProvider is a subtype to LocationProvider. However, the GpsLocationProvider has a precondition which the LocationProvider does not which is that it requires a GPS fix to get a location. This creates a new precondition which LocationProvider does not require. Liskov substitution would not be possible here since you could not treat a GpsLocationProvider as a LocationProvider.

==Postconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Postcondition postconditions] cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

MyList<T> implements List<T> {
...
public boolean contains(T element) {
this.remove(t)
// -- Wait! I can't do that, a postcondition to calling contains is that the list is unmodified.
// The removal of this postcondition in this list would mean this class has less postconditions then the parent.
// This is not good!
...
}
...
}

</pre>

In this example, we have a MyList which is a subtype to List. For one reason or another we want to also remove the element if we call contains on it. This violates a postcondition that the list must remain unmodified when calling contains. Due to this violation, we would not be able to use Liskov substitution here. In fact, substituting this List implementation into a program which uses List could be disastrous!

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

class Rectangle {
private double width;
private double height;

public Rectangle(double width, double height) {
this.width = width;
this.height = height;
}

public double getWidth() {return this.width;}
public double getHeight() {return this.height;}

public double setWidth(int width) {this.width= width;}
public double setHeight(int height) {this.height = height;}
}

class Square extends Rectangle {
private double width;
private double height;

public Square(double side) {
super(side, side);
}

public double setSide(int side) {
super.setWidth(side);
super.setHeight(side);
}
}

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be substituted for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T01:45:40Z

Stphung: /* Preconditions */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle is a object oriented design principle was introduced by Barbara Liskov in 1987 and is concerned with subtyping and contractual adherence. This principle is part of the [http://en.wikipedia.org/wiki/Solid_%28Object_Oriented_Design%29 SOLID] principles of object oriented design which is an acronym for the five basic class design principles and relates to many object oriented design principles. The basic idea behind the object oriented design principles is to create and apply proper [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstractions]. Based on a paper from 1994 the principle states,

<pre>
"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.".
</pre>

This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider implements LocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

In this example, a GpsLocationProvider is a subtype to LocationProvider. However, the GpsLocationProvider has a precondition which the LocationProvider does not which is that it requires a GPS fix to get a location. This creates a new precondition which LocationProvider does not require. Liskov substitution would not be possible here since you could not treat a GpsLocationProvider as a LocationProvider.

==Postconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Postcondition postconditions] cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

SelectiveCountingList<T> implements List<T> {
...
public boolean contains(T element) {
this.remove(t)
// -- Wait! I can't do that, a postcondition to calling contains is that the list is unmodified.
// The removal of this postcondition in this list would mean this class has less postconditions then the parent.
// This is not good!
...
}
...
}

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

class Rectangle {
private double width;
private double height;

public Rectangle(double width, double height) {
this.width = width;
this.height = height;
}

public double getWidth() {return this.width;}
public double getHeight() {return this.height;}

public double setWidth(int width) {this.width= width;}
public double setHeight(int height) {this.height = height;}
}

class Square extends Rectangle {
private double width;
private double height;

public Square(double side) {
super(side, side);
}

public double setSide(int side) {
super.setWidth(side);
super.setHeight(side);
}
}

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be substituted for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T01:43:09Z

Stphung: /* Invariants */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle is a object oriented design principle was introduced by Barbara Liskov in 1987 and is concerned with subtyping and contractual adherence. This principle is part of the [http://en.wikipedia.org/wiki/Solid_%28Object_Oriented_Design%29 SOLID] principles of object oriented design which is an acronym for the five basic class design principles and relates to many object oriented design principles. The basic idea behind the object oriented design principles is to create and apply proper [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstractions]. Based on a paper from 1994 the principle states,

<pre>
"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.".
</pre>

This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider implements LocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Postcondition postconditions] cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

SelectiveCountingList<T> implements List<T> {
...
public boolean contains(T element) {
this.remove(t)
// -- Wait! I can't do that, a postcondition to calling contains is that the list is unmodified.
// The removal of this postcondition in this list would mean this class has less postconditions then the parent.
// This is not good!
...
}
...
}

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

class Rectangle {
private double width;
private double height;

public Rectangle(double width, double height) {
this.width = width;
this.height = height;
}

public double getWidth() {return this.width;}
public double getHeight() {return this.height;}

public double setWidth(int width) {this.width= width;}
public double setHeight(int height) {this.height = height;}
}

class Square extends Rectangle {
private double width;
private double height;

public Square(double side) {
super(side, side);
}

public double setSide(int side) {
super.setWidth(side);
super.setHeight(side);
}
}

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be substituted for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T01:39:27Z

Stphung: /* Postconditions */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:47:58Z

Stphung: /* Definition */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:47:13Z

Stphung: /* Preconditions */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:46:28Z

Stphung: /* Postconditions */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:45:32Z

Stphung: /* Conclusion */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:44:04Z

Stphung: /* Definition */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:31:53Z

Stphung: /* Definition */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states,

<pre>
"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.".
</pre>

This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Postcondition postconditions] cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be exchanged for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:31:35Z

Stphung: /* Definition */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states,

"Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.".

This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Postcondition postconditions] cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be exchanged for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:27:22Z

Stphung: /* Postconditions */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Postcondition postconditions] cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be exchanged for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:27:02Z

Stphung: /* Preconditions */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Precondition preconditions] cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be exchanged for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:25:41Z

Stphung: /* Preconditions */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be exchanged for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-19T00:24:53Z

Stphung: /* Conclusion */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
The Liskov substitution principle is a guideline on subtyping existing classes. The purpose of Liskov substitution is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be exchanged for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:59:18Z

Stphung: /* Conclusion */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
The point of the Liskov substitution principle is to ensure that subtypes adhere to their contracts.

Concisely:
*Subtypes must not require anymore preconditions as it violates the contract they are based on.
*Subtypes must have at least the same set of postconditions to adhere to the contract they are based on.
*Subtypes must have the same invariants to ensure consistency.

Using these properties subtypes can be exchanged for base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:47:49Z

Stphung:

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

?

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. In other words, properties that are assumed to be true must always remain true. This property lends itself to being self explained by the quality of correctness. Take for instance this example in Java which illustrates this point.

<pre>

Rectangle/Square example

</pre>

=Conclusion=
Have subtypes be substitutable for their base types.

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:44:14Z

Stphung: /* Conclusion */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. <Explain in english>

=Conclusion=

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:44:02Z

Stphung: /* Liskov substitution principle */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. <Explain in english>

==Conclusion==

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:43:36Z

Stphung:

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot have fewer postconditions than the parent. This makes sense because if the subtype did not at least adhere to the postconditions of the parent, it could not be substituted for it simply because postconditions we assumed to be true would not be. Take for instance this example in Java which illustrates this point.

<pre>

</pre>

==Invariants==
When dealing with Liskov substitution, [http://en.wikipedia.org/wiki/Invariant invariants] must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:33:21Z

Stphung: /* Definition */

= Liskov substitution principle =
== Definition ==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. Plainly, we want subtypes to be substitutable for their base types as Robert Martin put it. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot require any less postconditions than the parent. <CONTINUE HERE>

==Invariants==
Invariants must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:32:23Z

Stphung:

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:31:49Z

Stphung:

= Liskov substitution principle =
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more
* than what the interface requires which
* violates this principle. Doing this would mean others
* would need to know that the underlying implementation
* of a LocationProvider is a GpsLocation provider and
* to get a GPS fix if so before calling getLocation(),
* we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot require any less postconditions than the parent. <CONTINUE HERE>

==Invariants==
Invariants must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T21:29:01Z

Stphung: /* References */

= Liskov substitution principle =
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more than what the interface requires which
* violates this principle. Doing this would mean others would need to know that the underlying
* implementation of a LocationProvider is a GpsLocation provider and to get a GPS fix if so before
* calling getLocation(), we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot require any less postconditions than the parent. <CONTINUE HERE>

==Invariants==
Invariants must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/
*http://www.davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T18:29:40Z

Stphung: /* Preconditions */

= Liskov substitution principle =
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

interface LocationProvider {
/**
*
* Preconditions: None
*
*/
public void getLocation();
}

class GpsLocationProvider {

/**
*
* Preconditions: A GPS fix must be present. -- Wait! I can't do that because I would be requiring more than what the interface requires which
* violates this principle. Doing this would mean others would need to know that the underlying
* implementation of a LocationProvider is a GpsLocation provider and to get a GPS fix if so before
* calling getLocation(), we don't want that!
*
*/
public void getLocation() {
...
}
}

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot require any less postconditions than the parent. <CONTINUE HERE>

==Invariants==
Invariants must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T09:18:59Z

Stphung: /* Liskov substitution principle */

= Liskov substitution principle =
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

Example code here

</pre>

==Postconditions==
When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot require any less postconditions than the parent. <CONTINUE HERE>

==Invariants==
Invariants must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T09:15:53Z

Stphung: /* Liskov substitution principle */

= Liskov substitution principle =
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. The following example in Java illustrates the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. This is fairly intuitive, in other words, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

Example code here

</pre>

==Postconditions==
Postconditions cannot be weakened. <Explain in english>

==Invariants==
Invariants must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T09:15:33Z

Stphung: /* Preconditions */

= Liskov substitution principle =
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. The following example in Java illustrates the the principle.

<pre>

public class MyClass {
private final List<String> list;

public MyClass(List<String> list) {
this.list = list;
}
....
}

public class TestRunner {
public static void main ( String[] args ) {
// If the List type follows Liskov substitution...
List<String> arrayList = new ArrayList<String>();
List<String> linkedList = new LinkedList<String>();

// ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
MyClass this = new MyClass(arrayList);
MyClass works = new MyClass(linkedList);
}
}

</pre>

==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened. This is fairly intuitive, in other words, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.

<pre>

Example code here

</pre>

==Postconditions==
Postconditions cannot be weakened. <Explain in english>

==Invariants==
Invariants must be preserved. <Explain in english>

=References=
*http://en.wikipedia.org/wiki/Liskov_substitution_principle
*http://javaboutique.internet.com/tutorials/JavaOO/
*http://www.codingefficiency.com/2009/07/21/solid-l-liskov-substitution-principle/

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T09:10:17Z

Stphung: /* Liskov substitution principle */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T09:06:22Z

Stphung: /* Liskov substitution principle */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T09:05:04Z

Stphung: /* Liskov substitution principle */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T09:04:34Z

Stphung: /* Liskov substitution principle */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T08:56:58Z

Stphung: /* Liskov substitution principle */

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T08:53:46Z

Stphung:

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T08:53:32Z

Stphung:

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T08:50:56Z

Stphung:

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T08:50:24Z

Stphung:

= Liskov substitution principle =

==The Principle==
The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same.

==Preconditions==
Preconditions cannot be strengthened. <Explain in english>
<Example>

==Postconditions==
Postconditions cannot be weakened. <Explain in english>

==Invariants==
Invariants must be preserved. <Explain in english>

CSC/ECE 517 Fall 2009/wiki3 20 i7

2009-11-18T07:54:07Z

Stphung:

Liskov Substitution Principle

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T05:08:47Z

Stphung: /* Problem */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Serializable] interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:57:24Z

Stphung: /* Conclusion */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

Using the serialization proxy pattern brings a two important benefits to the table when dealing with serialization of immutable classes. First, serialization is made possible for classes where a no argument constructor in the superclass would be needed without losing immutability of classes that may already be in place. Second, the usage of serialization proxy pattern is completely transparent to the clients of the class, they do not ever need to know that there is a serialization proxy.

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:53:37Z

Stphung: /* Serialization Proxy Pattern */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== Conclusion ==

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:53:19Z

Stphung: /* Idiomatic Usage */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as private, static, and final. The reason the class is declared private is because it should not be visible to anyone other then the enclosing class, static is because it should not share any instance variables with the parent, and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:52:28Z

Stphung: /* Idiomatic Usage */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The idiom for implementing serialization proxy pattern is using an inner class that is declared as static and final. The reason the class is declared static is because it should not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:51:35Z

Stphung: /* References */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The usual way this is implemented is using an inner class that is declared as static and final. The reason the class is declared static is because it should not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

4. [http://en.wikipedia.org/wiki/Immutable_object Wikipedia - Immutable object]

5. [http://en.wikipedia.org/wiki/Serialization Wikipedia - Serialization]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:50:13Z

Stphung: /* References */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The usual way this is implemented is using an inner class that is declared as static and final. The reason the class is declared static is because it should not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== References ==
1. [http://java.sun.com/j2se/1.4.2/docs/api/java/io/Serializable.html Java API - Serializable]

2. [http://www.jguru.com/faq/view.jsp?EID=251942 jGuru - Are classes that implement Serializable required to have no-argument constructors?]

3. [http://java.sun.com/docs/books/effective/ Effective Java]

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:41:41Z

Stphung: /* Idiomatic Usage */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The usual way this is implemented is using an inner class that is declared as static and final. The reason the class is declared static is because it should not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== References ==
Java API
Jguru
Effective Java

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:40:15Z

Stphung: /* Idiomatic Usage */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The usual way this is implemented is using an inner class that is declared as static and final. The reason the class is declared static is because it does not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. This is a good thing because we don't want users of this class to have to deal with the serialization proxy. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== References ==
Java API
Jguru
Effective Java

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:39:22Z

Stphung: /* Serialization Proxy Pattern */

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The usual way this is implemented is using an inner class that is declared as static and final. The reason the class is declared static is because it does not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. An example of this structure is the following.

<pre>
public class MyClass implements Serializable {
...
private static final SerializationProxy implements Serializable {
...
}
}
</pre>

== References ==
Java API
Jguru
Effective Java

CSC/ECE 517 Fall 2009/wiki2 18 i7

2009-10-09T04:37:49Z

Stphung:

= Serialization Proxy Pattern =

== Problem ==
When designing a class, it is preferred to have them be [http://en.wikipedia.org/wiki/Immutable_object immutable] because of guaranteed thread safety and consistent object state. An immutable class is one where the state cannot be modified after it is instantiated.

A problem arises in Java when needing a class to be [http://en.wikipedia.org/wiki/Serialization serializable]. In order to have a class be serializable the Serializable interface must be implemented. A class that is serializable is one that can be represented on disk as a sequence of bits. The reason this is a problem is not on serialization, but rather on deserialization. During deserialization of a class, Java requires that the first non-serializable superclass have a no-argument constructor. Java uses this constructor to instantiate the object and populate the fields. This may be the case if the superclass is one that is immutable. The answer here in most cases would be to make the class and superclass mutable and provide a no argument constructor in the superclass. Serialization proxy pattern aims to solve this problem.

== Design ==
The idea behind the serialization proxy pattern is simple. On serialization, instead of having to remove the immutability that exists in the superclass and the class that needs to be serialized, a proxy class is serialized instead of the target class. A proxy class in this context would be a class where enough information is stored in it to reconstruct the target class. On deserialization, instead of returning an instance of the proxy class, the target class is instantiated with the information provided by the proxy class and returned in place of it. The following diagram shows the design of what happens on serialization and deserialization.

[[Image:i718design.png]]

== Implementation Details ==
During serialization there is a method that Java looks for which is called writeReplace. If writeReplace exists, the value returned from this method will be serialized in place of the current class. This is where we would return a proxy object which stores enough information to reconstruct what we actually want to serialize. An example of an implementation of writeReplace can be identified in the following code snippet. In brief, there is a simple class called MyClass which holds a single integer value and there is an inner class SerializationProxy. The SerializationProxy class used as the serialization proxy object in the writeReplace method when serializing instances of MyClass.

<pre>
public class MyClass implements Serializable {
private final int value;

public MyClass(int value) {
this.value = value;
}

public int getValue() {
return this.value;
}

private Object writeReplace() {
return new SerializationProxy(this);
}

private static final class SerializationProxy implements Serializable {
private final int value;

public SerializationProxy(MyClass myClass) {
this.value = myClass.getValue();
}
}
}
</pre>

During deserialization there is a method that Java looks for which is called readResolve. If readResolve exists, the value returned from this method will instead be the result of the deserialization of this object. This method would be implemented in the proxy class and the constructor for the class we want to reconstruct would be invoked and returned as the value returned by readResolve. An example implementation of readResolve would be the following which would be added inside of the SerializationProxy class from the previous example.

<pre>
private Object readResolve() {
return new MyClass(this.value);
}
</pre>

== Idiomatic Usage ==
The usual way this is implemented is using an inner class that is declared as static and final. The reason the class is declared static is because it does not share any instance variables with the parent and final because this class should never be extended. Additionally since the class is hidden because it is an inner class, the serialization proxy used will be transparent to all users of this class regarding serialization. An example of this structure is the following.

<nowiki>
public class B extends A {
...
private static final BSerializationProxy {
...
}
}
</nowiki>

== References ==
Java API
Jguru
Effective Java