Penso che ci siano molti modi per classificare l'idioma.
Wrapper, ovviamente, ma può comportare l'associazione di molti pattern.
il libro Modelli di implementazione riporta alcuni pattern:
LIBRARY CLASS
nel Capitolo 5:
Where do you put functionality that doesn’t fit into any object? One solution is to create static methods on an otherwise-empty class. No one is expected to ever create instances of this class. It is just there as a holder for the functions in the library.
anche METHOD OBJECT
nel capitolo 7:
This is one of my favorite patterns, probably because I use it so infrequently but the results are spectacular when I do. Creating method object can help you turn a tangled mass of code packed into an impossible method into readable, clear code that gradually reveals details to readers. This is a pattern I apply after I have some code working, and the more complex the method the better.
Inoltre, penso che sia un semplice pattern Adapter / Facade come già detto @Joel Harmon.
Penso che lo scopo dell'idioma nel tuo caso:
- Libreria richieste:
- reveals details to readers/users
- keep api easy to use
- Layers Architecture, High Level Low Level divide, low level can change, high level api won't
-
Date.now:
Considero link
Description
Because now() is a static method of Date, you always use it as Date.now().
Polyfill
This method was standardized in ECMA-262 5th edition. Engines which have not been updated to support this method can work around the absence of this method using the following shim:
if (!Date.now) {
Date.now = function now() {
return new Date().getTime();
};
}
- "using the following shim" so it is a adapter
- "static method of Date", yes
LIBRARY CLASS
as the book Implementation Patterns said.