デザインパターンの学習は長期計画で
C# でデザインパターンの学習中。今回は中身の話ではなくて、Object-Oriented Programming (OOP) でのデザインパターンについての雑感。今日はObserverパターンの章を終えた。
ちなみにサンプルコードはJavaですが、Web上にソースコードが公開されているのでそれをDLしてChatGPTでC# に変換して使っています。ほぼ一緒なのでChatGPT変換しなくても、クラスとインターフェースの継承の記法の違いを理解できれば、ほぼ学習に支障ありません。
（約 3,700文字の記事です。）
これまで学んだこと。
Strategyパターン
Observerパターン
まず、いきなりは使えない
はっきり言って受験勉強だと思ったほうがいい。2, 3ヶ月でどうこうできる内容じゃない。1年計画で学習しないといけない。100時間程度で何とかなる話じゃない。なのでOOPで実際に何かを作ろうと思ったらそれなりの時間をデザインパターン学習につかわないといけない。
デザインパターンは経験の再利用
コードのコピペとかいうレベルじゃない。経験を再利用するわけなので、まずその基礎となる経験が必要。つまりはデザインパターンに関する理解という、絶対的な経験が必要。これは実務経験とかの話じゃない。デザインパターンに関する理解という経験だ。
プロシージャルなプログラミング経験が何年あったとしてもデザインパターンの理解にはあまり役には立たないと思う。
デザインパターンとコードの仕組みの相関性
デザインパターンを学び始めて少しずつ分かってきたことがある。まず、とあるパターンに対して「概念とコードの仕組み、UMLクラス図の関係性」に、ある程度の規則性があるということ。ま、最初から「デザインパターン」っていうくらいなので、パターン、金型、空手のような「型」がある。その型＝パターンと、それを使うことで手に入る「恩恵」、そしてそれを実際にコードとして表現する場合の「癖、特徴、書き方、コードの構成の特徴」みたいなものが、あるのだ。
この本に書いてあるのだが、パターンは発見したり生み出したりするものではない。すでに完成されたパターンを使って、車輪の再発明を回避しつつ、成功率の高い「枯れたパターン」の使いこなし、これでほぼどんな問題にも対処できるようだ。そしてもしそのどのパターンにも該当しない場合に、ようやく頭をひねるわけだが、そこでもデザインパターンの大原則を守って対処をしていくのみらしい。
そして当然ながらどのデザインパターンでもその原則はきちんと守られている。
なんでそういう風にコードを書くのか分からなかった
これもだんだん分かってきた。コードの構造を設計し、メンテしやすいような設計がすでに各デザインパターンでもう作られている。なので実は「なぜそのような発想でコードを書くのか？」の解釈を始めると永久に迷路から出られない。実はそのコードは、そのデザインパターンをもっとも効率的にコードに書き起こすために先人が工夫を重ねた結果の「型」だったのだ。だから「なぜこう書くのか？」の理解よりも、なぜそういう設計なのかの理解が先。その設計思想が分かれば、あとはそれを具現化するためのコードの書き方はほぼ決まる。なので各デザインパターンの設計思想の理解とコードの理解の両方が必要。片方だけだと役に立たない。
コードだけを見たらまったく意味不明な実装なのだが、デザイン（設計）からたどって解説を読んで、コードの実装を理解し、その往復でようやく○○パターンの特徴とメリットが分かる。（デメリットまではさっぱり分からない😭経験が足りないから。のちのちに分かるようになるらしい。）そして例題に対してサンプルコードのようになった理由を追体験して、ようやく1つのデザインパターンを理解した「つもり」になれる。
1つのデザインパターンを複数の例題で理解しないと本質が身に付かない？
ただし1冊やるだけでは各パターンに1つか2つの例題しかない。だから複数冊のデザインパターン本を学習することで、ようやく1つのデザインパターンのコアを理解できると思っている。少なくともそういう練習をすれば、「自分だったらこう考える、実装するが、教科書では別の方法になっている。なぜ？」を考えられるようになってようやくOOPの使いこなしが始まると思っている。だからまだ全然経験が足りない。
学習なので、言語学習なのでとにかく理解と反復しかない。ただしOOPは単なる言語学習と違って「丸暗記」はまったく役に立たない。思考停止で写経してもまったく身に付かない。ただのタイピング練習にしかならない。あくまでも「理解した内容の再現のための反復」が必要だ。理解の欠落を埋めるための反復練習だ。
OOPなしでもプログラミングできる！
まずはここだ。勘違いしていた。だが自分自身を振り返ってみても、実はOOPなしでもプロシージャルなコードでプログラミングはできる。入力・処理・出力、これができれば立派なプログラムだ。問題解決できていればそれでいいのだ。欲しい結果が手に入るツールになっていれば中身はどうでもいいのだ。
だからあまり難しく考えないで、プログラミングでやりたいことが実現可能ならば、どんなコードを書いたっていいのだ。とくにアマチュアならばなおさら、楽しむことや楽なツール作りに絞ってプログラミングしたっていい。OOPだからって突然に高性能になる分けじゃない。リファクタリングしただけなら結果に何の違いもない。
だからやたらめったらOOPにこだわる必要もない。
趣味やアマチュアでいいならば。
ただしプロ、職業プログラマを目指すならば、絶対にデザインパターンは必須の勉強だ。OOPができない＝デザインパターンの学習経験がない＝実装済みのOOPコードが読めない＆理解できない＝当然開発も実装も改良もできない、ことになる。プロとしてはかなり致命的だと思う。少なくとも面接で厳しい結果になると思う。
職業プロとしてはデザインパターンはどうやら共通言語としての位置付けがあるらしい、この本によれば。もっとも日本の現場ではどうか分からないし、プログラミングにも色んな業界・分野があるので一概には言い切れないかもしれない。だがプロにはOOP、デザインパターンの学習経験は必須だと思っている。
AIがプロシージャルコードを秒で出してくれる
というのもChatGPTやCopilotほか、様々なAIが秒でプロシージャルなコードを出力してくれるからだ。仕様を言葉で説明したり、疑似コードを提示して「あとはC# で清書して」と指示すれば綺麗なコードが出てくる。
だから実はもう、プロシージャル・プログラミングを人が手で行なう意味・価値はどんどん低くなってきている。あるとすれば言語体得のための練習としてのコーディングくらいであって、実務で手打ちかAI出力かはもはやどうでもいい気がする。むしろエラー処理などの点でAIのほうが気が利いたコードを書くことすらある。
そうなるとプログラマの仕事は、プロシージャルコーディング以外の何か、ということになる。私はそこが「OOPの理解とデザインパターンによるプロシージャルコードの編集＆実装」だと思っている。
もしAIがデザインパターンのコードを出力できるようになったとしても、それが本当に意図した設計（デザイン）の通りになっているかどうかを人が目視で判定する必要がある。そう、結局はOOPとデザインパターンの理解がないと詰むわけ。AIの出力したコードが意図したデザインパターンにマッチしているか、間違っているかを判断するためには、結局は本人がコードを書けるレベルでOOPとデザインパターンを理解していなければならない。
私がデザインパターンの習得にこだわっているのはこのためだ。プロシージャルの次、OOPでもしAIがコードを出力できたとしても、今の私にはその有効性を判断するための知恵も経験もない。だから学習開始したわけです😊
こつこつ時間とエネルギーをかけて学ぶしかない
なのでデザインパターンの体得には1年単位の学習が必要だと思う。学習曲線がかなり急だと思う。実用的なデザインパターンを網羅して、他人のコードと元になったデザインパターンを比較して、どこが良いのか悪いのか・間違っているかの判断ができるまでには、相当かかると思う。だがそれができるようになれば、「できる人とできない人との間の差」はとても大きいと感じる。私はここに何かがあるような気がしてならない。
だから知ってしまえば、答えが自ずと分かると思う。だからコツコツ学習中です。
その向こうにあるものは何なのか、これを知りたい。
今回の創作活動は約45分（累積 約3,920時間）
（1,163回目のnote更新）
筆者はAmazonアソシエイト・プログラムに参加しています。（AmazonアソシエイトとはAmazon.co.jpの商品を宣伝し所定の条件を満たすことで紹介料をAmazon様から頂けるという大変ありがたい仕組みのこと。）
以下のリンクを経由してAmazonでお買物をするとその購入額の1～3％ほどのお小遣いが私に寄付されます。誰が何を買ったという情報は私には通知されませんのでご安心下さい😊 以下のリンクを経由して頂ければ紹介商品以外のご購入でもOKですよ～。
「空の彼方にあるものは？」
ファムのほうじゃないやつね。
いいなと思ったら応援しよう！
