Comments on: Abstraction: The Rule Of Three http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/ Better Than Yesterday Fri, 17 May 2013 03:30:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: UKB http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2943 UKB Sun, 16 Dec 2012 23:48:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2943 1, 2, 3 could be add the previous two numbers together so that isn't completely accurate either 1, 2, 3 could be add the previous two numbers together so that isn’t completely accurate either

]]> By: Andrew Young http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2829 Andrew Young Mon, 05 Nov 2012 21:36:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2829 Two points make a line. Third point validates it. Two points make a line. Third point validates it.

]]> By: Dan Sutton http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2826 Dan Sutton Fri, 02 Nov 2012 16:03:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2826 There's something missing here, and that's the concept of what the code is going to be used for, and, more importantly, how it's going to be called. Here's an example of what I'm talking about: imagine you've got a class which ships packages via the US Mail, and another one which ships packages via FedEx. Conceptually, they're going to be similar; internally they're going to be different. Now, if different software is going to use each class, then it's OK to keep them separated with occasional duplication. But if you're going to create something which expects an object of type "shipper" then you're going to want to make an abstract class (or an interface) which contains empty methods to perform any shipper function, and subclass the US Mail and FedEx classes from it. Of course, you're going to find parts which contain identical code, and by all means, those parts should be defined in the abstract superclass. But my point is that any decision you make about how to abstract the code should be informed by the requirements of what's going to call it. It's all very well to throw things around like DRY and YAGNI, but in the end, what counts is common sense. There’s something missing here, and that’s the concept of what the code is going to be used for, and, more importantly, how it’s going to be called.

Here’s an example of what I’m talking about: imagine you’ve got a class which ships packages via the US Mail, and another one which ships packages via FedEx. Conceptually, they’re going to be similar; internally they’re going to be different.

Now, if different software is going to use each class, then it’s OK to keep them separated with occasional duplication. But if you’re going to create something which expects an object of type “shipper” then you’re going to want to make an abstract class (or an interface) which contains empty methods to perform any shipper function, and subclass the US Mail and FedEx classes from it. Of course, you’re going to find parts which contain identical code, and by all means, those parts should be defined in the abstract superclass.

But my point is that any decision you make about how to abstract the code should be informed by the requirements of what’s going to call it. It’s all very well to throw things around like DRY and YAGNI, but in the end, what counts is common sense.

]]> By: imnotsayinimjustsayin http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2825 imnotsayinimjustsayin Fri, 02 Nov 2012 15:03:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2825 1,2,3,1,5,7,1,11,13,... 1,2,3,1,5,7,1,11,13,…

]]> By: joshuaflanagan http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2824 joshuaflanagan Fri, 02 Nov 2012 14:07:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2824 One could certainly do some mental gymnastics to make the situation fit the definition, but it only dilutes the intent of the DRY principle. I think what you are looking for is Once and Only Once: http://c2.com/xp/OnceAndOnlyOnce.html One could certainly do some mental gymnastics to make the situation fit the definition, but it only dilutes the intent of the DRY principle.
I think what you are looking for is Once and Only Once:
http://c2.com/xp/OnceAndOnlyOnce.html

]]> By: Alejandro Varela http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2823 Alejandro Varela Fri, 02 Nov 2012 13:53:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2823 damn true damn true

]]> By: Mark http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2822 Mark Fri, 02 Nov 2012 08:59:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2822 The piece of knowledge that is being duplicated in the example is that the value "bar" should be handled differently then any other value. The piece of knowledge that is being duplicated in the example is that the value “bar” should be handled differently then any other value.

]]> By: nerd http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2821 nerd Thu, 01 Nov 2012 21:09:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2821 When looking at 1,2,3... I can think of millions of valid patterns, e.g. f(n) = round(3*f(n-1)/2), which gives: 5,8,12,18,27... Or f(n) = f(n-1)+f(n-2)... One can show that there are unlimited number of patterns to continue any limiter sequence of numbers. When looking at 1,2,3… I can think of millions of valid patterns, e.g. f(n) = round(3*f(n-1)/2), which gives: 5,8,12,18,27… Or f(n) = f(n-1)+f(n-2)…
One can show that there are unlimited number of patterns to continue any limiter sequence of numbers.

]]> By: Kris Garcia http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2820 Kris Garcia Thu, 01 Nov 2012 20:28:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2820 Good stuff. Definitely resonates with me. Code is knowledge, so I think the DRY principle does apply to lines of code. Plus, it seems to me that part of the problem that the Rule of Three heuristic can help address is to determine whether a line of code is JUST SIMILAR to another line of code as opposed to ACTUALLY REPEATING the same concept. As time goes by the two lines may diverge and so it makes sense to delay abstraction until pragmatism demands it (which reminds me of <a href="//www.codinghorror.com/blog/2006/10/the-last-responsible-moment.html”" rel="nofollow">The Last Responsible Moment</a>). Good stuff. Definitely resonates with me. Code is knowledge, so I think the DRY principle does apply to lines of code. Plus, it seems to me that part of the problem that the Rule of Three heuristic can help address is to determine whether a line of code is JUST SIMILAR to another line of code as opposed to ACTUALLY REPEATING the same concept. As time goes by the two lines may diverge and so it makes sense to delay abstraction until pragmatism demands it (which reminds me of The Last Responsible Moment).

]]> By: Leonardo Pisano http://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/#comment-2818 Leonardo Pisano Thu, 01 Nov 2012 12:49:00 +0000 http://lostechies.com/derickbailey/?p=1021#comment-2818 For that matter: 1,2,3,5,8,13. For that matter: 1,2,3,5,8,13.

]]>