From 107d9dd385e4a6cfd4b7a5a248cea2cf26809b3b Mon Sep 17 00:00:00 2001 From: otoburb Date: Thu, 24 Mar 2011 04:48:48 +0000 Subject: [PATCH] Tuple subclassing help article: Fixed typo --- core/classes/tuple/tuple-docs.factor | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/classes/tuple/tuple-docs.factor b/core/classes/tuple/tuple-docs.factor index 6de3ed2957..6587889de6 100644 --- a/core/classes/tuple/tuple-docs.factor +++ b/core/classes/tuple/tuple-docs.factor @@ -175,7 +175,7 @@ $nl $nl "There are two alternatives which are preferred to subclassing in this case. The first is " { $link "mixins" } "." $nl -"The second is to use ad-hoc slot polymorphism. If two classes define a slot with the same name, then code which uses " { $link "accessors" } " can operate on instances of both objects, assuming the values stored in that slot implement a common protocol. This allows code to be shared without creating contrieved relationships between classes." +"The second is to use ad-hoc slot polymorphism. If two classes define a slot with the same name, then code which uses " { $link "accessors" } " can operate on instances of both objects, assuming the values stored in that slot implement a common protocol. This allows code to be shared without creating contrived relationships between classes." { $heading "Anti-pattern #3: subclassing to override a method definition" } "While method overriding is a very powerful tool, improper use can cause tight coupling of code and lead to difficulty in testing and refactoring. Subclassing should not be used as a means of “monkey patching” methods to fix bugs and add features. Only subclass from classes which were designed to be inherited from, and when writing classes of your own which are intended to be subclassed, clearly document what subclasses may and may not do. This includes construction policy; document whether subclasses should use " { $link new } ", " { $link boa } ", or a custom parametrized constructor." { $see-also "parametrized-constructors" } ;