Talk:Rule of three (computer programming)

This is the talk page for discussing improvements to the Rule of three (computer programming) article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing: Software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software.

Three times? That's overkill! If the same code is used twice then it should become a procedure. SJ2571 (talk) 20:41, 9 July 2009 (UTC)[reply]

As a rule of thumb this is poor. It might have been taken out of context or misrepresented. When the portions of code being replicated are quite large it is very unlikely this rule will do any good (in my opinion).

There are some cases where it makes sense to apply such a rule but there is no compelling reason given to adopt this as a general rule for any case. An example of such a case where this rule might make sense is where two systems have a portion in common that may be changed in the future yet at least one system might not support every reasonably possible configuration of the portion supported by another. Over zealous duplicate removal can lead to a situation where a change must be made but due to an incompatibility the original process of duplicate removal must be reversed which is a waste of time. This may entail exactly the same kinds of technical complications that would be brought about by too much duplication.

This rule limits duplication it does not eliminate it. It clearly links to justification for limiting it but not for tolerating a small amount. If this article is to be balanced and useful it must include such a justification. — Preceding unsigned comment added by 212.85.4.184 (talk) 18:07, 18 August 2011 (UTC)[reply]

==

This rule is MUCH older than stated; the attribution is wrong.

My mother used to drill me with this when I was a little girl, circa 1980, so it was clearly common knowledge among programmers then. According to Amazon, Refactoring: Improving the Design of Existing Code wasn't even published until 1999. That's almost 20 years after I first heard it. There has to be a much earlier attribution that's been missed. — Preceding unsigned comment added by 98.172.76.114 (talk) 09:47, 4 August 2012 (UTC)[reply]

==

A quote about from - Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks, Don Roberts and Ralph Johnson, 1996

Every attempt to determine the correct abstractions on paper without actually developing a running system is doomed to failure. A framework is a reusable design, so you develop it by looking at the things it is supposed to be a design of. ... Develop three applications that you believe that the framework should help you build. These applications should pay for their own development. — Preceding unsigned comment added by 213.89.225.3 (talk) 10:37, 26 October 2012 (UTC)[reply]