Restrict Mutability of State - Revision history

Kevlin at 14:05, 24 June 2009

Kevlin — Wed, 24 Jun 2009 14:05:02 GMT

←Older revision		Revision as of 14:05, 24 June 2009
Line 7:		Line 7:
	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being given the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.		Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being given the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.

-	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Declare a variable as close to its point of use as possible. For local variables, declare as late as possible, only when a variable can be sensibly initialised. For variables with longer lifetimes, improving locality reduces the scope for change. Global data has the broadest scope possible. Keep in mind that public class-wide variables — <code>static</code>s in many languages — are simply globals with scope etiquette.	+	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Declare a variable as close to its point of use as possible. For local variables, declare as late as possible, only when a variable can be sensibly initialised. For variables with longer lifetimes, improving locality reduces the scope for change. Global data has the broadest scope possible. Keep in mind that public class-wide variables — <code>static</code> variables in many languages — are simply globals with scope etiquette.

	Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.		Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.

Kevlin at 14:03, 24 June 2009

Kevlin — Wed, 24 Jun 2009 14:03:30 GMT

←Older revision		Revision as of 14:03, 24 June 2009
Line 1:		Line 1:
	What appears at first to be a trivial observation turns out to be a subtly important one: a large number software defects arise from the (incorrect) modification of state. It follows from this that if there is less opportunity for code to change state, there will be fewer defects that arise from state change.		What appears at first to be a trivial observation turns out to be a subtly important one: a large number software defects arise from the (incorrect) modification of state. It follows from this that if there is less opportunity for code to change state, there will be fewer defects that arise from state change.

-	Perhaps the most obvious example of restricting mutability is its most complete realization: immutability. A moratorium on state change is an idea carried to its logical conclusion in functional programming, but even its modest application in the context of other programming models has a simplifying effect. If an object is immutable it can be shared freely across different parts of a program without concern for aliasing or synchronization problems. An object that does not change state is inherently thread-safe — there is no need to synchronize state change if there is no state change. An immutable object does not need locking or any other palliative workaround to achieve safety. Immutability is particularly suitable for value objects in languages that favor predominantly reference-based semantics. For example, Java's <code>String</code> class represents objects that are essentially immutable — if you want another string value, you use another string object.	+	Perhaps the most obvious example of restricting mutability is its most complete realization: immutability. A moratorium on state change is an idea carried to its logical conclusion in pure functional programming languages such as Haskell, but even its modest application in the context of other programming models has a simplifying effect. If an object is immutable it can be shared freely across different parts of a program without concern for aliasing or synchronization problems. An object that does not change state is inherently thread-safe — there is no need to synchronize state change if there is no state change. An immutable object does not need locking or any other palliative workaround to achieve safety.

-	~~A related approach to~~ immutability is through ~~qualification, such as~~ the <code>const</code> ~~feature~~ found in C++ and ~~D. Object usage can be constrained with respect to~~ the mutability ~~declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified~~. In C++ ~~and D~~ <code>const</code> qualification typically ~~expresses~~ the notion of read-only~~, which is clearly a restriction on mutability, but D also offers <code>immutable</code> for declaring~~ full immutability.	+	Depending on the language and the idiom, immutability can be expressed in the definition of a type or through the declaration of a variable. For example, Java's <code>String</code> class represents objects that are essentially immutable — if you want another string value, you use another string object. Immutability is particularly suitable for value objects in languages that favor predominantly reference-based semantics. The <code>const</code> qualifier found in C and C++ and the <code>immutable</code> qualifier in D constrain mutability through declaration. In C++ <code>const</code> qualification restricts mutability in terms of access rights, typically expressing the notion of read-only access and not necessarily full immutability.

	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being given the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.		Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being given the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.

-	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Declare a variable as close to its point of use as possible. For local variables, declare as late as possible, only when a variable can be sensibly initialised. For variables with longer lifetimes, improving locality reduces the scope for change. Global data has the broadest scope possible. Keep in mind that public class-wide variables are simply globals with scope etiquette.	+	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Declare a variable as close to its point of use as possible. For local variables, declare as late as possible, only when a variable can be sensibly initialised. For variables with longer lifetimes, improving locality reduces the scope for change. Global data has the broadest scope possible. Keep in mind that public class-wide variables — <code>static</code>s in many languages — are simply globals with scope etiquette.

	Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.		Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.

Kevlin at 08:54, 17 January 2009

Kevlin — Sat, 17 Jan 2009 08:54:58 GMT

←Older revision		Revision as of 08:54, 17 January 2009
Line 5:		Line 5:
	A related approach to immutability is through qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified. In C++ and D <code>const</code> qualification typically expresses the notion of read-only, which is clearly a restriction on mutability, but D also offers <code>immutable</code> for declaring full immutability.		A related approach to immutability is through qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified. In C++ and D <code>const</code> qualification typically expresses the notion of read-only, which is clearly a restriction on mutability, but D also offers <code>immutable</code> for declaring full immutability.

-	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.	+	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being given the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.

	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Declare a variable as close to its point of use as possible. For local variables, declare as late as possible, only when a variable can be sensibly initialised. For variables with longer lifetimes, improving locality reduces the scope for change. Global data has the broadest scope possible. Keep in mind that public class-wide variables are simply globals with scope etiquette.		Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Declare a variable as close to its point of use as possible. For local variables, declare as late as possible, only when a variable can be sensibly initialised. For variables with longer lifetimes, improving locality reduces the scope for change. Global data has the broadest scope possible. Keep in mind that public class-wide variables are simply globals with scope etiquette.

Kevlin at 15:55, 22 November 2008

Kevlin — Sat, 22 Nov 2008 15:55:01 GMT

←Older revision		Revision as of 15:55, 22 November 2008
Line 1:		Line 1:
	What appears at first to be a trivial observation turns out to be a subtly important one: a large number software defects arise from the (incorrect) modification of state. It follows from this that if there is less opportunity for code to change state, there will be fewer defects that arise from state change.		What appears at first to be a trivial observation turns out to be a subtly important one: a large number software defects arise from the (incorrect) modification of state. It follows from this that if there is less opportunity for code to change state, there will be fewer defects that arise from state change.

-	Perhaps the most obvious example of restricting mutability is its most complete realization: immutability. A moratorium on state change is an idea carried to its logical conclusion in functional programming, but even its modest application in the context of other programming models has a simplifying effect. If an object is immutable it can be shared freely across different parts of a program without concern for aliasing or synchronization problems. An object that does not change state is inherently thread-safe -- there is no need to synchronize state change if there is no state change. An immutable object does not need locking or any other palliative workaround to achieve safety. Immutability is particularly suitable for value objects in languages that favor predominantly reference-based semantics. For example, Java's <code>String</code> class represents objects that are essentially immutable -- if you want another string value, you use another string object.	+	Perhaps the most obvious example of restricting mutability is its most complete realization: immutability. A moratorium on state change is an idea carried to its logical conclusion in functional programming, but even its modest application in the context of other programming models has a simplifying effect. If an object is immutable it can be shared freely across different parts of a program without concern for aliasing or synchronization problems. An object that does not change state is inherently thread-safe — there is no need to synchronize state change if there is no state change. An immutable object does not need locking or any other palliative workaround to achieve safety. Immutability is particularly suitable for value objects in languages that favor predominantly reference-based semantics. For example, Java's <code>String</code> class represents objects that are essentially immutable — if you want another string value, you use another string object.

	A related approach to immutability is through qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified. In C++ and D <code>const</code> qualification typically expresses the notion of read-only, which is clearly a restriction on mutability, but D also offers <code>immutable</code> for declaring full immutability.		A related approach to immutability is through qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified. In C++ and D <code>const</code> qualification typically expresses the notion of read-only, which is clearly a restriction on mutability, but D also offers <code>immutable</code> for declaring full immutability.

Kevlin at 09:00, 21 November 2008

Kevlin — Fri, 21 Nov 2008 09:00:18 GMT

←Older revision		Revision as of 09:00, 21 November 2008
Line 1:		Line 1:
	What appears at first to be a trivial observation turns out to be a subtly important one: a large number software defects arise from the (incorrect) modification of state. It follows from this that if there is less opportunity for code to change state, there will be fewer defects that arise from state change.		What appears at first to be a trivial observation turns out to be a subtly important one: a large number software defects arise from the (incorrect) modification of state. It follows from this that if there is less opportunity for code to change state, there will be fewer defects that arise from state change.

-	Perhaps the most obvious example of restricting mutability is its most complete realization: immutability. A moratorium on state change is an idea carried to its logical conclusion in functional programming, but even its modest application in the context of other programming models has a simplifying effect. If an object is immutable it can be shared freely across different parts of a program without concern for aliasing or synchronization problems. An object that does not change state is inherently thread-safe -- there is no need to synchronize state change if there is no state change. An immutable object does not need locking or any other palliative workaround to achieve safety. Immutability is particularly suitable for value objects in languages that favor predominantly reference-based semantics. For example, Java's <code>String</code> class is essentially immutable -- if you want another string value, you use another string object.	+	Perhaps the most obvious example of restricting mutability is its most complete realization: immutability. A moratorium on state change is an idea carried to its logical conclusion in functional programming, but even its modest application in the context of other programming models has a simplifying effect. If an object is immutable it can be shared freely across different parts of a program without concern for aliasing or synchronization problems. An object that does not change state is inherently thread-safe -- there is no need to synchronize state change if there is no state change. An immutable object does not need locking or any other palliative workaround to achieve safety. Immutability is particularly suitable for value objects in languages that favor predominantly reference-based semantics. For example, Java's <code>String</code> class represents objects that are essentially immutable -- if you want another string value, you use another string object.

-	A related ~~solution based on partial~~ immutability is qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified.	+	A related approach to immutability is through qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified. In C++ and D <code>const</code> qualification typically expresses the notion of read-only, which is clearly a restriction on mutability, but D also offers <code>immutable</code> for declaring full immutability.

	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.		Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.

Kevlin at 13:14, 22 October 2008

Kevlin — Wed, 22 Oct 2008 13:14:20 GMT

←Older revision		Revision as of 13:14, 22 October 2008
Line 10:		Line 10:

	Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.		Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.
-

	By [[Kevlin Henney]]		By [[Kevlin Henney]]

-	This work is licensed under a	+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]	+



	Back to [[97 Things Every Programmer Should Know]] home page		Back to [[97 Things Every Programmer Should Know]] home page

Kevlin at 21:12, 14 October 2008

Kevlin — Tue, 14 Oct 2008 21:12:55 GMT

←Older revision		Revision as of 21:12, 14 October 2008
Line 5:		Line 5:
	A related solution based on partial immutability is qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified.		A related solution based on partial immutability is qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified.

-	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. ~~Consider an object holding another object by value as~~ a ~~field. A query that leads to the return~~ of that ~~field does not have to take any special measures to protect the value if it is returned by copy:~~ the caller ~~will have its own copy~~ and cannot ~~modify the internal state of the originating object~~. ~~Note~~ that to be effective for values copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.	+	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Passing or returning a copy of a value object ensures that the caller and callee cannot interfere with one another's view a value. But note that to be effective for values, copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.

-	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. ~~Rather than declare~~ a ~~local~~ variable ~~at the top~~ of ~~a function or method long before it is used or can be properly initialized~~, declare it as late as possible ~~in as narrow~~ a scope ~~as possible~~. Global ~~variables have~~ the broadest scope possible ~~and are a problem for just this reason~~. ~~What qualifies as global is not just restricted to classic global variables~~ in ~~procedural languages, but applies also to~~ class~~- or module~~-wide variables ~~that offer some form of public access~~.	+	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Declare a variable as close to its point of use as possible. For local variables, declare as late as possible, only when a variable can be sensibly initialised. For variables with longer lifetimes, improving locality reduces the scope for change. Global data has the broadest scope possible. Keep in mind that public class-wide variables are simply globals with scope etiquette.

	Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.		Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.

Kevlin at 18:57, 27 September 2008

Kevlin — Sat, 27 Sep 2008 18:57:05 GMT

←Older revision		Revision as of 18:57, 27 September 2008
Line 1:		Line 1:
-	~~TBD~~	+	What appears at first to be a trivial observation turns out to be a subtly important one: a large number software defects arise from the (incorrect) modification of state. It follows from this that if there is less opportunity for code to change state, there will be fewer defects that arise from state change.
		+
		+	Perhaps the most obvious example of restricting mutability is its most complete realization: immutability. A moratorium on state change is an idea carried to its logical conclusion in functional programming, but even its modest application in the context of other programming models has a simplifying effect. If an object is immutable it can be shared freely across different parts of a program without concern for aliasing or synchronization problems. An object that does not change state is inherently thread-safe -- there is no need to synchronize state change if there is no state change. An immutable object does not need locking or any other palliative workaround to achieve safety. Immutability is particularly suitable for value objects in languages that favor predominantly reference-based semantics. For example, Java's <code>String</code> class is essentially immutable -- if you want another string value, you use another string object.
		+
		+	A related solution based on partial immutability is qualification, such as the <code>const</code> feature found in C++ and D. Object usage can be constrained with respect to the mutability declared for accessing the object. The set of operations on a qualified object is restricted to those that are similarly qualified.
		+
		+	Perhaps a little counterintuitively, copying offers a complementary technique for restricting mutability. In languages offering a transparent syntax for passing by copy, such as C#'s <code>struct</code> objects and C++, copying value objects can greatly improve encapsulation and reduce opportunities for unnecessary and unintended state change. Consider an object holding another object by value as a field. A query that leads to the return of that field does not have to take any special measures to protect the value if it is returned by copy: the caller will have its own copy and cannot modify the internal state of the originating object. Note that to be effective for values copying requires a transparent passing syntax: if the programmer has to make special efforts to remember to make the copy, such as explicitly call a clone method, they are also being the opportunity to forget to do it. It becomes a complication that is easy to overlook rather than a simplification.
		+
		+	Another way to restrict the mutability of state is to reduce the scope in which it is accessed. Rather than declare a local variable at the top of a function or method long before it is used or can be properly initialized, declare it as late as possible in as narrow a scope as possible. Global variables have the broadest scope possible and are a problem for just this reason. What qualifies as global is not just restricted to classic global variables in procedural languages, but applies also to class- or module-wide variables that offer some form of public access.
		+
		+	Of course, this is not some kind of silver bullet with which to shoot down all defects, but restricting the mutability of state offers a guideline that can help to reduce the incidence of defects through improved encapsulation and code simplification.
		+

	By [[Kevlin Henney]]		By [[Kevlin Henney]]

Kevlin: New page: TBD By Kevlin Henney This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] Back to [[97 Things Every Programmer Should Kno...

Kevlin — Sat, 27 Sep 2008 14:35:16 GMT

New page: TBD By Kevlin Henney This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] Back to [[97 Things Every Programmer Should Kno...

New page

TBD

By [[Kevlin Henney]]

This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

Back to [[97 Things Every Programmer Should Know]] home page