プログラミングを学ぶためのフックを作る試み

この記事の目的
プログラミングを学ぶ上であえて難しいものに触れて『分からないの定義』を広くし、疑問を作りやすくする。

プログラミングの全体像について考える

学習をする際、『全体像から入ろう』とよく言われるのでプログラミングの全体像を把握するために抽象寄りの考え方や原則を集めてみました。
中途半端に紹介するだけでは学習にならないと思うので、自分の認識も少しだけ混ぜました。

抽象を5個集める

集めた抽象が知的好奇心のフックになるのでは？
『これ、なんだろう？』とか、『こういうことあったな！』という体験が学習では必要になるのではないか

本題

プログラミングの抽象の表面だけを順に上げていく。

YAGNI

『You ain't gonna need it』の略で「ヤグニ」と読むそうです。
意味は、『必要になるまで機能は、実装するな』という意味だそうです。

DRY

『Don't Repeat Yourself』の略で「ドライ」と読むそうです。
意味は、『同じことを繰り返すな』という意味だそうです。

KISS

『Keep it short and simple.』の略で「キス」と読むそうです。
意味は、『簡潔に単純にしておけ』という意味だそうです。

オブジェクト指向

「オブジェクト」ってなんぞやという感じなんですが、この考え方だけに留まらず、深い理解を得ようとすると歴史に触れるのは必須になってくるのではないかなと思っています。
オブジェクトは、「モノ」を指しているそうです。そして、この「モノ」に注目した考え方が「オブジェクト指向」らしいです。

自分の捉え方では、プログラムを動かすためのプログラムだと思っています。プログラムは、人間の仕事を自動化するのが役割とされていますが、オブジェクト指向ではプログラム自体がプログラムの仕事を自動化しているんだと思っています。ドリンクバーのプログラムを作る時、コーヒーというクラスがあっても、直接人の仕事には作用しませんがプログラム全体で見るとコーヒークラスの他に様々なクラスが組み合わさり、ドリンクバーという仕事になっていると思います。プログラムを動かすための一つ一つのプログラムが互いに作用する

SOLID(長くなります)

色々な原則の頭文字をとっています。「ソリッド」と読むそうです。

S Single Responsibility(単一責任の原則)

O Open-Closed(オープン・クローズドの原則)

L Liskov Substitution(リスコフの置換原則)

I Interface Segregation(インターフェイス分離の原則)

D Dependency Inversion(依存性逆転の原則)

難しそうな言葉だらけで頭がこんがらがってきますね...。ちょっと自分なりに簡単にしてみます。

• S 一つのクラスには一つの責任だけ持たせましょうね

  • クラスは、コード上の小さな設計書です。その設計書の中で色々できるようにしたら、便利かもしれないです。
    ただ、コードの変更が必要になった時に少しの変更が大きなバグのもとになります。どこから手をつければいいのか分からないというお手上げ状態になってしまう前に一つ一つのクラスに持たせる責任は一つだけ！ということを頭の片隅に入れておきます。

• O クラスで色々なことをしたければ、変更ではなく、追加で行いましょうね

  • クラスというソースコード上の設計書がいくつも組み合わさって、プログラムが出来上がります。その中のクラスを1つでも変更してしまうと
    『プログラムが壊れる』危険があります。なので、クラスを変えたければ、変更ではなく、追加で行いましょうということらしいです。
    ただ、個人的には追加もそれはそれで危ない気がするので役割を持たせたければ、役割の分割も考えたほうがいいかなと思いました。

• L 親クラスと子クラスができることには、一貫性を持たせましょうね

  • クラスには、『派生元のクラスと同じ動きを持たせて、別のクラスを作る』といったことができます。この派生元のクラスを『親クラス』と呼び、親クラスから生まれた
    別のクラスを「子クラス」と呼びます。子クラスは親クラスができることを全て引き継ぎます。親クラスから、子クラスを作る一連の動作を「継承」と呼びます。『親クラスができることは、子クラスもできなくてはいけない』ということを言っています。これが一貫性なのですね...。
    子クラスが親クラスと全く別のことができてしまうとバグの元になるそうです。

• I クラスには、必要な動作だけ持たせましょうね。もしくは、他のクラスに移動して役割を分割しましょうね

  • クラスに必要ない動作を持たせると、予期しないバグの原因に繋がります。必要であれば、別のクラスに実装するなどして動作のセットを小さく分割したほうがよさそうです。
    なんだか、Sの単一責任の原則とKISSに近いものを感じますね。

• D 上位モジュールが動作するように下位モジュールが頑張るようにしようね。

  • ツールを使うクラスのことを「上位モジュール」と呼びます。逆にツールとして使われに行くクラスを「下位モジュール」と呼びます。そして、上位モジュールと下位モジュールの間に『インターフェイス』があります。インターフェイスの役割は、「抽象化」です。上位モジュールとインターフェイスは下位モジュールが何をしているかは知りません。ですが、下位モジュールはインターフェイスが必要としている条件を満たす必要があります。下位モジュールがインターフェイスに合わしに行くのです。インターフェイスが下位モジュールのことをいい感じに抽象化することで上位モジュールがいい感じに動作します。

💡モジュールとは「部品」です。これはそのまま覚えたほうがいいと思っています。ITに限らなければ、モジュールはさまざまな場面で使える言葉で、主語によって指し示す対象が変わる言葉だと思っています。クラスから見れば関数はモジュールだけど、プログラムから見ればクラスもモジュールになると思います。上には上がいるということですかね笑

まとめ

プログラミングの考え方は色々あるが、その目的はプログラムを良くすること

雑感

名言とか格言って言い方が強いほど印象に残りやすいのなんでなんでしょう...

最初は1時間で書き終わるつもりだったのに、『これなんだ？』ってなったら止まらなくなってしまいました...。

最初にどこまで扱うか『終わり』を決めるのって本当に大事ですね。

気付くと読者に語りかけるように文章を書いているので、もっと自分視点で正直な文章を書きたい

参考にさせていただいたサイト・記事