0

REFERENCE

According to reference: Below is a more advanced version of the facade pattern that adds security to internal methods.

Question: Honestly what do they mean add security? Furthermore, what would be insecure example? Lastly, What would be a simple but real use case for security and this facade + revealing module pattern?

var MyModule = ( function( window, undefined ) {

  // revealing module pattern ftw
  function MyModule() {

    function someMethod() {
      alert( 'some method' );
    }

    function someOtherMethod() {
      alert( 'some other method' );
    }

    // expose publicly available methods
    return {

      // in our normal revealing module pattern, we'd do the following:
      someMethod : someMethod,

      // in the facade pattern, we mask the internals so no one has direct access by doing this:
      // HOW DOES THIS MASK THE INTERNALS?  WHAT DO THEY MEAN BY ADDS SECURITY?
      someMethod : function() {
        someMethod();
      }

    };

  }

} )( window );

Armeen Moon
  • 18,061
  • 35
  • 120
  • 233
  • 3
    it means that nobody can change the function signature. but, it can still be replaced completely, which makes the whole idea somewhat silly. if it had access to a closure, then it makes some more sense. – dandavis Nov 19 '14 at 07:15
  • Wait so for the revealing module pattern you can reassign someMethod: but using the facade pattern you cannot reassign someMethod? – Armeen Moon Nov 19 '14 at 07:17
  • could you please show a practical example? I just am a bit confused. – Armeen Moon Nov 19 '14 at 07:18
  • in both you can re-assign it. it's kind of useless, but i suppose in the second one, you can't get the methods source code pragmatically. still, that's hardly what i would call security. – dandavis Nov 19 '14 at 07:23
  • 1
    The question is: what kind of security? Reliability? Safety? Protection? Programmability? Or user protection? – thi gg Nov 19 '14 at 07:44
  • I think the author means **obscurity** when he writes **security** -- Façade is an *information-hiding* pattern. Security by obscurity is questionable. https://en.wikipedia.org/wiki/Security_through_obscurity – Fuhrmanator Nov 20 '14 at 15:21

1 Answers1

1

This just makes no sense. Really none.

  • There is no added "security". Security is a completely different field when developing web applications.
  • "Works well in combination with other patterns", "Easy to implement" is not really an advantage. The normal design is even simpler.
  • "Makes it easy to patch internals". Sure. But YAGNI. You still can introduce it when you really patch internals, or shim externals.
  • "Provides a simpler public interface". Well, it can be used to reduce the complexity of the interface, especially if the internal methods have additional parameters that are not documented and are expected not to be exposed. But the someMethod in the example does not have any parameters, so it's just useless here.

Actually, the revealing module pattern already is a facade by itself. It defines some internal functions, and then exports them on the module object, whose property names are the external interface. There's no need for an additional layer of indirection.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • 1
    a solution in search of a problem. the 1st example in the "book" makes sense, the one above, not so much... – dandavis Nov 19 '14 at 07:32
  • Fair enough. Do you have any simple yet articulated examples of this pattern? @dandavis you said the first example makes sense? so a facade pattern is just wrapping a function around an some conditionals(complexity)? If thats so I can just move on... I get it. – Armeen Moon Nov 19 '14 at 07:40
  • addEvent is easier and safer to use than coding addEventListener and attachEvent routines each time. you can also think of polyfills as a facade in that respect. – dandavis Nov 19 '14 at 07:51
  • 1
    @MatthewHarwood: It's not about wrapping complex behaviour in a function. It's about using an extra name (`addEvent`) instead of the internal method (`addEventListener`) in the first place, even if those are doing just the same thing (`addEvent` could be a function that just calls `addEventListener`, but it could also be [`addEvent = callable(Element.prototype.addEventListener)`](http://stackoverflow.com/q/25391594/1048572) - or in the module pattern, the declaration `someMethod: someInternalMethod`). The point is that you can easily change the implementation without the name. – Bergi Nov 19 '14 at 08:00