00:05
はい、みなさんこんにちは。KEITHことくわはらです。 本日もやっていきましょう。KEITHのエンジニア雑談チャンネルです。この番組では、ウェブ業界に関することや、
エンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。 で、今日はですけども、
ChatGPTに教わるプロジェクト指向プログラミング、OOPの概念というところですね。 概念、オブジェクト指向の概念って言った方がいいかもしれないですけど、
昨日、リスコフの知観原則というワードを知ったんですね。 だから名前を知って、今までやってきたことある、まあオブジェクト指向のプログラミング
曲がりなりにもやってきたんですけど、基礎と言いますか、根底にあるリスコフの知観原則みたいなものがあるというのを知りまして、
そもそもオブジェクト指向とはみたいなところを久しぶりになんか知りたくなったんですけど、 まあそれ普通にググってもいいですし、まあいろんな著名な方々が書かれた本を読むとか、
まあそっちの方も正しいんでしょうねってのはあるんですけど、まあそれはそれとしてやるんですが、 まあやっぱり現代流行っているAIがどこまで知っているとかAIがまとめた説明だと
どんな感じなのかっていうのが興味あって、 いつも通りチャットGPTのGPT4に投げてみました。
今日の壁打ちはこんな感じでしたんですね。 で、それを投げた結果と、どういうものを教えてくれるのかっていうのを今からお話をダラダラしていこうかなと思っている感じです。
まずじゃあリスコフの知観原則っていうもののそもそもの概念を見ていきたいと思います。
スタートですけどもリスコフの知観原則とは、まずはウィキペディアからちょっと情報を持ってこようかなと思ってますけど、
オブジェクト指向プログラミングにおいてサブタイプのオブジェクトはスーパータイプのオブジェクトの使用に従わなければならないという原則になります。
リスコフの知観原則を満たすサブタイプをBehavioral Subtypeと呼んだりもします。
はいまあそういう名前があるらしいですね。 で、これに対してChatGPTに聞いてみました。リスコフの知観原則とは?みたいな感じで聞いたんですけど、
リスコフの知観原則とはオブジェクト指向プログラミングにおける重要な概念の一つでソリッドの原則のLにあたります。
ソリッド原則っていう別のものもあるんですけど。 この原則はバーバラリスコフによって1994年に導入されました。
この趣旨は以下の通りです。サブタイプ、派生クラスのオブジェクトはそのスーパータイプ、規定クラスのオブジェクトと知観が可能でなければならない。
これはプログラムの正しさを損なうことなく、サブタイプのオブジェクトでスーパータイプのオブジェクトを置き換えることができるというものを意味します。
はいはいまあ言い方はさておき、まあだいたい似たようなことを言ってますね。 この原則に従うことで派生クラス、サブクラスと規定クラス、スーパークラスですね。
と同じ方法で使用することができるようになります。 これによってプログラムの柔軟性と拡張性が向上しますよと。例えばシステムに新しいタイプのオブジェクトを追加する場合ですね。
既存のコードを変更することなく統合できるようになります。 リスコフの知観原則を守ることで以下のような利点もありますよというので3点利点を挙げられていて。
03:04
一つは再利用性の向上。まあ派生クラスというのは規定クラス同じインターフェースを持つため高度な再利用性が可能になります。
これがまず一つある意味で求めるものですよね。再利用性と。 二つ目に保守性の向上です。新しいサブクラスを追加する際に既存のコードを大きく変更する必要がなくなって保守も
良いになります。 ラスト3つ目は拡張性の向上ですね。
既存のクラスの階層に新しいクラスを追加しやすくなってシステムの拡張でも良いになります。 ただしリスコフの知観原則を適切に適用するためには
スーパークラスとサブクラスが適切に設計されている必要ももちろんあって、これは特に大規模で複雑なシステムに重要な考慮仕事も
なります。それはそうだよねって感じです。 オブジェクト思考プログラミングの難しさとか極意とかいろんな手法設計理論
ホゲホゲみたいのは生まれているんですけど、 現代でもずっと語られ続けてきたりはしてますので大変というか難しいし、本来の
オブジェクト思考とは現実をいかにプログラムに落とし込むかっていうところですね。
確か立脚してたはずなので、 現実はそんなひとつのプログラムでバーって書けるかっていう
ケースバイケースではありますよね。 だから設計論というのがいろいろ生まれましたし難しいんだよねっていうのはあります。
ただ一方で、やはり我々プログラマーとしてはそれは面白い話でもあるんですよね。 なんだかんだ行動を書くことよりも設計することの方が多分楽しいと
個人的には思ったりはしますけど。 まあリスコフの知観原則の話を読んでたんですけど、その中で昨日ですね
ペーシャンに所属していただいているパートナーのエンジニアの方の一人に教えて いただいたんですけど、リスコフの知観原則を学ぶのであればセットで
DBCですね。 契約プログラミングの話です。デザイン by コントラクトと言ったり、コントラクトプログラミングと言ったり
まあいろんな言い方しますけど、契約プログラミングと日本語で訳されます。 こちらもセットで学ぶのがいいですよと言われまして
契約プログラミングは私も名前だけは全然知ったんですけど、ちゃんと調べたり学んだこと なかったなっていうので、これもついでにGPTに聞いてみました
こちらはですねオブジェクト思考プログラミングの一種法でありまして、ソフトウェアの正確さと 堅牢性というのを向上させるために用いられます
このアプローチはソフトウェアの各部分間の明確な契約、コントラクトに基づいて構築をされます 主な要素というのは以下の通りですので3つありますね
一つは前提条件です。プリコンディションズですね メソッドや関数が正しく動作するために呼び出し元が満たすべき条件ですと
で例えばあるメソッドが引数として整の数を要求する場合はその整の数を提供するのは 呼び出し元の責任ですよね
続いて2つ目事後条件ですね。こっちはポストコンディションズです メソッドや関数が処理を完了した後に保証する状態のことを言います
メソッドが特定の値を計算して返すことを約束する場合はその計算結果が事後条件となります
ラスト3つ目普遍条件ですね。インバリアンスです。クラスのオブジェクトが満たすべき条件ですね これは常に満たすべき条件と書かれています
06:01
こちらはオブジェクトのライフサイクル全体を通じて保持されるべき属性や状態に関するルールになります
例えば金鉱鉱座の残高が負にならないみたいなルールですね まあこれはそうだよね
まあシステムジョフになっても別にいいんじゃないって話はありますけど現実界としてお金は自然数ですからね
まあゼロ含みますけど。デザインバイコンタクト契約プログラミングのアプローチってのがありますけどこちらを使用することでソフトやコンポーネント間の相互採用というのが明確になり
バグの発見と修正が容易になります。これは高度の信頼性とメンテナンス性を大幅に向上させることになります
はいということですね。またその契約に基づく明確な使用をすることで先ほどの堅牢なコートだったりとか
正確さっていうのがより担保されるようになりますという感じですね まあ確かにこれ読んだらさっきのリスクの知観原則本当に否定的な原則だと思いますけどこれと契約
プログラミングというのはすごくいい話だと思いましたね しっかりこれに従えば良いというのでまあ多分皆さんは自然にやられているものだとも言います
けども これを改めて言語化して新たに学ぶ人たちはこういうことがあるよっていうのを知っておくと全然良いのかな
いう感じですね契約プログラミングなかなか名前が僕はセンスあって好きですね でまぁオブジェクト思考プログラミングの話に戻りますけどももうちょっとじゃあ
オブジェクト思考プログラミングのメリットみたいなところを具体的な例を出しつつ教えて 聞いてみたんですね
出てきたんですけどちょっと教科書的な固いものが出てきてしまったのでもう少し具体的な かつもうちょっと年齢をですね
学生さんが読んでわかるような人に教えるつもりの例をくださいって聞いてみたんです けどしたらですね
なんだかんだやっぱりゲームの例が出てきたんでまぁまぁせっかく出てきたんですよもうちょっと 読んでいきたいと思いますけど
まずはクラストオブジェクトっていう概念がありまして例えばこうビデオゲームはテレビ ゲームのいいんですけど
キャラクターがいますよねでそのキャラクターというクラスを作るというふうに考えましょう 暮らせて概念がもちろんあるんですけど
でそのクラスというものを一旦考えますでそのクラスには名前と体力と例えば攻撃力 などの属性プロパティといったりしますけどまぁそういう属性が付与されたクラス
という概念を1回考えます で攻撃するならば攻撃するときのその動作
これはメソッドですねまあ動作というか振る舞いといったらわかりやすいかもしれないです けどというものも含まれたりします
要は属性とその人が何をする振る舞いっていうのを定義するでそれをプロパティと メソッドといったりします
こういうものを含めたものをクラスというふうに定義しまあそういう概念があるよって ことですね
でまぁ実際のゲームで登場する各キャラクターっていうのはそのキャラクタークラスっていう もののオブジェクトですね
クラスっていうのはよく言われる設計図と言われたりしますね 実際に作られたインスタンスと言いますけどオブジェクトのことを実体と言ったりするん
でもそういう設計図と実体みたいな言い方をしたりすることもありますね で設計図的なキャラクターというクラスを作っておいてそれぞれのゲームキャラクターですね
戦士もいれば魔法使いもいればビーストもいればみたいな感じでキャラクターごとに それぞれの属性とか振る舞いというのは変わってきますけど
根幹となるような設計とか構造というのは一緒ですよねそれは先ほど言いました クラスってものと同じような形にするという感じです
09:01
まあこういうクラスオブジェクトというのがあってこれのメリットは同じ基本設計を使って 異なるキャラクターも簡単に作成できますよね
まあ先ほど言いました勇者とか魔法使いとか異なるタイプのキャラクターというのを追加する のが簡単になりますよね
はい毎回毎回例えば勇者だったら武器これとか攻撃する振る舞いはコーダーとか属性として これがありますっていうのをやっていきますで
魔法使いだと同じようにこうだこうだーだってあるんですけど魔法使いの場合は他の キャラクターと違ってこういう能力があったりしますよねっていうのを個別個別に書いて
いったりしてもいいんですけど それをじゃあキャラクターごとに毎回やるのかとでどんどん物語とか進んでったらキャラクター
どんどん増えていきますけどそのたんびにまた新しく こういうキャラクターのためにこういう属性を追加しなきゃって一個一個考えるのはすごく
だるいですし なんか使用変更があったらそれ全部また手作業でやらなきゃいけないっていうのでやっぱり構造化
しておくのすごくいい話ですよねって感じです 続いて今のクラストオブジェクトで続いては継承という概念があります
継承ですねキャラクタークラスというものから例えば勇者とか魔法使いのサブクラスというのを作成できますと これらはキャラクターの共通の特性を受け継いでいて
特別な能力や装備を持つこともできますさっき言った話ですね 名前つけると継承というものがありますという感じです
これによってキャラクターの設計を再利用することになりますが独自の特徴を持つ新しい キャラクターというのを簡単に作るようになりますとこれによって開発時間が節約され
コードも整理されます よくあるドラクエだったりなんだったりっていうRPGやる中で戦う時のコマンドがあったりするじゃないですか
全キャラクター必ず例えば戦うアイテム逃げるとか防御とか あと魔法みたいですかっていうようなコマンドってのは決まってくるじゃないですか
あれのことをクラスで定義したりをするってことですね そうすることによってどんなキャラクター増えようがそのキャラクターが例えば職業を変えたりとかそれは
全部属性を変えればいいだけの話ですよね 1個1個それを作っておけば他のキャラクターから何をしたとしても切り替えが簡単になりますし
簡単に管理できるようになりますよねっていうので形状というものがありますと で3つ目ですね3つ目はカプセル化という概念ですね
キャラクターの体力とか攻撃力などデータですねっていうのはゲームのルールに従ってのみ 変更できるようにします
例えば体力という特定のメソッドダメージを受けるとかですね を通じてのみを減らしたりすることができるということです
これによって不正な方法でキャラクターの状態を変更することができないため ゲームのバランスとか整合性を保つことができるようということですね
これも結構大きくてカプセル化しないといつどのプログラムがどこで値を変えたとか状態が どういうふうに変わったとかっていうのを追いづらくなりますし管理ができないのでバグだったりとか
簡単にハッキングして違う属性とか値に書き換えることもできてしまったりする それはよろしくないっていうのでちゃんと1個1個オブジェクトはカプセル化といってあの情報
隠蔽しちゃうんですよね他から見えないようにしたりとかブロックをしたりするようにする ということでじゃあちゃんと状態というのを保すことで正式な手続きとか
僕らが想定していた動きの中振る舞いの中で値が変わってそれを管理されるっていうことが できるようになるのでカプセル化ってのすごく大事だよなって話です
12:03
ラスト4つ目ですけどこれは多体性と言われるものですね まあ先ほど何度出ましたこう異なるタイプのキャラクターっていうのが勇者とか魔法使いとかがいます
けど攻撃メソッドっていうのを共有することもできますとはい ただの攻撃メソッドとしてもキャラクターごとによってやり方ってのは変わってきますよねと
というのでまぁそういうキャラクターごとに変わったもの個別なものっていうのを設定できる ことでデザインというのをより柔軟にすることができますよね
はいまあ今みたいな感じでオブジェクト思考プログラミングってもう少し具体に落とし込んで いくと
より設計をすることで視覚的かつ具体的な映像通じて理解することができますし管理の仕方 拡張のしやすさみたいな行動を整理することもできるようになりますというところですね
はいまあこれがオブジェクト思考プログラミングのお話でした はいまぁちょっと難しいし結局この辺は口頭で説明してもわかりづらいのでやっぱソースコードを見
ながらとか自分で行動書きながらやったほうが絶対わかりやすいんですけど まあ少なくともオブジェクト思考プログラミングっていうものを概念を知るだけでよりいわゆる良い
コードと言われるものが書けるようになったりするので まあ改めて言語化しながら僕は何度も書いたことがあるのでこれ見ながら
そうそうそうだよねっていうのを改めてこう頭の整理になりました まあ新しく学ぶ方々はこの辺とか知りつつ実際にやっぱコードを書いてみるのが
わかりやすいんじゃないかなと思いますし 自分の現実世界を1回プログラムに落とし込んでいってみたらいいんじゃないかと思います
まさしくオブジェクト思考プログラミングのスタートと一緒のことを僕らもやると いう感じです
今はゲームだったりしましたけど別に家族でもいいですしペットとか動物界をオブジェクト に落とし込んでみるというのも一つですね
なんかアニマルみたいなスーパークラスを作っておいてドッグクラスとかキャットクラス あとバードクラスとかですね
バードの中でもいろんな種類いますよねインコがあったりとかオウムがいたりとか 鶏だったりとかってまあそういうのはもう本当に具体なのでそれは属性の方で判断をして
一つバードクラスっていうのをサブクラスとして作っておいて まあ例えば動物だったら名前つける人もいますねまあ学名としての名前はありますので
名前っていうプロパティがあったり振る舞いとしては泣くとか餌を食べるとか 逃げるとかいろんな振る舞いありますけどまあそういうメソッドを定義して書いてみても一つかもしれないですね
はいというところでまぁ今日はそんなオブジェクト思考プログラミングっていうものの話を AI を見聞きながらこう学んでいきましたというところですね
あーそうですね言い忘れましたけどオブジェクト思考で書かないデメリットの話もちょっと あってですね
デメリットはさっき言った通りでメリットの逆です プログラムの設計とか管理状態の管理もそうでし拡張の面でもそれが逆転します
難しくなるってそんな感じですね 一つはコードの再利用性がやっぱり難しいですねというのが一つとコードの管理が複雑化
しますよねというところですね はいまぁデータの変更とかをどこで処理でやってますかっていうのがどんどん分散して
しまって大規模になればなるほどこの追跡と管理がすごく困難になりますよみたいな ところです
あとは再利用性難しい話でいくと同じようなことを車輪の再発明をいろんなところで各種 行われていて結局
15:04
誰がどのメソッドを使っているかわからなくなったりすると バグの温床になりますねみたいなのもありますし
あとは拡張性と柔軟性の低下というのがありますよね今言った話とそのまんまです けど書き換えることがすごく大変で拡張したいんですけど
この処理はどこで無沙汰でやってるっていうのは全部プログラム1回を終わなきゃいけ なくてですね
オブジェクト志向でしかで書いていればこのメソッドを書き換えれば全然問題ないじゃん っていうのができるんですけどそれを各種バラバラにそれぞれのオブジェクト単位で書いてたり
するとどこを変更したらプログラム全体としては成功せた持ってたというのがわかりづらく なるんですよねっていうので拡張性柔軟性というのが下がっていくと
依存度が高かったりする時もあったりするのでね 次ではデータの安全性と整合性の話も
今言った通りですね誰がどこでどういう処理をすることで値を変えたとか 値の変え方みたいなのもバラバラになってしまうと
整合性保つの本当大変ですよね多分テストしきれないと思います ラスト5つ目としてスケーラビリティながやっぱり限定されますよねってところです
複雑さとかコードのスケールってところを考えた時に 新しく入ってきた人が既存のコードを参加したい
コード変更するのは難しくなったり今までいた人たちも誰がどこで何のコードを追加したか っていうのを例えばギットで管理したとしてもですよ
追い切れなくなるので より大変になるよねっていうのでしっかりやっぱり管理するためにもオブジェクト志向をプログラミングで
書いておこうが良いよねっていうのがあったりします 個人で書いたら別にいいじゃんって話はありますけど個人プロダクトだとしても僕は
出れた方がいいと思ってて 過去の自分はやっぱり他人なんですよね あいつ何のコードを書いたっていうことに結局なるんですよ
なのでやっぱりOOPで書くのは一つかなと思ったりはしました というところで今日はメリットとかなんぞやみたいな話を話しましたけど
1回は書いてみるのが本当にわかりやすいと思います はい今回はこんなところで終わっていきたいと思います
いつも聞いてくださり本当にありがとうございます ではまた次回の収録でお会いしましょう
バイバイ
