6 ms·

Basic Patterns for Everyday Programming

85 points by laktek 15y ago

adammacleod 15y ago
I'd be careful with the last Memoize example, if current_date changes then the JavaScript function at least will return the old value still. Memoize only works if your function is one to one (one set of inputs gives the same outputs), and you cache the result of the function for each value of the input.
- evmar 15y ago
  The last example also doesn't actually memoize if the result of the computation is false -- it will recompute on each call.
  - adammacleod 15y ago
    It will store a false in the JavaScript version, I'm not familiar with Ruby but I believe you are correct in that case.
- gizzlon 15y ago
  Shouldn't that be solved with a closure in both languages?
  - qntm 15y ago
    I'm not sure there's anything there to be solved. If a "function" can return two different answers despite being provided with the exact same input parameters, you simply should not be attempting to memoize it.
ericflo 15y ago
I love the design on this blog.
erez 15y ago
One pattern that this guy misses is "better to be clear than to be clever". His "a == x || a == y..." example is a case of verbosity being a good thing, and probably the reason why most languages don't have a == (x or y or z) in their syntax. And then, if this isn't convoluted enough, he hides it behind an abstraction, which is another anti-pattern: Whatever you need to hide, you need to refactor. Hiding your cleverness away from the user is never a good idea. He even excuses it with "This refactoring allows others to read the code in context to the domain, without having to comprehend the internal logic." Sadly, this "Don't make me think" attitude is very common.
- morsch 15y ago
  He proposes to replace if(current_day == "Monday" || current_day == "Wednesday" || current_day == "Friday") with if(["Monday", "Wednesday", "Friday"].include?(current_day)) I've done this before, and I don't think it's any less clear -- I wouldn't have thought of making a public announcement about it, though. I like it because it more closely aligns with the way you're probably thinking in this example: you're wondering if current_day is part of a certain set of days (the discount weekdays, apparently), not if it's equal to "Monday" or equal to "Tuesday", etc. I like the Javascript example with it's indexOf(..) >= 0 a lot less, but I guess people more used to JS idioms auto-translate this sequence to a set-contains operation. It's more sensible if the set of values is larger than just three; and in this instance, you have to wonder why the day isn't available as a numeric variable, but I think you can let it slide for a contrived example. It's even more useful if you reference the same set more than once, because you can just define it once, and as a constant if your language of choice does that kind of thing. This would also let you make your code less wordy (but arguably more literal) without hiding logic in functions, e.g. his later example would be if(discount_weekdays.include?(current_day) && current_date > 20)
  - erez 15y ago
    "It's more sensible if the set of values is larger than just three ... It's even more useful if you reference the same set more than once" Both are correct, I am strictly referring to his rationale being it's too verbose.
damncabbage 15y ago
The tucking-away of current_date and current_day inside discount_day? is a mess. If either change between calls to discount_day?, suddenly discount_day? is returning the wrong value. That method returns different values given the same inputs; it's not a good candidate for being memoized. (Furthermore, it's harder to test, as now current_date and current_day need to be stubbed out. It's also less obvious which day is being checked with regards to being discount day or not.) I'd recommend having discount_day? taking a date as the argument, and having it invoked as discount_day?(current_date). (The day can then be calculated from the provided date.)
Yrlec 15y ago
If you want to use memoization for caching in C#, you can try out my library FuncCache: https://bitbucket.org/Yrlec/funccache/overview https://bitbucket.org/Yrlec/funccache/overview
deleted 15y ago
[deleted]
mrspandex 15y ago
Checking for null on every method invocation? I usually call methods for a reason and if my object is null, I have an error. If I have a situation where an object may be null, there will be specific handling for that case. The other "patterns" are fishy too. How has this gotten so many points?
- bem 15y ago
  Checking for null on every method call certainly sounds nuts to me. Furthermore I would argue that doing so decreases consistence in your program. For example, in Objective-C I can count on nil being returned every time I call a method on a nil object. The opposite is true for other languages. The point is, it renders me able to make certain assumptions about how my code will behave, and thereby reduces the amount of code and tests I have to write. Now if the language you're using behaves opposite of your wish, you're either using the wrong language or doing things the wrong way.
- jwdunne 15y ago
  The author's response to a comment destroys the article's credibility by saying the difference between '==' and '===' is purely stylistic. I think somewhere down the line the author started to run before he could walk and that'll definitely come back to haunt him.
  - laktek 15y ago
    I have never claimed the choice between '==' and '===' is stylistic.
Jach 15y ago
Memoization is an optimization technique, I certainly don't use it every day. Be sure you verify you actually get a speedup (especially when using hash-tables for your cache) before you run off and prematurely optimize, as well as understand the trade-off of increased memory and less computation (if it's an actual speedup). As others have pointed out the example of memoizing in the blog is pretty bad. Storing the value in a variable seems like a better choice than in a procedure to me, if your program won't be running over a day.
DanielRibeiro 15y ago
Cool. Looks a lot like an excerpt of Smalltalk Best Practices[1] and a bit of Refactoring[2] book together. [1] http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/... [2] http://martinfowler.com/books.html#refactoring http://martinfowler.com/books.html#refactoring

85 points by laktek 15y ago

I'd be careful with the last Memoize example, if current_date changes then the JavaScript function at least will return the old value still. Memoize only works if your function is one to one (one set of inputs gives the same outputs), and you cache the result of the function for each value of the input.

evmar 15y ago
The last example also doesn't actually memoize if the result of the computation is false -- it will recompute on each call.
- adammacleod 15y ago
  It will store a false in the JavaScript version, I'm not familiar with Ruby but I believe you are correct in that case.
gizzlon 15y ago
Shouldn't that be solved with a closure in both languages?
- qntm 15y ago
  I'm not sure there's anything there to be solved. If a "function" can return two different answers despite being provided with the exact same input parameters, you simply should not be attempting to memoize it.

ericflo 15y ago

I love the design on this blog.

erez 15y ago

One pattern that this guy misses is "better to be clear than to be clever". His "a == x || a == y..." example is a case of verbosity being a good thing, and probably the reason why most languages don't have a == (x or y or z) in their syntax. And then, if this isn't convoluted enough, he hides it behind an abstraction, which is another anti-pattern: Whatever you need to hide, you need to refactor. Hiding your cleverness away from the user is never a good idea. He even excuses it with "This refactoring allows others to read the code in context to the domain, without having to comprehend the internal logic." Sadly, this "Don't make me think" attitude is very common.

morsch 15y ago
He proposes to replace if(current_day == "Monday" || current_day == "Wednesday" || current_day == "Friday") with if(["Monday", "Wednesday", "Friday"].include?(current_day)) I've done this before, and I don't think it's any less clear -- I wouldn't have thought of making a public announcement about it, though. I like it because it more closely aligns with the way you're probably thinking in this example: you're wondering if current_day is part of a certain set of days (the discount weekdays, apparently), not if it's equal to "Monday" or equal to "Tuesday", etc. I like the Javascript example with it's indexOf(..) >= 0 a lot less, but I guess people more used to JS idioms auto-translate this sequence to a set-contains operation. It's more sensible if the set of values is larger than just three; and in this instance, you have to wonder why the day isn't available as a numeric variable, but I think you can let it slide for a contrived example. It's even more useful if you reference the same set more than once, because you can just define it once, and as a constant if your language of choice does that kind of thing. This would also let you make your code less wordy (but arguably more literal) without hiding logic in functions, e.g. his later example would be if(discount_weekdays.include?(current_day) && current_date > 20)
- erez 15y ago
  "It's more sensible if the set of values is larger than just three ... It's even more useful if you reference the same set more than once" Both are correct, I am strictly referring to his rationale being it's too verbose.

damncabbage 15y ago

The tucking-away of current_date and current_day inside discount_day? is a mess. If either change between calls to discount_day?, suddenly discount_day? is returning the wrong value. That method returns different values given the same inputs; it's not a good candidate for being memoized. (Furthermore, it's harder to test, as now current_date and current_day need to be stubbed out. It's also less obvious which day is being checked with regards to being discount day or not.) I'd recommend having discount_day? taking a date as the argument, and having it invoked as discount_day?(current_date). (The day can then be calculated from the provided date.)

Yrlec 15y ago

If you want to use memoization for caching in C#, you can try out my library FuncCache: https://bitbucket.org/Yrlec/funccache/overview https://bitbucket.org/Yrlec/funccache/overview

deleted 15y ago

[deleted]

mrspandex 15y ago

Checking for null on every method invocation? I usually call methods for a reason and if my object is null, I have an error. If I have a situation where an object may be null, there will be specific handling for that case. The other "patterns" are fishy too. How has this gotten so many points?

bem 15y ago
Checking for null on every method call certainly sounds nuts to me. Furthermore I would argue that doing so decreases consistence in your program. For example, in Objective-C I can count on nil being returned every time I call a method on a nil object. The opposite is true for other languages. The point is, it renders me able to make certain assumptions about how my code will behave, and thereby reduces the amount of code and tests I have to write. Now if the language you're using behaves opposite of your wish, you're either using the wrong language or doing things the wrong way.
jwdunne 15y ago
The author's response to a comment destroys the article's credibility by saying the difference between '==' and '===' is purely stylistic. I think somewhere down the line the author started to run before he could walk and that'll definitely come back to haunt him.
- laktek 15y ago
  I have never claimed the choice between '==' and '===' is stylistic.

Jach 15y ago

Memoization is an optimization technique, I certainly don't use it every day. Be sure you verify you actually get a speedup (especially when using hash-tables for your cache) before you run off and prematurely optimize, as well as understand the trade-off of increased memory and less computation (if it's an actual speedup). As others have pointed out the example of memoizing in the blog is pretty bad. Storing the value in a variable seems like a better choice than in a procedure to me, if your program won't be running over a day.

DanielRibeiro 15y ago

Cool. Looks a lot like an excerpt of Smalltalk Best Practices[1] and a bit of Refactoring[2] book together. [1] http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/... [2] http://martinfowler.com/books.html#refactoring http://martinfowler.com/books.html#refactoring