Interfaces Should Reveal Intention - Revision history

http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&action=history&feed=atom Interfaces Should Reveal Intention - Revision history 2013-05-21T20:10:20Z Revision history for this page on the wiki MediaWiki 1.11.0 http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=24702&oldid=prev Elandre at 09:20, 8 July 2009 2009-07-08T09:20:54Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 09:20, 8 July 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 5:</td> <td colspan="2" class="diff-lineno">Line 5:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that an resturant object that contain table objects, code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime by calling <<del style="color: red; font-weight: bold; text-decoration: none;">/</del>code>resturant.setTable(new Table());</code></div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that an resturant object that contain table objects, code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime by calling <code>resturant.setTable(new Table());</code></div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not necessarily need ''setters'' for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made clear by being public and separate. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not necessarily need ''setters'' for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made clear by being public and separate. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr>  </table>

Elandre http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=24701&oldid=prev Elandre at 09:20, 8 July 2009 2009-07-08T09:20:01Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 09:20, 8 July 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 5:</td> <td colspan="2" class="diff-lineno">Line 5:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that <ins style="color: red; font-weight: bold; text-decoration: none;">an resturant object that contain table objects, </ins>code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime <ins style="color: red; font-weight: bold; text-decoration: none;">by calling </code>resturant</ins>.<ins style="color: red; font-weight: bold; text-decoration: none;">setTable(new Table());</code></ins></div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not necessarily need ''setters'' for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made clear by being public and separate. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not necessarily need ''setters'' for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made clear by being public and separate. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr>  </table>

Elandre http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=24700&oldid=prev Elandre at 09:11, 8 July 2009 2009-07-08T09:11:55Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 09:11, 8 July 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Kristen Nygaard, father of object-oriented programming and the Simula programming language, focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects, and receiving order objects.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Kristen Nygaard, father of object-oriented programming and the Simula programming language, focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects, and receiving order objects.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In this type of model we will find a restaurant object with a public interface offering methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code>, and waiter objects with methods such as <code>serveTable(<del style="color: red; font-weight: bold; text-decoration: none;">tableNumber</del>)</code> and <code>provideMenu(customer,<del style="color: red; font-weight: bold; text-decoration: none;">tableNumber</del>)</code> &mdash; object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In this type of model we will find a restaurant object with a public interface offering methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code>, and waiter objects with methods such as <code>serveTable(<ins style="color: red; font-weight: bold; text-decoration: none;">table</ins>)</code> and <code>provideMenu(customer,<ins style="color: red; font-weight: bold; text-decoration: none;">table</ins>)</code> &mdash; object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.</div></td></tr>  </table>

Elandre http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=24597&oldid=prev Kevlin at 18:30, 4 July 2009 2009-07-04T18:30:28Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 18:30, 4 July 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 7:</td> <td colspan="2" class="diff-lineno">Line 7:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and <del style="color: red; font-weight: bold; text-decoration: none;">clear</del>. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>The answer to that is that you do not <ins style="color: red; font-weight: bold; text-decoration: none;">necessarily </ins>need <ins style="color: red; font-weight: bold; text-decoration: none;">''</ins>setters<ins style="color: red; font-weight: bold; text-decoration: none;">'' </ins>for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made <ins style="color: red; font-weight: bold; text-decoration: none;">clear by being </ins>public and <ins style="color: red; font-weight: bold; text-decoration: none;">separate</ins>. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because it make the concepts of the domain stand out clearly following the principles found in natural language.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because it make the concepts of the domain stand out clearly following the principles found in natural language.</div></td></tr>  </table>

Kevlin http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=23306&oldid=prev Kevlin at 10:06, 5 February 2009 2009-02-05T10:06:50Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 10:06, 5 February 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 9:</td> <td colspan="2" class="diff-lineno">Line 9:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because it make the concepts of the domain stand out clearly following the <del style="color: red; font-weight: bold; text-decoration: none;">princicples </del>found in natural language.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because it make the concepts of the domain stand out clearly following the <ins style="color: red; font-weight: bold; text-decoration: none;">principles </ins>found in natural language.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td></tr>  </table>

Kevlin http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=23305&oldid=prev Elandre at 10:02, 5 February 2009 2009-02-05T10:02:28Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 10:02, 5 February 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 9:</td> <td colspan="2" class="diff-lineno">Line 9:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because <del style="color: red; font-weight: bold; text-decoration: none;">they </del>make the concepts of the domain stand out clearly. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because <ins style="color: red; font-weight: bold; text-decoration: none;">it </ins>make the concepts of the domain stand out clearly <ins style="color: red; font-weight: bold; text-decoration: none;">following the princicples found in natural language</ins>.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td></tr>  </table>

Elandre http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=23304&oldid=prev Elandre at 10:00, 5 February 2009 2009-02-05T10:00:15Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 10:00, 5 February 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 9:</td> <td colspan="2" class="diff-lineno">Line 9:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because the <del style="color: red; font-weight: bold; text-decoration: none;">focus is on </del>the domain. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> because <ins style="color: red; font-weight: bold; text-decoration: none;">they make </ins>the <ins style="color: red; font-weight: bold; text-decoration: none;">concepts of </ins>the domain <ins style="color: red; font-weight: bold; text-decoration: none;">stand out clearly</ins>. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td></tr>  </table>

Elandre http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=23303&oldid=prev Elandre at 09:58, 5 February 2009 2009-02-05T09:58:13Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 09:58, 5 February 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 9:</td> <td colspan="2" class="diff-lineno">Line 9:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code>.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better off just referring to queried attributes by their name, using methods named <code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are pure queries returning values are, by definition, functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code> <ins style="color: red; font-weight: bold; text-decoration: none;">because the focus is on the domain</ins>. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td></tr>  </table>

Elandre http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=23276&oldid=prev Kevlin at 11:01, 4 February 2009 2009-02-04T11:01:19Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 11:01, 4 February 2009</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Kristen Nygaard, father of object oriented programming and the Simula programming language focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects and receiving order objects.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Kristen Nygaard, father of object<ins style="color: red; font-weight: bold; text-decoration: none;">-</ins>oriented programming and the Simula programming language<ins style="color: red; font-weight: bold; text-decoration: none;">, </ins>focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects<ins style="color: red; font-weight: bold; text-decoration: none;">, </ins>and receiving order objects.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In this type of model we will find a restaurant object with a public interface methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code>, waiter objects with methods such as <code>serveTable(tableNumber)</code> and <code>provideMenu(customer,tableNumber)</code><del style="color: red; font-weight: bold; text-decoration: none;">, </del>object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In this type of model we will find a restaurant object with a public interface <ins style="color: red; font-weight: bold; text-decoration: none;">offering </ins>methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code>, <ins style="color: red; font-weight: bold; text-decoration: none;">and </ins>waiter objects with methods such as <code>serveTable(tableNumber)</code> and <code>provideMenu(customer,tableNumber)</code> <ins style="color: red; font-weight: bold; text-decoration: none;">&mdash; </ins>object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' (a.k.a. ''inversion of control'' design principle). Dependency injection has benefits as it reduces coupling and simplifies unit testing so that an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(...);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.</div></td></tr> <tr><td colspan="2" class="diff-lineno">Line 9:</td> <td colspan="2" class="diff-lineno">Line 9:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called something like <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>So what about the ''getters''? I think <del style="color: red; font-weight: bold; text-decoration: none;">personally </del>you are better <del style="color: red; font-weight: bold; text-decoration: none;">of </del>just referring to <del style="color: red; font-weight: bold; text-decoration: none;">the actual attribute</del>, using methods <del style="color: red; font-weight: bold; text-decoration: none;">such as </del><code>price<del style="color: red; font-weight: bold; text-decoration: none;">()</del></code>, <code>name<del style="color: red; font-weight: bold; text-decoration: none;">()</del></code>, and <code>timePoint<del style="color: red; font-weight: bold; text-decoration: none;">()</del></code>. Methods that <del style="color: red; font-weight: bold; text-decoration: none;">return attributes </del>are by definition functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code>.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>So what about the ''getters''? I think you are better <ins style="color: red; font-weight: bold; text-decoration: none;">off </ins>just referring to <ins style="color: red; font-weight: bold; text-decoration: none;">queried attributes by their name</ins>, using methods <ins style="color: red; font-weight: bold; text-decoration: none;">named </ins><code>price</code>, <code>name</code>, and <code>timePoint</code>. Methods that are <ins style="color: red; font-weight: bold; text-decoration: none;">pure queries returning values are, </ins>by definition<ins style="color: red; font-weight: bold; text-decoration: none;">, </ins>functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code>.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should try to avoid using them; there are better alternatives.</div></td></tr>  </table>

Kevlin http://commons.oreilly.com/wiki/index.php?title=Interfaces_Should_Reveal_Intention&diff=21669&oldid=prev Kevlin at 15:43, 22 November 2008 2008-11-22T15:43:00Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 15:43, 22 November 2008</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Kristen Nygaard, father of object oriented programming and the Simula programming language focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects and receiving order objects.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Kristen Nygaard, father of object oriented programming and the Simula programming language focused in his lectures on how to use objects to model the behavior of the real world and on how objects interacted to get a piece of work done. His favorite example was Cafe Objecta, where waiter objects served the appetites of hungry customer objects by allocating seating at table objects, providing menu objects and receiving order objects.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In this type of model we will find a restaurant object with a public interface methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code>, waiter objects with methods such as <code>serveTable(tableNumber)</code> and <code>provideMenu<del style="color: red; font-weight: bold; text-decoration: none;"><</del>customer,tableNumber)</code>, object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In this type of model we will find a restaurant object with a public interface methods such as <code>reserveTable(numberOfSeats,customer,timePoint)</code> and <code>availableTables(numberOfSeats,timePoint)</code>, waiter objects with methods such as <code>serveTable(tableNumber)</code> and <code>provideMenu<ins style="color: red; font-weight: bold; text-decoration: none;">(</ins>customer,tableNumber)</code>, object interfaces that reveal each object's intent and responsibility in terms of the domain at hand.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So, where are the ''setters'' and ''getters'' so often found dominating our object models? They are not here as they do not add value to the behavioral intention and expression of object responsibility. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' a.k.a. ''inversion of control'' design principle. Dependency injection <del style="color: red; font-weight: bold; text-decoration: none;">is a good thing </del>as it <del style="color: red; font-weight: bold; text-decoration: none;">provide reduced </del>coupling and <del style="color: red; font-weight: bold; text-decoration: none;">simplified </del>unit testing <del style="color: red; font-weight: bold; text-decoration: none;">as </del>an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(..);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Some might then argue that we need setters to support ''dependency injection'' <ins style="color: red; font-weight: bold; text-decoration: none;">(</ins>a.k.a. ''inversion of control'' design principle<ins style="color: red; font-weight: bold; text-decoration: none;">)</ins>. Dependency injection <ins style="color: red; font-weight: bold; text-decoration: none;">has benefits </ins>as it <ins style="color: red; font-weight: bold; text-decoration: none;">reduces </ins>coupling and <ins style="color: red; font-weight: bold; text-decoration: none;">simplifies </ins>unit testing <ins style="color: red; font-weight: bold; text-decoration: none;">so that </ins>an object can be tested using a mock-up of a dependency. At the code level this mean that code such as <code>Table table = new TableImpl(<ins style="color: red; font-weight: bold; text-decoration: none;">.</ins>..);</code> can be replaced with <code>Table table;</code> and then initialized from the outside at runtime.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called <code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>The answer to that is that you do not need setters for that. Either you use the constructor or, even better, create an interface in an appropriate package called <ins style="color: red; font-weight: bold; text-decoration: none;">something like </ins><code>ExternalInjections</code> with methods prefixed with <code>initializeAttributeName(AttributeType)</code>. Again the intention of the interface has been made public and clear. An interface designed to support the use of a specific design principle or the intent of frameworks such as Spring.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So what about the ''getters''? I think personally you are better of just referring to the actual attribute, using methods such as <code>price()</code>, <code>name()</code>, and <code>timePoint()</code>. Methods that return attributes are by definition functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code>.</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>So what about the ''getters''? I think personally you are better of just referring to the actual attribute, using methods such as <code>price()</code>, <code>name()</code>, and <code>timePoint()</code>. Methods that return attributes are by definition functions and read better if they are direct: <code>item.price()</code> reads better than <code>item.getPrice()</code>.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should avoid using them<del style="color: red; font-weight: bold; text-decoration: none;">, </del>there are better alternatives.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>The conclusion on this is that setters and getters are alien constructs that do not reveal the intention and responsibility of a behavior-centric interface. Therefore you should <ins style="color: red; font-weight: bold; text-decoration: none;">try to </ins>avoid using them<ins style="color: red; font-weight: bold; text-decoration: none;">; </ins>there are better alternatives.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>By [[Einar Landre]]</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>By [[Einar Landre]]</div></td></tr>  </table>

Kevlin