こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。
弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております)
さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。
なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。
「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ
いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしている、といったのはHead Firstシリーズを題材にして、複数人で読んでみている」とのことだったので、大体そんなレベルを想定しています。
オススメ
この状態で「デザインパターンを一生懸命勉強する」ことについて、まずメリットや良さそうな所を考えてみると・・・
- そもそも、自学や自習について「外れてはならない、正解の勉強法」なんて無いように思います
- 気が向いた時、その存在を知った時、手に取ってみた時こそが「勉強してみるチャンス！！」と考えるのもアリなはずです
- もし、コレが「仕事として、教育コンテンツを考えていてカリキュラムを組んでいる」といった場面であれば、適切に順序やタイミングを考える方が良いと思いますが・・
- しっかりと考察しながら理解することは難しかったとしても、一部のパターン(例えばテンプレートメソッドパターンとか)についていえば、実例を目にする&気づける場面は増えてくる可能性があります
- 同じチームのメンバーや同僚が書いたコードから、実践例を見抜くことが出来れば、(自分の今のレベルを先回りした)「予習」をしておくことで、現場での学びが増大したり、あるいは共通の語彙を持つチャンスが開けると思います
といったポイントが浮かびました。
オススメナイ
他方で、「デザインパターンを勉強する上で、効果を最大化したい・効率も良くしたい・すぐに実際の開発に活かせるようになりたい」などなどの観点でみると、「早すぎるデザパタ」をオススメしにくい理由も考えられます
- その威力を実感するための前提を整えてからでも遅くない
- デザインパターンは「ソフトウェア開発においての課題を解決しやすくするため」の知識なので、「どういった点で、どういった課題が、どのように現れるのか」を実感できるようになってからこそ、効果を上げやすいものになります
- デザインパターンは「どう使うか」の問題であり、適用する眼が必要
- 「特定のコンテキストにおいて、よく考えられたトレードオフのもとに、問題を解決するための方法が記述された実装テクニック」がデザインパターンです。裏を返せば、「何にでも聞く万能薬や統一理論」ではありません
- そのため、「形式通りに使えているか」よりも「いつ使うか」の方が重要であり、こちらは特に開発者の経験値を問われます
- 「ゴールデンハンマー」に見えやすい
- デザインパターンは「よくできた、みんなが知っている、よい実装のための実践レシピ」として知られているが故に、それを初めて知った人にとっては「金槌を持つと全てが釘に見える」かのようになりがちです。とにかくデザインパターンを使ってみたくなる！！は、多くのプログラマーが通った道なのではないでしょうか
こうした理由で、「まずデザインパターン」は、中々シビアな道のりとなるのです。
それを避けるには、「形式的に知識を吸収する」のではなく、そもそもの「デザインパターンが必要とされ、広く受け入れられるようになったのか」といった、コンセプトそのものについての背景や動機を知り、共感しながら学ぶのが安全なように思えます。
「なぜ」を楽しみながら、学びの階段を描いていく
という訳で、「デザインパターンの(学習の)罠」を避けるためにも、「なぜ(それが生まれ、受け入れられてきたのか)(それが必要とされているのか)」「何を解決しようとしているのか」を知っていくのが、良い感じにやっていくためのヒントになると思います。
もし、何かを学ぶ時に「その前段」の課題について知らないと、前に進むのが困難になりがちですし、その逆も然りです。
太郎君は、Xを覚えるよりも近所の公園で友達とサッカーをやりたいことでしょう。正二さんは、本質を感じ取りながらXの話を聞いてくれそうですよね。コレには博士もにっこり
デザインパターンが、何に基づき何を解決しているのか
(GoFの)デザインパターンは、「オブジェクト指向における再利用のためのデザインパターン」です。
すなわち、「オブジェクト指向がやりたかったこと」について、典型的に「問題」「解法」を形式化して体系化したものこそが「デザインパターン」であり、みんなが困っている「あるある」を相手取ることで「色んな人同士で再利用しよーぜ！」という価値を提供しているものと言えます。
では、「オブジェクト指向がやりたかったこと」とは何か？についても、考えてみてはいかがでしょうか。
それが、ソフトウェアの設計原則です。
(他の分野とは少しニュアンスが異なり、)ソフトウェアの設計で言う所の「原則」については、「良く出来ている設計・実装が一般的に満たしている(満たされるべき)、典型的な要素」が「原則」と呼ばれます。
例えば「DRY原則」など、(法則・定理と違って)簡単に破ることができますが、「あるべき姿のソースコードはDRYになっている」といった調子です。
そして、利用している言語やFW等によって、「どんなものが良しとされるか」は異なります。そのために、GoFのデザインパターンはあくまで「オブジェクト指向における」という修飾語が欠かせないのです。
そうすると、次の「なぜ」は「どうして、オブジェクト指向なの」になります。
オブジェクト指向というパラダイムを採用しているプログラミング言語においては、「解きたい課題が、オブジェクト指向っぽいものと相性が良さそうだぞ」と価値判断をしたはずである！と仮定できますよね。
オブジェクト指向がどんなパワーを与えたのか、オブジェクト指向らしさとは何か・・・コレが、原則の上位に存在する「価値」となり、原則を導き出すための「命題」となっていきます。
更に更に踏み込んでいくと、「オブジェクト指向などの、あるいはそれ以外でも、プログラミング言語がなぜ存在するのか？」と、その上位の命題を求めていくことになります。
それはもはや、「ソフトウェアとは何であって、何でないのか」に繋がっていくはずです。
コレについていえば、「コンピューター以前の機械」「ソフトウェアが生まれたことで、解決した問題」まで紐解けば・・・・・
少なくとも、単一の機能を果たすだけの計算機と比較すると、「単体の機械でも複数の異なる問題を相手にできる道具」たらしめる = 柔軟性をもつことは「ソフトウェア」の特徴であり、コレがソフトウェアなる存在の価値を唯一無二なものとしている強みなのだと思います。
大概のものは、より「上位」の課題を解決するのを支援するために存在する
様々な概念は、「それ単体でポッと出てきた」のではなく、何かしらの必要性が生じたり経験の中で発見されることで「必然的に見出され、確立してきた」のだな〜という感覚が共有できましたでしょうか。
「何故コレが必要なのかが分からない」という時は、「より上位の問題の解決を支援するためのものだ」と考えて、学習目標を追っかけて行ってみるのが1つのコツかと思います。
それによって、「公式丸暗記」ではない「原理原則への共感を以て思考できるようになるツールを手に入れる」ことに近づけるはずです。
デザインパターンの目的
そもそもの「デザインパターン」という手法が、何を解決しようとしているのか？どうして、この形になったのか・・？については、「パターン、Wiki、XP」という素晴らしい書籍があるので、ぜひ1度読んでみてください・・・・
そして、今度は「GoFのデザインパターン」もしくは「オブジェクト指向プログラミングのデザインパターン」に絞って話をすると、「特定のコンテキスト(設計や実装の課題)において、オブジェクト指向パラダイムの強みを活かした、典型的な実装例」を提供してくれます。
豊富な経験を持つ開発者たちが、自身が関わった開発の中で何度も目にした問題と、そうした問題に対して何度も繰り返し利用できたような設計をまとめたものです。
一方で、「名前が付く前」は「個々人の中にあった、経験則的に、くり返し使っているアレ」だったことも確かで、そういった意味でも「絶対の正解」としてのデザインパターンは有り得ない・・・と言えるのではないでしょうか。
設計原則の目的
先に「オブジェクト指向パラダイムの強み」という表現を用いましたが、そういう「しっかりと強みを発揮できているコード(≒「オブジェクト指向らしい」コード)が備えているべき「原則」があるもの、と考えられます。
オブジェクト指向において重要とされる原則は、そのプログラミング言語自体(仕様や機能)として実現されていたり、デザインパターンなどの利用によって支援されていたりします。
こうした原則について理解を深めることで、デザインパターンの真価や、あるいは「デザパタに現れる形式に囚われすぎない応用力」の獲得にも繋がります。
現在、オブジェクト指向において最も特徴的な原則といえば「SOLID原則」と言って良いかと思います。
ざっくりとWikipediaを貼っておきますね。
「オブジェクト指向のための原則があって、そこからパラダイムが実現した」のではなく、オブジェクト指向言語が普及してベストプラクティスが見出されてきた中で、パターンやプラクティスよりも強固な存在として(=よく従われる、例外が少ない)原則が存在するのです。
SOLID原則の目的は、以下のような性質を持つ中間レベルのソフトウェア構造を作ることだ。
●変更に強いこと
●理解しやすいこと
●コンポーネントの基盤として、多くのソフトウェアシステムで利用できること「中間レベルの」という言葉は、SOLID原則がモジュールレベルの開発に使われるものであることを意図している。コードレベルよりも上に適用するものであり、モジュールやコンポーネントで使うソフトウェア構造の定義に役立つ。
Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘. Clean Architecture 達人に学ぶソフトウェアの構造と設計 (Japanese Edition) (Kindle の位置No.1113-1118). Kindle 版.
オブジェクト指向パラダイム(言語)の目的
ロバート・C・マーチン氏によれば、少なくとも「うまくオブジェクト指向をやっていく」ために「変更に強いこと」「理解しやすいこと」は重要であると考えているように見えます。
ただし、コレも「オブジェクト指向で上手くやれる」ことが後天的に発見された強みであり、必ずしもパラダイムの源流となるソフトウェア(言語)やアイディアが、そうした要素を視野に入れていたとは断定できません。
重要なのは、歴史上の問題ではなく、「実際に現代の社会で広くオブジェクト指向言語が普及し、上手く使おうとしているプログラマーやデザイナーが多くいる」ことだ、とこの記事においては設定したいと思います。
それでは、オブジェクト指向の強みはどこなのか・・・そして、その要素が「変更に強いこと」「理解しやすいこと」と、どう結びついているのでしょうか？
#ちょうぜつ本 によれば、「オブジェクト指向の定義はない」であり、その一方で、オブジェクト指向的なモノの見方 = パラダイムによって、得られたメリットとして「カプセル化」「多様性」「継承/汎化」の3つなのではないか、と記述されています。
個人的には、オブジェクト指向の強みとは突き詰めれば「抽象化の実現」にあるのではないか、と今の時点では考えています。
そもそも、(生産性に着目した場合の)プログラミング言語の進化は、突き詰めれば抽象化なのだと思うのです。すなわち、「物事を分かりやすくするのを助ける力を、強くしていった」のではないでしょうか。言い換えると、「良いコードを実現するために、良い抽象化を用いる」という感じです。
カプセル化は「具象を知らなくても操作が可能になる」ような能力ですし、そうやって具象と抽象を切り離されて「抽象ベースの実装が可能になる」ことでポリモーフィズムが実現されます。
コレによって、確かにシステム全体の構成は複雑になる(例えばファイル数が増える)かも知れませんが、モジュール(クラスだったりメソッドだったり)の1つ1つを見ると「行数や分岐が少ない」ような状態が実現されていきます。
何かを知ろうとした時の「ここまで把握しておけばOK、その先の詳細なことは放っておいてね」という線引がされるので、「複雑」だけど「付き合いやすい」状態だと言えて、コレは人間にとって利便性が高そうですよね。
大規模な開発に秩序をもたらし、人員増加や保守期間の長大化であったり、要求の激しい変化に対応する柔軟性の獲得は、抽象化(もしくは抽象と具体の分離・整理)によって支えられているものだと、個人的には考えるところです。
このコンセプトが、設計原則やパターン、アーキテクチャパターンにおいても「果たすべき目的」として、継承されている・・・と考えると、「なぜ」を理解するための補助線になると思います。
1歩ずつ学んでいくためのヒントになりそうなコンテンツ・文献の紹介
例えば「最終的に、GoF本やPoEAAだったり、IDDD本を読みたい！」という所を目指すとしても、その前に色々と寄り道をしていって良いのでは〜という感覚は伝わったでしょうか。
その視点に基づき、「具体的に何かオススメある？」という、冒頭の問いに立ち返ります。
遠回りしましたが、ここからが本題です！！！
「分かりやすさのために遠回りする」というコンセプトである以上は、「とっつきやすさ」も大事だと考えています。[2]
抽象的な話になると、専門性が高い本(分厚かったり難しかったり、理解するのに技術書慣れや開発経験を要するもの)が増えてきてしまう印象があります。 (商業的な理由もありそうかも・・？)
他方で、そのあたりは、カンファレンスや勉強会での発表で非常に秀逸なものが多くあります。という訳で、そうしたコミュニティから生み出されてきたコンテンツを積極的に取り上げてみます。
(自分が普段出入りしている関係で、PHP系のコミュニティのものが多いです)
必修
「オブジェクト指向パラダイム(言語)の目的」の所でちらっと触れましたが、結局のところの動機は「良いコードを書くためには？」であるとも言え、それは恐らく「デザインパターンを学んでみたい」という学習欲求を持つ皆さんも同じだと思います。
そんな訳で、まずは「良いコードをについて考える」ところから入りたいです。また、あまり大きな話になりすぎずに、具体・実践に近い話からが良いので〜と考えます。
今であれば、まずこの2冊は必修と言って良いのではないか・・・と思います。
コードは(変数名にせよメソッドの切り方にせよ)あらゆる場面で最小の設計行為であると考えていますが、リーダブルコードはまず「コード単位での読みやすさ」に触れさせてくれますし、「良いコード/悪いコード〜 (ミノ駆動本)」は、そこから少しステップアップして「設計への橋渡し」をしてくれる1冊だと感じています。
「抽象」について理解を進める
IMOですが、とにかく「抽象化」こそパワーだ！！！ということですので、「そもそも抽象化ってどのようなものですか、何がいいんですか」について共感してほしいのです。
そこに役立つ資料やコンテンツを紹介していきます。
また、抽象を考えるに当たって「関心」「目的」「責務」というのがでてきたりします。
抽象とは「突き詰めて言えば、お前はなにであるか」に対する答えであり、ソフトウェアという人工物においては「全ての存在は、必要とされて存在させられている」ものですから「なぜ、そこにいるのか」という目的を持ちます。他者(開発者)によって存在させられ(設計)て存在し(定義)ている存在(オブジェクト)なのですから、それぞれが目的を持っているということは、他者に対して責務を持っている訳です。目的を果たすために「なにを、どこまで扱うか」が「自身の関心」となりますし、そのために他の存在を利用するならば「他者への関心」を持つことになります。
オススメするもの
いきなり技術トピックではないです！
が、「抽象とは？具体とは？」について、平易な説明で優しく解説している本ですし、プログラミングとか関係なく仕事一般に役立つ話ですのでぜひぜひ。
コレを読めば、よくある「抽象的って漠然としていること」みたいな勘違いと訣別できます！
「ソフトウェア(設計)における抽象の力」について、この成瀬さんの発表は初学者向けに抜群だと思います。リーダブルコードを読んだ+αくらいの経験値があれば、十分について行けそうな気はします。
こちらも基本的なレベルの説明でありつつ芯を掴んだ解説を味わえるので、おすすめです。
その次に、少し概念的な説明も含むようなお話を。
視聴者のレベルによっては少し難しいかも知れない(Interfaceを使ったことは無いな、知らないな・・となると、もしかしたら置いていかれるかも)ですが、そうした場合でも「細かいことは気にしないで少し見てみよう！」というのをオススメしてみます。
「抽象のハシゴ」という概念が出てくるので、それだけでも抑えていただけると。
より実践的、「どういう時に抽象性を意識することで、コードの柔軟性を保護できるか」といった話に踏み込んでいる発表です。
先の2つとは違った方向性での難しさがある内容ですが、プログラミングにおける「良い抽象化」を改めて考えてみるヒントをもらうことが出来るかと思います。
「依存」について理解を進める
責務や関心といった言葉を出しましたが、「他者に関心がある」というのを「依存している」といえます。
例えば「データベースに接続しているモデルクラス」は「モデルがデータベースに依存している」といえますし、「ファイルログを書き出しているコントローラークラス」は「コントローラーはファイルロガーに依存している」といえます。
システムとは、複数の要素が相互に関連しあって1つの目的をなすものですから、必ず「依存」「関連」だったり「コラボレーション」が発生します。
コレを上手くいなしていかないと、良いコード・良い設計にはなり得ませんので、極めて重要です。
オススメするもの
悪い依存が引き起こす問題、それをどう避けるか、良い依存とはどのような状態か・・といった、基礎的な理解を得るためにめちゃくちゃ良い発表だと思います！！
1回で難しくても、ぜひ2回3回と観てみてほしいです。
依存や関心というのは、言ってしまえば「何を変更すると、どうなるか」という影響を考察することであり、そこを上手くコントロールすることがソフトウェアを柔軟に保つために非常に重要です。
それを語ったのが「SOLID原則のO」であり、それを平易で明快にまとめてくれています。
「責務」「凝集/結合」について理解を進める
責務とは、「システムの中で、誰が・誰に対して・何の責任(≒目的)を持つか」という考えですが、こうした責務や依存についての状態(品質)の説明として、「凝集(度)/結合(度)」といった概念が用いられます。
また、「依存=繋がっている」というのは、「結合」ともいえます。
言ってしまえば、オブジェクト指向の実践とは「高凝集・低結合なオブジェクト群をつくり、依存関係の方向性の秩序を保ち、それによって開放閉鎖原則を良く守ること」なのではないか、とすら思います。
オススメするもの
そうした重要な概念である「凝集・結合」について、解説している動画です。
ややレベルが上がりますが、こちらでも詳細に「凝集度」「結合度」について説明がなされています。
どちらも非常に秀逸な資料・記事ですが、内容(話題のスコープ、深さ)的には大きく違いがあるものではないので、片方だけでも良いと思います。良いと思いますけど、どっちも読むと良いんじゃないでしょうか！！とも思います。
「責務」と「関心」が密接に関わることについては述べたとおりですが、折角なので「関心をどう扱うか」「オブジェクト指向や”モデリング”における関心事が、どのようにシステム設計の中に現れてくるか」についての話となります。
「アーキテクチャ」についての主題を設定した発表ですが、原則的な話・概念的な話より少し「実際の世界での形(=応用)」の話なので、「責務の問題」について感覚を捉えてみる手助けになるかと思います。
抽象化の力 = 変化に強いコードを保つための「変動性」について理解を進める
抽象化をすることで「具体を切り離す」という話はしましたが、それと同時に「複数の登場人物における共通性を見抜いて、まとめあげる」ことが、ソフトウェア設計における抽象の活用方法となります。
(この「まとめられた対象が持つ差分」のことを変動性とかバリエーションとか言ったりします)
ココを理解することが「ポリモーフィズム」を使いこなすことにも繋がっていきますし、変更に強いコードができあがってきます。
オススメするもの
「バリエーションってどういうものだろう」といった感覚を、具体的な例を用いて想像しやすい発表なのではないでしょうか。
必ずしも、このセッション中で「共通性」「可変性」などの概念について体系立てて説明をしているわけではないですが、その辺りへの厳密な定義などについて興味が湧いてきたら(難しい)本wyお読みましょう！
こちらも「バリエーションをどういなすか」という話になりますが、少しレベルは上がります。レベルが上がるというか、先回りする必要が出てくるというか。
「デザインパターンを学んでみたい」といった動機を持っている場合、これぞ「パターンを勉強して見る価値」を示してくれているような内容であると、個人的には感じるところです。
ココら辺でそろそろ・・・
SOLID原則的な話について行ける土台が整ってきたと思うので、「オブジェクト指向」「SOLID原則」といった話題を扱っている書籍を接種してみてはいかがでしょう。
このあたりが、自分でも好きですし周りでも評判の良い本に感じます。
先の2冊、翻訳本であること・(PHP利用者にとっては)PHP以外の言語であること・ボリュームもそこそこあること、と技術書の読書経験が少ない人にとっては少し苦しいかも知れません。
(会社の先輩とか捕まえて一緒にチャレンジしてみて欲しい気はする)
というのに対して、こちらの #ちょうぜつ本 は強くおすすめできる本です。
文章が平易で日本語として分かりやすく、扱っている範囲もオブジェクト指向やSOLID原則〜クリーンアーキテクチャ、デザインパターン、更にテストやアジャイル・・・と「原理原則などの基礎的な概念と、今風の開発なら触れることになるプラクティス」と、 一通り揃う 感がとても強いです。
トピックが幅広いので、全体のページ数に比べると、個別のトピックに対する軽快さを感じる読後感になると思います。
書籍で言うなら？
技術書を読んで学びを得ることに、さほどハードルを感じないようであれば、「例えばこんな順番で学んでいってみるのはどうでしょうか？」「その際には、こんな本はどうでしょうか？」というリストも記載してみます。
ただし、めちゃくちゃ主観的・・というか「パッと思い出した本のタイトルを並べてみる」くらいのノリなので、他にオススメがあれば拡充していきたい気持ちです。
- 「読みやすいコード」として、変数名や分岐の扱い方について
- 結合や凝集度について(・・・の原理や概念・定義というより、「それらで説明ができるようなアンチパターンや品質」について)
- 抽象化、カプセル化、多態性などの概念
- SOLID原則・オブジェクト指向
- デザインパターン
- レイヤードアーキテクチャ、ヘキサゴナルアーキテクチャなどのアーキテクチャパターン(戦術DDD含む)
- ドメイン駆動設計
5以降は、「易しい・読み易い順」にはなってない気がしています。
また、なるべく洋書は避けたいものの、ちょっとDDD Distilledと同じくらいの存在感・評判の翻訳本が見当たらないかなぁという気がして・・・技術同人誌に頼ってみると、何か掘り出し物があるかもですね。
最後に
デザインパターン/アーキテクチャ攻略チャート
おおよそ、ここまでの話を整理して「こういう順番でトピックをつまみ食いしていくと、学びの地図が広げやすい・歩みやすいのかな」というのが以下のリストです。
- 基礎文法
- そもそも「コードを書く」人ですよね？
- 「良いコード」や読みやすさ
- 「良いコードを書いていこう」という意識・課題が、まず何よりも根っこにあるはずだ！という話でした
- オブジェクト指向
- 設計の「原則」を知ってから、応用に入っていきたい
- 凝集度・結合度
- SOLID
- 設計の「原則」を知ってから、応用に入っていきたい
- デザインパターン
- パターンとして現れてくる色々な形式を見て、「なるほど、これなら確かに」と共感できる武器を増やしてから、望んで欲しいです
- ただ、必ずしも「GoFのデザインパターン」から入らなくてもいいと思います。王道ではあるのでどこかで触れて見る価値は大いにあるものの、最初の一手としては抽象度や規模の面でレベルも高いと思うので
- リファクタリング などは強くオススメ
- アーキテクチャ(アーキテクチャパターン)
結局、「どこまで学んでからデザインパターンに手を出す」のが良いのか？
ただし、あまりに外堀や背景を埋めていく事に拘りすぎても、道が遠くなるのは事実。
「欲した時が適切な時」ではあるのと、「具体例や、典型的なやり方」を学ぶことで、原理原則についての理解度が深まったりする効果もあるかと思います。
なので、「適度なタイミングでジャンプして、手を出してみる」のはアリだと思うんですよね。分からなかったら戻ればいいですし。
と考えると、「とりあえずこのあたりの概念は何となくでも感覚掴んでおいてから、デザパタやってみるのが良いんじゃない？」でいうと、
- 抽象(化)とは？
- カプセル化とは？
- 責務、依存、結合とは？
- ポリモーフィズム、何が嬉しいの？
みたいな概念について、基礎的な知識を仕入れてみてから、いくつか「分かりやすいデザインパターン」について知ってみると楽しめそうな気がします。
そんな際に助けになりそうなリンクを置いておきます。
(TECHSCOREさん、今までにめっちゃお世話になっているので、貼らせていただきます。)
を読んだ上で・・・
「テンプレートメソッド」「ファクトリ」「ストラテジ」は、分かりやすく「行数や分岐を減らす」ようなイメージを掴めそうです(主観です)。
端的に言えば、行数や分岐を減らしているということは、「責務が明確になって凝集度が上がっている」「共通性と変動性の分離が進んでいる」ことのサインにもなりやすいです(決してイコールではありませんが)。
このあたりも、今でもよく見かける形なので、パターンについて学んでみたり普段触れているアプリケーションやフレームワークの中から実例を探求してみると面白いかと思います。
SOLID原則について知りたいです
Clean Architectureは「SOLID原則」と「パッケージ原則」についての本だと思って良い気がします。書籍タイトルの「アーキテクチャ」は、それらの原則を形にしたらどんな構造になるのかな・・？を試してみた、くらいの感覚で良いのでないかと。
ということで、覚悟が出来たらどこかで手を出してみるのが良いのではないでしょうか。
終わりの終わりに
上手くまとまっているか自信がないのですが、長くなってきたのでおしまいにします！
ココで紹介している資料・発表動画については、あくまで「自分が知っている」「いま存在を思い出せた」というものになるので、偏りがあることをご容赦ください。
「こちらもオススメ！」といったものがあったら、是非コメントなどで教えてください。
NE株式会社のエンジニアを中心に更新していくPublicationです。 NEでは、「コマースに熱狂を。」をパーパスに掲げ、ECやその周辺領域の事業に取り組んでいます。 Homepage: ne-inc.jp/
Discussion