2016年度版 僕が考えたChrome拡張機能を作るときのデザインパターン - Qiita
4年近く前の2012年に僕が考えたChrome拡張機能を作るときのデザインパターンというエントリを書きました。最近参加したイベントで「よういちろうさんの拡張機能の記事見て作ってみました〜」と声をかけてくれた人がいて嬉しかったのですが、2012年のそのエントリは、すでに内容が古くなってしまっています。最近の状況を踏まえて、内容を新しくした「2016年度版」を書いてみようと思います。 変更しようと思った点は、以下です。 prototype.jsは使わず、ECMAScript 2015で書く。 Background Page(常駐型)ではなく、Event Page(非常駐型)にする。 そもそも最初のコードセットは自分で書かない。 本文やコード的には、2012年度版をコピペしています。 （この投稿の内容は、自分のブログエントリと同じです。） 前にいくつかのChrome拡張機能を作っていて、すでに数
デザインパターンを読み解く
ポリモーフィズム（サブクラスによる切り替え、抽象化） ここに分類されるのは、オブジェクト指向の第３原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。＜参照＞ 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
