9章よく使われる抽象化

Jason Strimpel

 

この章では、アイソモーフィックJavaScriptのアプリケーションで頻繁に使われる2つの機能を抽象化します。

  • cookieの読み書き
  • リクエストのリダイレクト

抽象化によって環境に固有の実装がカプセル化され、クライアントとサーバーのどちらでも利用可能な一貫したAPIが提供されます。本書の第II部全体を通じて、抽象化の危険性を繰り返し述べてきました。抽象化は悪だというCoplienの発言も紹介しました。この章のすべてが抽象化に費やされることを踏まえて、まずは抽象化を行うべき根拠やそのタイミングについて考えたいと思います。

9.1 抽象化する理由とタイミング

実際には、抽象化は悪ではありません。問題なのは、抽象化が誤って使われることが多いという点です。コードに意味を与えてくれる重要な事柄が、不必要に隠されてしまうことがよくあります。しかも、間違った抽象化の主な原因は世界をよりよくしようという善意の努力です。例えば、プロジェクトのScaffold(ひな型)を作ってくれるモジュールは便利です。しかし、詳細が内部のモジュールに隠され、中身を調べたり拡張や設定あるいは修正したりといったことが容易にはできなくなってしまったとしたら、それは望ましいことではありません。このような誤った抽象化こそが悪なのであり、そこからすべての抽象化が悪だというイメージが広がっています。正しく適用するなら、直感的なインタフェースを作成するための不可欠なツールとして抽象化は役立つでしょう。

筆者はこれまで、実装の詳細がユーザーに不必要な重荷を与えてしまうという場合にだけ抽象化を行ってAPIを共通化し、環境の違いを吸収するようにしてきました。『スタートレック』でのセリフを借りるなら、「多数にとっての利益が、少数あるいは1人にとっての利益を上回る」場合に抽象化を行っています。この原則は宇宙船の運営には役立つかもしれませんが、これだけでは抽象化するべきかどうかの判断を誤ることもあります。どの時点で抽象化するべきかを適切に判断するのは、とても難しいことです。筆者は次のように自問することにしています。 ...

Get アイソモーフィックJavaScript now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.