オブジェクト指向でなぜ作るのか 9~13章とまとめ
はじめに
これの続き
オブジェクト指向そのものを深掘りできる本だと思っていたが、意外と周辺知識の薄めな解説の章があったので残りはサラッとまとめる
第9章 現実世界とソフトウェアのギャップを埋めるモデリング
現実世界の概念や物事をソフトウェア設計に落とし込むモデリングについての章
最近勉強しているDDDでもその重要性は感じており、このモデリングをミスると設計全体の方向性に影響を与えうるし、修正がより難しい領域だと感じている。
そんなモデリングについて、図を使って触りを紹介している章
第10章 擬人化して役割分担させるオブジェクト指向設計
OOPにより、保守性や再利用性を向上させるために、凝縮度と結合度を用いて説明している章
- 凝縮度
- クラスに定義する機能=部品を一箇所に集めまとまりを強くすること
- 結合度
- 部品=クラス間のやり取りを少なくすること
これらを意識することで、保守性や再利用性が高まることを説いている。
また、依存の方向を一方向にすることなどにも触れられていた。
第11章 オブジェクト指向から生まれたアジャイル開発とTDD
ウォーターフォール型開発やその問題点の紹介、それに対してアジャイル宣言の誕生やテストから書いていくTDDなどを言葉の紹介をしていた章
これに関しては他にもっと詳しい資料や書籍があるはずなので割愛。
第12章 オブジェクト指向を使いこなそう
本書の結びの章
新たな知識等はない
印象的だったのは「時代がオブジェクト指向に追いついた」というワードで、元上司の20年選手のエンジニアのかたも「人類にオブジェクト指向は早かった」と言っていたのを思い出した。
半世紀以上前に考案され現代になりやっと定着した定着した技術を本一冊、一朝一夕でものにしようにもできないのが身にしみた。
理解をもっと深めていこうと思った。
おまけ
第13章 関数型言語でなぜ作るのか
関数型言語とその考え方の紹介
現在仕事でScalaに入門しているが、関数型っぽい書き方に慣れないことあるなあと読んでいた。
オブジェクト指向でなぜつくるのか 第7,8章
はじめに
これの続き
今回は深い内容ではなかったのでまとめて
第7章 汎用の整理術に化けたオブジェクト指向
オブジェクト指向の考え方は、システム開発における上流工程にも当てはめることができますよ。という章
それは、
- 集合論
- 役割分担
という考え方として適用できる。
これらの考え方は、現実世界に適用することができる。
「従業員クラスのAさんインスタンス、Bさんインスタンス」（集合論）やある特定の役目を持つメソッドを呼び出していく仕組み（役割分担）など。
この章はボリュームも軽く、こういうことができますよという紹介だった。
第8章 UMLは形のないソフトウェアを見る道具
UML(Unified Modeling Language)の紹介の章
UMLとは、ソフトウェアの内部構造を図で表現するための書き方のこと。
個人的にUMLは見たことあったものの、言葉は知らなかったし、あまり馴染みはない。
UMLには13種類のダイアグラムがあり、様々な工程、領域に汎用的に対応できるようになっている。
使い方は3つある。
- プログラム構造や動作を表現
- クラス図
- 図によって視覚的にクラスの呼び出し関係をみる
- シーケンス図
- プログラムやメソッドの実行順序を表現
コミュニケーション図
- メソッドの実行をインスタンスを中心に表現
汎用の整理術の成果物を表現
- クラス図
- 現実世界の物事の関係を表現
- シーケンス図
- 役割間のやり取りを時系列で表現
コミュニケーション図
- 役割間のやり取りを構造を中心に表現
非オブジェクト指向を表現
- ユースケース図
- 実際のユースケースとして機能を表現
- アクティビティ図
- 役割ごとに分けてフローチャート形式で表現
上記にあげたのは一例だが、共通していることは、様々な形でシステムの内部を表現しているということ。
実際にUML図を作成したことはないし、見たこともなかったので、このようにまとめるだけで勉強になった。
これはCtoCのSaaSサービスやWebサービスというよりは、デカ目のエンタープライズシステム向けの考え方なのかなと感じた。
Google Cloud FunctionsからスプレッドシートAPIをPythonで操作する
はじめに
タイトル通りのことがしたかったんだけど、意外とこの組み合わせのサンプルっぽいものが無かったのです記録に残しておく。
サンプルリポジトリ作りました。
スプレッドシートAPIを有効にする
まずはじめに、GoogleのデベロッパーコンソールからスプレッドシートAPIを有効にする。
ここから、プロジェクトを選択する。
そしたら、検索ボックスから「Sheets API」を検索して、有効化する。
サービスアカウントのアドレスをスプレッドシートに登録する
まずはGCPコンソールにログイン。
左上のナビゲーションメニューからIAMと管理＞サービスアカウントを選択する。
そしたら、名前がApp Engine default service accountのメールをコピーする。
コピーしたらそのアドレスをスプレッドシートの共有設定に登録する。
最後にスプレッドシートの以下部分をコピーしておく。
あとで、SPREADSHEET_KEYとして使う。
https://docs.google.com/spreadsheets/d/{ここの部分！}/edit#gid=0
設定はこれでおしまい。
ソースコード
import gspread import google.auth def main(event, context): # ここで認証情報を取得する。デフォルトのサービスアカウントが適用される credentials, _ = google.auth.default(scopes=['https://spreadsheets.google.com/feeds', 'https://www.googleapis.com/auth/drive']) # ここでスプレッドシートの認証 gc = gspread.authorize(credentials) # 先ほどコピーしたスプレッドシートキーを変数に SPREADSHEET_KEY = '{your-spreadsheet-key}' # sheet1を取得 worksheet = gc.open_by_key(SPREADSHEET_KEY).sheet1 import_value = int(worksheet.acell('A1').value) export_value = import_value + 100 worksheet.update_cell(1, 2, export_value)
上記のような感じで操作する。
なかなか認証周りの資料がない中、そのプロジェクトのデフォルトのサービスアカウントの情報をスプレッドシートに登録しておけばjsonファイル等がなくても操作できることがわかった。
オブジェクト指向でなぜつくるのか 第6章
はじめに
これの続き
OOPがもたらしたソフトウェアとアイデアの再利用
ソフトウェアの再利用
- クラスライブラリ - フレームワーク - コンポーネント
といったようなものたち。
クラスライブラリ
汎用的な機能を持つクラスを集めたもの。
アプリケーションから呼び出して利用したりする。
標準のクラスライブラリや外部のクラスライブラリ等がある。
- 言語の標準クラスライブラリ
- 外部のクラスライブラリ
- 上記PHPのDateTimeをラップした日付操作ライブラリのCarbon github.com
フレームワーク
特定のプログラミング言語で書かれた、特定の目的を持つ再利用部品群のこと
基本的な制御の流れをフレームワーク側で用意して、アプリケーションで個別の処理を組み込む
クラスライブラリとは違い、フレームワークがアプリケーションの処理を呼び出す
LaravelやRuby on Rails等
アイデアの再利用
デザインパターン
設計のパターンのこと
再利用がしやすいソフトウェアを作るために先人たちが工夫したアイデアを文書にまとめたものである。
特に有名なのが、GoFのデザインパターン
まとめ
この章は、再利用にはこのようなパターンがあるよという話で、具体的な話はなかった。
ただ、ライブラリやフレームワークに関しては、当たり前のように使っていたものの定義をしっかりと確認できてよかった。
オブジェクト指向でなぜ作るのか 第5章を読んだ
はじめに
これの続き
メモリの仕組みの理解はプログラマのたしなみ
- 比較的新しく作られた言語は、メモリのことを意識しなくて済む
- ただ、何が行われて動いているか理解していないと、途方にくれるかもしれない
- だから最低限理解しておく必要があるよという章
コンパイラとインタプリタ
- コンパイル言語はコンパイラがソースコードを機械語に変換して実行を行う - インタプリタ言語は実行時にソースコードの解釈を行う
まあこの辺は当たり前の前提知識という感じ。
個人的にはコンパイル言語の方が好き。
上記以外に中間コード方式というのもある。
コンパイルはするが、専用のインタプリタ上で実行することで異なる実行環境でも動作する。（JVM上のJavaなど）
JavaがJVM上で動作することは知っていたが、中間コード方式ということは知らなかった。
CPUは複数のスレッドを同時実行する
- スレッドとはプロセスよりも小さな単位
- スレッドは一つの作業を最初から最後まで一気に行うわけではなく、中断して他のスレッドの作業を実行する。
- これをマルチスレッドという。
この辺も最低限は知っていた。
マルチスレッドができる理由は、全体効率を上げるため。CPUのリソースを効率よく使用することができる。
静的領域、ヒープ領域、スタック領域で管理する
メモリの使い方について。
- メモリの領域は基本的に静的領域、ヒープ領域、スタック領域の3つの領域で管理する。
静的領域について
- プログラムの開始時に確保され、プログラムが終了するまで配置が固定される領域のこと
- 静的な変数、つまりグローバル変数とプログラムの命令を実行可能な形式に変換したコードが配置される
ヒープ領域について
- プログラムの実行時に動的に確保するメモリ領域のこと
- 必要に応じてアプリケーションに割り当てる
スタック領域について
- スレッドの制御のために使うメモリ領域のこと
- スレッドに一つずつ用意される
- メソッドの引数やローカル変数、戻り値などが格納される
この辺の領域については曖昧な知識だったので、改めて確認することができてよかった。
ここまで説明されてきた、内容はあくまで常識とのこと。
心に留めておきたい。
OOPの特徴はメモリの使い方にあり
ここからはOOP固有の話
クラス情報はクラスにつき1つだけロードされる
- 同じクラスから作られた異なるインスタンスであっても、メソッドに書かれたコード情報同じため、1つのロードが行われる
- このクラス情報がロードされる領域は静的領域
インスタンス生成のたびにヒープ領域が使われる
変数にはインスタンスのポインタが格納される
- 作成したインスタンスを格納する変数には、ヒープ領域に作成されたインスタンスのポインタが格納される
- ポインタはメモリ領域の場所を示す情報
- javaでは変数のコピーに注意が必要
- 変数にはポインタが入るため
まとめ
この章は結構ボリュームがあった。
なんとなくで知っていたことや、意外と知らなかった知識を分かりやすいJavaのコード例と、図で示してくれていたので、とても勉強になった。
今まではあまりなかったが、これからはちょっとはメモリのことを意識してコードを書いていきたい。
2年目を終えて
はじめに
昨日3/31を持って社会人2年目及び新卒で入った会社からグループ内転籍（面接したしほぼ転職）したので振り返り。
新卒でエンジニアに配属された会社は、がっつり営業会社。
やったこと
- 社内システム開発（PHP/Laravel）
- バッチクローラー開発（Go）
- Docker導入
- オンプレからGCP移行
- BacklogからGitLab移行
- データ可視化（Python）
- LINE Bot開発複数（PHP/Larave,CodeIgniter,Slim）
- Botサーバー構築（AWS）
- そのほか諸々
こう見ると少人数だった分色んなタスクが降ってきてそれをこなしたなーという感じ。
未経験から配属された割に領域問わずフロント、バック、インフラと満遍なくさわれていい経験できたなという感じ。
できるようになったこと
- PHP/Laravel
- サーバー構築最低限（Ansibleも最低限）
- 動くアプリケーションを構築すること
業務で触れてきた範囲は最低限できるようになったかなあという感じ。
まだ未熟なもの
- Go
- 綺麗な設計
- アプリケーション実装力
- アルゴリズムとかCSとか
色んな言語触ってしまったし、そういう環境にあったからだが、割と深いところまで学びきれなかった。
組織的にも高めていこうという気概は鈍かった気がする。もっとバックエンド開発における足腰を鍛えなければなと。
これからやること
グループ内のがっつりしたエンジニア組織（会社）に転籍する。
こう見るとエンジニア組織としてかなりモダンでしっかりとした環境に移ることになる。
自分で望んだことだし、また1から日々精進するのみ。
テーマ
これから勉強というか身に付けたいなと思っているテーマ。
過去から大きく変わらない部分の力をつける
これは、t_wadaさんの技術選定の審美眼という話の中で書かれたものからインスパイアされた。
この資料の長生きしている技術に学ぶ部分あたりをしっかりと身につけようと思う。
ちょうどRDBMS（SQL）については勉強していたところだし。
あと、個人的にはGoを結構楽しく勉強していたので、それも引き続きやっていきたい。
オブジェクト指向でなぜ作るのか 第4章を読んだ
はじめに
このエントリーの続き。 引き続き思考の整理、アウトプットとして。
第4章 OOPは無駄を省いて整理整頓するプログラミング技術
今までの章の流れから、じゃあ実際OOPってどういう特徴があって何が嬉しいの？の部分をちょっと長めに取って説明している章。
OOPには三つの大きな要素がある
- クラス
- ポリモーフィズム
- 継承
それぞれの効能（嬉しい点）については以下
クラス
- まとめる
- 隠す
- たくさん作る
上記がクラスの効能。
- 部品が減るというメリット
- 命名が楽になるというメリット
- 部品が探しやすくなるというメリット
がある。
この辺は当たり前のようにやっているので改めて説明されて再確認という感じ。逆にクラスがなかったら、とっちらかっているという説明をしっかりとされて、偉大さを再確認できた。
また、機能をクラスにまとめているので命名も楽になるし部品が探しやすくもなる。
命名は気をつけなければいけないものではあるものの、クラス内の部品という隠された内部のことであるならばシンプルに保てるよねという話。
探しやすさについてはIDEの進化も合間ってすごく楽。
ポリモーフィズム
呼び出す側のロジックを共通化する仕組み
ポリモーフィズムについては、今まで一番言葉の定義を曖昧にしながら使ってきたものかもしれない。interfaceのようなものと理解した。
自分としてはinterface設計自体があまり得意ではなく、慣れていないので、しっかりとできるようにしたい。
その効能としては、接点を共通化することで、実装を隠蔽することができる。という風に認識している。似たような処理を一つのinterfaceとして提供することで、呼び出し側での手戻りを少なくできる。
継承
複数クラスの共通する部分を別クラス（スーパークラス）にまとめて、コードの重複を排除する仕組み。
これはよく使うから馴染みがある。
ただ、クラス設計をうまくできずに巨大なスーパークラスが出来上がってしまったこともある。
個人的には継承とポリモーフィズムを綺麗に使い分けて整頓されたコードを仕上げることをできるようになることが課題かなと思う。
これで三つの説明をまとめた。
この他に、パッケージ、例外、ガベージコレクションについても軽く触れられていたので説明する。
- パッケージ
- クラスをまとめる仕組み
- PHPで自作パッケージを使用することがなかった（それほど大規模なプロダクトじゃなかった）のでイメージはComposerでインストールするパッケージやライブラリたち
- クラスをまとめる仕組み
- 例外
- 戻り値と違う形で特別なエラーを返す仕組み
- 当たり前のように使っていたが、例外がないと全てハンドリングして返さなければいけない
- Golangをちょっとやった時に例外がなくて大変だなと苦労した
- 戻り値と違う形で特別なエラーを返す仕組み
- ガベージコレクション
- インスタンスを作った時、不要になった時点で自動でメモリを解放してくれる機能
- 意識したことがなかったが、こんなに素晴らしい機能が標準で言語に備わっているのかというお気持ち
今までの章と比べるとボリュームがあったが、いい感じにまとめられていて読みやすかった。
