こんにちは、etau です 🤓
ここ 1 年ほど Google Apps Script で自作クラスを使ってコードを書くことが増えてきました、というよりもクラスなしでコードを書くことがなくなりました。
GAS の開発をご依頼いただいた場合も、オブジェクト指向プログラミングの考え方にそった、クラスたっぷりのプログラムを納品させていただいております。
きっかけとなったのは、なんとなーくドメイン駆動設計に触れ、オブジェクト指向プログラミングを目指せば、目標である「リーダブルでかっこいいコード」が書けるんじゃないかと考えたことです。
今回は、現時点で考える自作クラスを利用した場合のメリットとデメリットをまとめていきます。
オブジェクト指向プログラミング
当初はこちらの本をベースに Google Apps Script のコーディングにドメイン駆動設計に取り込もうとしてました。
「第 10 章 オブジェクト指向設計の学び方と教え方」に書かれている「古い習慣から抜け出すためのちょっと過激なコーディング規則」がかなり魅力的で最高です
最近は GAS であれば「ドメイン駆動設計」まで必要かな？「オブジェクト指向プログラミング」でも十分なんじゃないかな？ってところを行ったり来たりしています。
そんな中、いろいろとクラスの書き方を工夫していたところ Google Workspace services 単位でクラスを書いていくと、ある程度形になることに気づきました。
Google Workspace services 単位でクラスを分割し、残りの変数や関数を関連したクラスに書き込んでいったりするだけで、なんとなくオブジェクト指向プログラミングの体をなします。
Google Workspace services にないクラスであっても、「ヒト・コト・モノ」を意識しながら必要に応じてクラス化します
オブジェクト指向プログラミングの代表的な特徴としてあげられる「カプセル化」「継承」「ポリモーフィズム」のうち、「カプセル化」については効果をかんじますが、「継承」「ポリモーフィズム」については、いま書いているボリュームのコードだとあまりメリットを感ることができません。
すべての特徴を使いこなせなくても、「オブジェクト指向プログラミング」とは、コードをリーダブル保ち、開発のスピードをあげ、修正や機能追加のメンテナンス性を向上させるツールであることは間違いありません。
加えて「オブジェクト指向プログラミング」は、現実にあるものとコードの世界とつないでくれる存在です。
実際にすべてをつないでくれるわけではありませんが、コードをその先にあるモノに紐付けることができるので、コードで書いている内容がイメージしやすい利点があります。
それでは、以下にクラスを利用した場合のメリットとデメリットをまとめます。
メリット
開発
開発をおこなうにあたって過去のコードを参考にすることがあります。
ところが、手続き型でコードを書いている場合、目的のコードを探し出すまでに時間をとられたり、たどり着いたとしても以前のコードをそのまま利用することが難しいはずです。
オブジェクト指向プログラミングでコードを書くことによって、以下のようなメリットがあります。
- 短時間で目的のコードにたどり着ける
- 過去に作ったクラスが簡単に再利用できる
- 追加した新しいクラスやメソッドを簡単にストックできる
- クラス単位でのデバッグが可能になるため、テストが楽になる
このように、一度しっかりとコードを書いてしまえば、そのコードをどんどん組み合わせて使うように、コードを書くことができます。
コードを機能単位の小さなブロックとして持っていて、新しく書くコードに必要なブロックを寄せ集めて組み上げていくと、ある程度形ができている状態です。
不足しているパーツ (クラス、メソッド) や、メインとなる関数を書き足すだけである程度思っていたプログラムが完成する理想的な状態です。
さて、続いて書き終えたコードをメンテナンスする場合のメリットについても触れていきます。
メンテナンス
ここでいうメンテナンスとは、問題点の修正や新しい機能を追加することを想定しています。
オブジェクト指向プログラミングで書かれたコードの全体の見通しが良くなるので、メンテナンス時に目的のコードへのアクセスが容易になります。
さらに、クラスやメソッドのサイズが適切に保たれていれば、他のクラスへの影響を意識せずにメンテナンスが可能です。
メンテナンスをしやすくするために、以下の点に注意しながらクラスを作成しています。
- クラスを適切に分類する
- コンストラクタ メソッドには最低限のプロパティだけを持たせる
- メソッドの機能は 1 つとし細分化する
- ドキュメンテーション コメントをしっかりと書く
この点を守れば、メンテナンス時にも、目的のコードへのアクセスの高速化、コードの修正や機能追加にかかる時間の短縮、テストをおこなう際の影響範囲を小さく抑えることができるなどのメリットがあります。
クラス構文自体に慣れてしまえば、コードの読みやすさは手続き型と大きく変わりません。
くわえて、ドキュメンテーション コメントをしっかり書くことによってコードを読むスピードは格段にあがります。
読みやすさ
メソッドには 1 つの機能しか持たせません。
その結果、メソッドは細かくわかれていきます。
そのメソッドに対して、ドキュメンテーション コメントを一つひとつ書いていくのは手間ですが、それによって、コードを読まなくても、そのメソッドの機能、仮引数・戻り値の型とその内容を確認することができます。
必要があれば、そこからメソッドを読み込んでいく必要がありますが、メソッド自体は 1 つの機能しか持っていないため、手続き型のコードを読むよりも処理の内容は理解しやすいはずです。
以上のようなたくさんのメリットがありますが、デメリットがないわけではありません。
デメリット
コード量
コード量は手続き型にくらべ、少なく見積もっても 1.5 倍になります。
コードが長くなる要因のひとつとして、クラスに書かれるドキュメンテーション コメントがありますが、そのおかげで、メリットの項目にもあげたようにコード自体はとても読みやすくなります。
この点は大きなデメリットにはなりませんが、次の項目が、この自作クラスを使うかどうかの一番のポイントになります。
学習コスト
GAS を利用される方の多くはノンプログラマーなのではないのでしょうか。
以前に比べて V8 Runtime になってからクラス構文の書きやすさから、クラスを自作するための学習コストは低くなりましたが、自作クラスを活用するための学習コストが低くなったわけではありません。
さらにチームでコードを運用する場合、全員がオブジェクト指向プログラミングとそのコードの書き方を理解する必要性も出てきます。
この「学習コスト」とのバランスを考え、オブジェクト指向プログラミングを採用をしないという選択肢もあります。
その上で、なぜオブジェクト指向プログラミングで GAS を書くのかをあらためて考えてみました。
結論から述べると、コードが資産になるからです。
コードを資産にするための 3 つの条件
ノンプログラマーのコードは資産になりにくい。
スキルアップの速度が早いというポジティブな面と、正解のコードに出会う機会が少ないため試行錯誤している期間が長いというネガティブな両方の面から、自分で書いたコードですら、すぐに読めなくなってしまいます。
コードを資産にするための条件は、最低限以下の 3 つを満たしている必要があります。
リーダブルなコード
- コード全体の見通しがいいこと
- コード自体が読みやすいこと
再利用性が高いコード
- 汎用性の高いクラスやメソッドであること
- 可搬性の高いクラスやメソッドであること
拡張性が高いコード
- クラスのサイズが適切で、メソッドが正しいクラスに書かれている (高凝集) 状態であること
- クラス同士が複雑に影響しあわない (疎結合) 状態であること
現時点で「コードを資産にするため」の条件を満たす最良な方法が「オブジェクト指向プログラミング」だと思います。
その場しのぎのコードは書かずに、未来の自分のため、未来のチームのためにコードを書いていくという目標を達成させるための素晴らしいツールです。
1 年後も同じことを言っている自信はありませんが、本質は大きく変わってないはずです。
