1

The way many design patterns are described in the classical literature is somewhat different from their implementation in dynamic languages such as Javascript.

The presence of some features like first-class functions makes some pattern implementations structurally the same, what sometimes makes it harder to distinguish between them.

I had this legacy piece of code that relies on Amazon S3 for storage. There are some façade functions that aimed to make its use simpler: getS3, putS3, listS3 and so on...

We didn't have a proper development setup and while I was trying to create it, I felt the need of write data to different locations in S3 for production and development environments.

My idea was to prepend a predefined development bucket to the S3 path. Since I didn't want to touch the original functions, I thought of a wrapper function that I initially called environmentDecorator as an allusion to the Decorator Pattern.

It is roughly like:

function environmentDecorator(fn) {
  return function(bucket, key, ...rest) {
    if (environment === 'development') {
      key = bucket + '/' key
      bucket = 'development-bucket'
    }
    return fn(bucket, key, ...rest)   
  }
}

The reason I thought of the Decorator Pattern was the "ability to add responsibilities dinamically [to the functions]" without changing their interface.

However, a few days later, while I was reviewing this piece of code, I thought it would better fit the Proxy Pattern definition: "Provide a surrogate or placeholder for another object to control access to it" and "Add a wrapper and delegation to protect the real component from undue complexity". If so, I should call my wrapper environmentProxy.

I see this is a theoretical question and the important thing is to get the issue solved, but I couldn't help feeling curious about this.

  • 1
    The way many design patterns are described in the classical literature is somewhat different from their implementation in dynamic languages such as Javascript. -- That's because the "classical" patterns are based on C++, not Javascript.. Some of those patterns don't even apply to Javascript. For the most part, each pattern exists because there wasn't a corresponding native idiom in C++ at the time. – Robert Harvey Nov 29 '16 at 15:05
  • "The presence of some features like first-class functions makes some pattern implementations structurally the same, what sometimes makes it harder to distinguish between them" Then stop trying to distinguish between them :/ – David Arno Nov 29 '16 at 15:09
  • 1
    @RobertHarvey agreed, but this doesn't mean such patterns don't exist in dynamic languages, only that they are different than their canonical form. Just keep an open mind here. – Henrique Barcelos Nov 29 '16 at 15:22
  • 1
    Some of them aren't needed at all in Javascript, because Javascript already has the capability of expressing the pattern natively, within the language itself. Try to keep an open mind here; not everything in programming is a software pattern. – Robert Harvey Nov 29 '16 at 15:50
1

Even in c++ or java some patterns are structurally identical. Heck I could call this a factory. The difference is intent.

I see this more as a decorator. Your intent is to decorate input parameters with deployment details. Sure you could see it the other way but decorator seems the simplest way to see it and that's good enough.

Remember the point isn't to implement structural purity. It's to communicate a good way to think about how the code works. Give me that and I can forgive a lot.

  • is the exactly kind of discussion I had in mind. As I said, the code has solved my issue in an acceptable way. It was just some curiosity in which pattern it fits better. Thank's for your answer =] – Henrique Barcelos Nov 29 '16 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.