Minimize number of methods
From CSSEMediaWiki
(Difference between revisions)
WarwickIrwin (Talk | contribs) m (Noted opposing force) |
Jenny Harlow (Talk | contribs) m (added to see also links) |
||
| (One intermediate revision by one user not shown) | |||
| Line 1: | Line 1: | ||
:''Minimize the number of messages in the protocol of a class.'' --Riel's Heuristic 2.3, [[Arthur Riel 1996]] | :''Minimize the number of messages in the protocol of a class.'' --Riel's Heuristic 2.3, [[Arthur Riel 1996]] | ||
| − | This heuristic ensures that you can always find the method that you are looking for, and enhances reusability. This is tied to the idea of [[You ain't gonna need it]] - don't implement methods until you need them. | + | This heuristic ensures that you can always find the method that you are looking for, and enhances reusability. This is tied to the idea of [[You ain't gonna need it]] - don't implement methods until you need them. With recent automated documentation systems such as javadoc and Microsoft Intellisense this heuristic has become somewhat less important. Poorly documented classes with large numbers of methods can still cause a problem for people unfamiliar with them but this problem has been greatly reduced. |
| + | |||
| + | This heuristic of course only applies to public methods | ||
An opposing force is [[Behavioral completeness]]. | An opposing force is [[Behavioral completeness]]. | ||
| Line 7: | Line 9: | ||
== See also == | == See also == | ||
* [[Riel's heuristics]] | * [[Riel's heuristics]] | ||
| + | * [[Interface segregation principle]] | ||
* [[Fat interfaces]] | * [[Fat interfaces]] | ||
* [[Avoid interface bloat]] | * [[Avoid interface bloat]] | ||
Latest revision as of 03:17, 18 October 2010
- Minimize the number of messages in the protocol of a class. --Riel's Heuristic 2.3, Arthur Riel 1996
This heuristic ensures that you can always find the method that you are looking for, and enhances reusability. This is tied to the idea of You ain't gonna need it - don't implement methods until you need them. With recent automated documentation systems such as javadoc and Microsoft Intellisense this heuristic has become somewhat less important. Poorly documented classes with large numbers of methods can still cause a problem for people unfamiliar with them but this problem has been greatly reduced.
This heuristic of course only applies to public methods
An opposing force is Behavioral completeness.
