オブジェクト指向でなぜ作るのか 第4章を読んだ
はじめに
このエントリーの続き。 引き続き思考の整理、アウトプットとして。
第4章 OOPは無駄を省いて整理整頓するプログラミング技術
今までの章の流れから、じゃあ実際OOPってどういう特徴があって何が嬉しいの？の部分をちょっと長めに取って説明している章。
OOPには三つの大きな要素がある
- クラス
- ポリモーフィズム
- 継承
それぞれの効能（嬉しい点）については以下
クラス
- まとめる
- 隠す
- たくさん作る
上記がクラスの効能。
- 部品が減るというメリット
- 命名が楽になるというメリット
- 部品が探しやすくなるというメリット
がある。
この辺は当たり前のようにやっているので改めて説明されて再確認という感じ。逆にクラスがなかったら、とっちらかっているという説明をしっかりとされて、偉大さを再確認できた。
また、機能をクラスにまとめているので命名も楽になるし部品が探しやすくもなる。
命名は気をつけなければいけないものではあるものの、クラス内の部品という隠された内部のことであるならばシンプルに保てるよねという話。
探しやすさについてはIDEの進化も合間ってすごく楽。
ポリモーフィズム
呼び出す側のロジックを共通化する仕組み
ポリモーフィズムについては、今まで一番言葉の定義を曖昧にしながら使ってきたものかもしれない。interfaceのようなものと理解した。
自分としてはinterface設計自体があまり得意ではなく、慣れていないので、しっかりとできるようにしたい。
その効能としては、接点を共通化することで、実装を隠蔽することができる。という風に認識している。似たような処理を一つのinterfaceとして提供することで、呼び出し側での手戻りを少なくできる。
継承
複数クラスの共通する部分を別クラス（スーパークラス）にまとめて、コードの重複を排除する仕組み。
これはよく使うから馴染みがある。
ただ、クラス設計をうまくできずに巨大なスーパークラスが出来上がってしまったこともある。
個人的には継承とポリモーフィズムを綺麗に使い分けて整頓されたコードを仕上げることをできるようになることが課題かなと思う。
これで三つの説明をまとめた。
この他に、パッケージ、例外、ガベージコレクションについても軽く触れられていたので説明する。
- パッケージ
- クラスをまとめる仕組み
- PHPで自作パッケージを使用することがなかった（それほど大規模なプロダクトじゃなかった）のでイメージはComposerでインストールするパッケージやライブラリたち
- クラスをまとめる仕組み
- 例外
- 戻り値と違う形で特別なエラーを返す仕組み
- 当たり前のように使っていたが、例外がないと全てハンドリングして返さなければいけない
- Golangをちょっとやった時に例外がなくて大変だなと苦労した
- 戻り値と違う形で特別なエラーを返す仕組み
- ガベージコレクション
- インスタンスを作った時、不要になった時点で自動でメモリを解放してくれる機能
- 意識したことがなかったが、こんなに素晴らしい機能が標準で言語に備わっているのかというお気持ち
今までの章と比べるとボリュームがあったが、いい感じにまとめられていて読みやすかった。
オブジェクト指向でなぜ作るか 第3章を読みました
はじめに
このエントリーの続き。
引き続き思考の整理、アウトプットとして。
第3章 OOPを理解する近道はプログラミング言語の歴史にあり
先人たちがオブジェクト指向という「ソフトウェア開発の総合技術」にたどり着くまでの歴史について。
どのようにプログラミングは発展し、何が問題で、どのように解決してきた結果オブジェクト指向プログラミングにたどり着いたのかということを述べた章。
ざっくりとした歴史の流れは以下
- 2進数で記述された機械語 ↓
- アセンブリ言語の登場
- 人間に少しだけ分かりやすくなった ↓
- FORTRANやCOBOLなどの高級言語の発明
- より分かりやすく
↓
分かりやすさ重視の構造化プログラミングへ
- より分かりやすく
↓
高級言語の発明までは、表現力の向上に重きが置かれ、構造化プログラミングは保守性、再利用性の向上に重きが置かれている
では、構造化プログラミングとはどんなものか？
正しく分かりやすい構造にする必要がある、という考えのもと普及した。これは、当時ソフトウェア需要が増大していたことにも関係してくる。
この構造化プログラミングの基本三構造は以下の通り。
- 順次進行
- 処理は呼ばれた順に上から実行
- 条件分岐
- 命令によって次の処理を決定
- 繰り返し
- ある条件に当てはまるまで一定回数繰り返す
この理論がシンプルだったため当時受け入れられたという。
また、当時の工夫が独立性を高め、保守に強くすること。
例えば、グローバル変数の使用を少なくするという工夫。何か不正があった場合に調べる範囲が広く保守性が低いため。
自分も意識しないうちにグローバル変数をあまり使わないように意識していたので、納得感が高かった。
この保守に強い構造にするということは、プログラムの寿命が伸びたことに起因している。
当時は10年以上後も自分の書いたコードが使われるという考えはなかったという。
それが違うと分かってきて、複雑さを避け、理解しやすさを重視し、使い回しによる生産性の向上が求められるような時代に入っていった。
ただ、グローバル変数の利用制限、大規模な再利用は構造化プログラミングでは限界があったことによって生まれたのがOOPであるという。
次の章からオブジェクト指向プログラミングの話に入っていく。
オブジェクト指向でなぜつくるのかを読み始めました
はじめに
タイトルの通り。
- 作者:平澤 章
- 発売日: 2011/04/07
- メディア: 単行本
なぜ読み始めたのか
OOPであるPHPを利用して当たり前のようにLaravelで開発しているものの、オブジェクト指向は雰囲気でしか理解していないし、一度しっかりとしたインプットをして活かしていきたいと思ったから。
例のごとく1章ずつ読むたびにこまめにアウトプットしていこうと思う。
第1章 オブジェクト指向はソフトウェア開発を楽にする技術
この書籍の導入となる章。
細かな話は何もない。
オブジェクト指向とは「ソフトウェア開発の総合技術」だが、難しく感じてしまう理由は以下の通り
- 用語の洪水
- 難しい専門（横文字で聞いたことない）用語がたくさん出てくる
- 比喩の乱用
- 説明時の比喩が分かりにくく理解しにくい
- なんでもオブジェクト症候群
- 言葉が広すぎてなんでもオブジェクトになってしまう
確かに、比喩でしっかり理解できた感覚はないし、難しい用語が多いなと感じる。
しっかり読んで身につけていこうと思う。
第2章 オブジェクト指向と現実世界は似て非なるもの
まず、オブジェクト指向の三大要素である、
- クラス
- ポリモーフィズム
- 継承
について、超ざっくり説明があった。言葉の意味はだいたい知っているし、意味も分かっているが、ポリモーフィズムはうまく使いこなしてるとは言えない。
ネットで調べると、たまにあるくらいの入門的な内容。
上記1,2章が導入だった。
ソフトウェア・ファーストを読みました
はじめに
ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略を読んだので備忘録。
ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略
- 作者:及川 卓也
- 発売日: 2019/10/10
- メディア: 単行本
なぜ読んだか
最近、自分のキャリアを考えたときに、エンジニアとしてプロダクトを育てられうような人材になりたいと思った。
では、その文脈で語られる、プロダクト志向ってどんなものだっけと言語化したくなったので、この本を手に取り読んだ。
感想
1~3章はそれぞれ、ソフトウェアファーストとは？、日本の課題、必要な変革について書かれていた。
この辺はソフトウェアを外注していたような伝統的な企業がどうすべきかということを中心に論じられ、現在ソフトウェアを中心に割とモダンな環境で仕事をしている人には当たり前のことも多いかもしれない。
なので個人的には4,5章から学びや気づきは多かったと思う。
4章 これからの「強い開発組織」を考える
この章で特に印象に残っているのは、Howを考え実装するのが従来のソフトウェアエンジニアの役割だが、WhyやWhatの部分も考えるという部分（個人的に噛み砕いた解釈）
これは読書や勉強会等でインプットしているだけでできるようになることではないし、Howの部分に大きな楽しさがあることは事実なので、しっかりと開発段階で意識して、チームで議論しながらでないと身につかないものだなと思った。
幸いにも、そのような習慣をつけていたが、まだ規模が小さいので大きなプロダクトと大きなチームで挑戦したいと思った。
また、組織構造についても言及があった。職能別組織、事業別組織、マトリックス組織と言及があったが、大学の授業で履修していたのでそれらの一長一短は深くはないものの理解している。
その中でいいなと思ったのが、技術方針を定めておく必要があるという部分。
これは、意思決定の助けにもなるし、同じような志向の人が集まりチームワークも取りやすくなるのではと考える。技術方針を明確に打ち出しているチームは入る前にイメージしやすいだろうし、いいなと思った。
5章 ソフトウェア・ファーストなキャリアを築くには
この章は、章題の通りキャリアの築き方についてだった。最初にT型人材について話が出てきたが、これはよく聞く。
さらにそこから進化させるパターンが複数あるという。専門を深める=スペシャリストや、専門以外も深める=π型（パイ型）人材、専門を広げる等。
まだ、2年の経験しかないのでとにかくTを深めてきちんとしたT型になるように意識をしなければと思った。
また、この章だけじゃなく書籍を通して語られていたことだが、学びを辞めた時に人の成長は止まる、学び続ける必要があるというメッセージ。深く同意だ。
その他メモに残っている印象に残った言葉や考え方、自分が考えたこと
- 現代社会における多くの仕組みがソフトウェアで構成されている。→つまり世の中にインパクトを与える機会が多い
- ソフトウェアはユーザーエクスペリエンスを実現するためにある。その体験がユーザーの感情を動かす
- どのような立場にいても変わらずに変化し続けることを大切にしたい
- 生存戦略よりも成長戦略
まとめ
技術書と違ってさくっと読みやすいので、のんびり読みしてしまう自分でも1日1章で5日で読んでしまった。
読み物として面白く、納得感も得られたので読んでよかった一冊。話題になるのも分かるなあという感じ。
著者の及川さんありがとうございました。
SQL アンチパターン第21,22章を読んだ
はじめに
SQLアンチパターンについて
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
第21章 シュードキー・ニートフリーク（擬似キー潔癖症）
テーマとしては、主キーに欠番があることだった。
個人的には、気にならない。
アンチパターンとしては以下が挙げられていた。
- 欠番を割り当てる
- 複数台のアプリケーションサーバから同時処理が行われた場合に、片方がエラーになるため良くない
- 既存行に番号を振り直す
- ステップ数が多い
- そのキーを参照しているレコードがあった場合にそちらもupdateする必要がある
- キー管理テーブルの変更も伴ってしまう
上記のようなリスクがあるため、基本的には変更をかける必要がない、識別のための番号なので連番である必要性はない。
また、GUIDについても言及があった。
GUIDとは、128bitの擬似乱数のこと。
同じ識別子が振られる可能性は極めて低いが、ディスクの使用スペースが多く値が長いことがデメリット。
第22章 シー・ノー・エビル（臭いものに蓋）
テーマはクエリのコーディングについて。
アンチパターンは以下。
- 診断せず判断する
- データベースへのアクセスした後のクエリを確認しないこと
- 画面には何も表示されないことが多い
- 見逃しがちなコード
- SQLクエリの構築時のコードしか読まないこと
ここに関しては、かなり起こりにくいアンチパターンかなと感じた。
開発者として、返り値の確認や、期待した結果が得られなかった時のデバッグ過程の中で発行されたクエリを確認することは当たり前だと思う。
灯台下暗しみたいなことなのかな。
SQL アンチパターン第20章を読んだ
はじめに
SQLアンチパターンについて
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
第20章 SQLインジェクション
ここら辺もフレームワークがよしなにやってくれる箇所だから意識していないが、意識しなければ。
難しいのは、望まない操作を許可しないように、ソフトウェアをセキュアにすることです
大事。
対応策として用意されているのが以下。
初学時にプリペアドステークスで対策をするように言われたことを思い出した。
この一言で、改めてアンチパターンは知識として持っておくべきだと感じた。
また、「20.5.1 入力のフィルタリング」や「20.5.4 ユーザーの入力をコードから隔離する」に関しては普段から慣れてできている。改めて確認することができてよかった。
まとめ
この章の内容もある程度知識として持っているものだった。
ただ、フレームワークを使い慣れているとどうしてもそこまで深くは意識しないので、アンチパターンに対して正しい対策と、レビューを心がけようと思った。
初学者時に、プリペアドステートメントでSQLインジェクション対策を行なっていたことを思い出した。
SQL アンチパターン第19章を読んだ
はじめに
最近結構読書をしているが、まとめてというよりはこまめに読むかつ、厚めの本を読む機会もあるのでインプットしたことをなるべく早めにアウトプットしようと思う。
SQLアンチパターンについて
- 作者:Bill Karwin
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
第19章 リーダブルパスワード
めちゃくちゃ普段から意識しなければならない内容。
アンチパターンについても、うなずける内容だった。
めちゃくちゃうなずける反面、普段使っているLaravelだと意識せずとも、Hashファサードが用意されており、簡単にできてしまうのでアンチパターンとして学ぶことができてよかった。
なので意識すべきことは、
- SQL文に平文のパスワードを含めない
- 予めハッシュ化したパスワードをデータモデルに引数で渡すことで解決
かなと思う。
また、リセット手法については書籍に記載している、トークンを用いる方法を使っている。
Laravelでは使用したことはないが、これも用意されているみたいですね。
