クロージャーは必要ですか？

Question

クロージャーというものをあまり使ったことがなかったので学んでみました。

ここのページがわかりやすかったです。

私が今までクロージャを理解できなかった理由 - プログラミングを勉強するブログ
https://artgear.hatenablog.com/entry/20120115/1326635158

で、学んでみたところ理解できたつもりなのですが、

このクロージャーというもの(クロージャーパターン)は、
いわゆるベタ書きのJavaScriptなら、グローバル的な変数を内部に閉じ込めてプライベート化して
関数を外部公開する意味がありそうに思いますが、

現代的なJSで、CommonJSでもESModulesでもいいのですが、モジュール分割している書き方(モジュールパターン)の場合は、
内部のプライベート変数は外部に公開されないので、
クロージャーで閉じ込める書き方をする必要がないと思うのですが

そのような理解をしておいて大丈夫でしょうか？

参考ですがこんなコードを書いています。
https://github.com/standard-software/partsjs/blob/v7.4.0/source/syntax/canUseMap.js

let _canUseMapFlag;

export const canUseMap = () => {
  if (isUndefined(_canUseMapFlag)) {
    try {
      new Map();
      _canUseMapFlag = true;
    } catch (e) {
      _canUseMapFlag = false;
    }
  }
  return _canUseMapFlag;
};

Mapが文法的にOKならtrue、を返す関数です。
超古い環境ではMapは使えない場合があるから、こんな関数を作ってみているのですが
これは簡単にクロージャー化できるのですが、クロージャー化する意味もないのではないかと思っているのです。

もっとクロージャーについて使い道がある、ということや、
あるいは、クロージャーはもういらないパターンだよ、
ということも知っていたり、ご意見いただけたら助かります。
よろしくお願いします。

---

追記

追加の例ですが
https://github.com/standard-software/partsjs/blob/v7.4.0/source/platform/platform.js
ここの、name とか、browserName も、呼び出すために毎回indexOfを何度もするよりかは、一度取得した後にキャッシュした値を次回から返す、というようにしようかなと思ったりです。
こういうパターンの場合はクロージャーパターンでも、モジュールパターンでも、あまり変わりなさそうな気がしました。

Answer 1

クロージャーは必要ですか？

使い方次第ですが、必要です。
現在、普通に利用される各種フレームワークは、内部で実装しているはずです。

モジュール分割している書き方(モジュールパターン)の場合は、

内部のプライベート変数は外部に公開されないので、
クロージャーで閉じ込める書き方をする必要がないと思う

モジュールスコープ（ファイルスコープ）がある現在は「変数スコープを局所化するために使う」必要はありません。
モジュールの考え方がなかった、古いJavaScript実行環境では、クロージャを変数スコープの局所化目的で使われていました。

もっとクロージャーについて使い道がある

MDN クロージャ の「実用的なクロージャ」でも説明される手法は、ExpressJS, KoaJSのミドルウェアで実装されています。
ミドルウェア登録関数（use()など）に use(getMiddleware(option)) とすると、__所定の引数を受け付ける関数（ミドルウェア）__を返します。

Wikipwdia クロージャ では 冒頭の説明に「エンクロージャ」という語を用いていますので、
「クロージャ＝返却される関数閉包」の考えに「エンクロージャの存在がある」と意識を向けると、思考の幅が広がると思います。
JavaScriptでは高階関数、カリー化、部分適用といった語で検索してみると良いと思います。
これらも、エンクロージャ＋クロージャという２つの関数で実現されると理解できます。

---

＞ Mapが文法的にOKならtrue、を返す関数です

Map などの標準ビルトインオブジェクトの判別は、わざわざクロージャにする理由はありません。
仕様を確認して expose されるオブジェクト（Map の場合、windowなど）に着目し以下のようなユーザ関数を定義します。

export const canUseMap = () => "Map" in window;

// const global = new Function("return this")();
// export const canUseMap = () => "Map" in global;

• MDN 機能検出の実装

Comments

[standard-soft]

ありがとうございます。
理解が深まりました。
MDNでも部分適用についてはサンプル付きで書かれていましたね。

canUseMap についても
(些末なことですが)try catch のコストを軽減するためにモジュールでPrivate変数確保してみたのですが
グローバルに関数があるかどうかで判定してしまえば、もっと楽できそうです。
ありがとうございます。

[miyabi_pudding]

> モジュールの考え方がなかった、古いJavaScript実行環境では

これを考慮した後方互換をするか、も重要な判断基準になるかと思います。

あとは、コールバックメソッドを実装する際は、クロージャーの方が、ぶっちゃけ使い勝手がいいような気がします。

[miyabi_pudding]

（というか早くプライベートフィールドプロパティの標準化をしてほしい願望）

[standard-soft]

コメントありがとうございます。

> これを考慮した後方互換をするか、も重要な判断基準になるかと思います。

ですよね。
自分の場合、古い環境でも動くようにBabel/WebPack環境で整えてしまっていたので、どこかの変換がうまくいってて気が付きにくく、複数ファイルから単独ファイルになったときに内部的にはクロージャーが使われているのでしょうね。気が付きませんでした。

> あとは、コールバックメソッドを実装する際は、クロージャーの方が、ぶっちゃけ使い勝手がいいような気がします。

なるほど、納得です。コールバックを提供しておけば、即時にその場で即時関数にしてクロージャーで変数を閉じれるというわけですね。

> 早くプライベートフィールドプロパティの標準化
下位互換を考えてやらないのかもしれません。
もう紳士協定的になれてしまった感じはありますが、JSは謎仕様が多くて苦労しますよね。

昔コンポーネント作成していて、publicになっていて欲しい値がprivateになっていてどうしても改良できない、みたいなジレンマに陥っったこともあるので、JSの紳士協定的ななんでもできる風な仕様も気楽でいいかなと思ったりします。