ノリさんどうしたじゅんぺいインターフェースクラスとアブストラクトクラスって知ってますか当たり前じゃないですか当たり前ですかそれを知らずにプログラマーをやってるんですかさすがに知ってますか僕も知ってますなんだこいつなんだこいつでも聞き出し下手くそかしょっぴり知ってるだけなのでちょっと教えてほしいですいや僕からするともうちょっと補足が欲しいですえっとはい

Javaを書いてるんですけどあなたJavaを書いてるんですね僕Javaを書いてるんです勉強していく中でインターフェースクラスとアブストラクトクラスっていうのが出てきたんですけどなんていうかアブストラクトクラスいらなくねって思ったんですよインターフェースクラスで足りないのかなっていうちょっとJava書いてない人からするとめちゃめちゃ置いてけぼりなんでもう少し優しく話してほしいんですけどまず言語に実装されてる

機能ですクラスみたいな感じでインターフェースというのとアブストラクトというのがありますこれ多分Javaだけに限らずPHPとかはあるPHPでも同じようなのがあるんですね同じのはあるそれフレームワークじゃなくて言語なんですね

言語についてる機能でオブジェクト思考言語だとついてるんだけど確かにRubyとかだと見たことはないそうなんですよ優しい言語しか触ったことないRubyはあるのかもしれないですけどマジで使った覚えがないですそうね僕もRubyとPythonでインターフェース使ってるの見たことないですねじゃあないのかもしれないちょっとその辺は分かんないんですけどじゃあまず機能知ってると言ってましたねあなたじゃあ

教えてほしいわ聞かせていただきましょう普通にちょっとあのマジで知らん俺に教えてほしいですえーなんて言えばいいんでしょうねインターフェースはまずインターフェースからいきますとなんかこう大枠というかいいよまあ共通部分を共通部分大枠をとりあえず置いとくんですか具体的に言うと例えばなんかRPGのゲームみたいなのがあってそれに対してなんか

キャラクターってそのRPGっていろいろいるじゃないですか戦士だとか魔法使いだとか盗賊だとかみんな攻撃っていうアクションがあるじゃないですかロールがあるそうだね持ってるねいわゆるその攻撃みたいのをインターフェースって置いといてそのインターフェースクラスを例えば戦士が

実装した時に具体的な内容も付け加えるんですよ剣で攻撃するインターフェースだから攻撃っていう枠で置いといて実装したやつが具体的な中身を剣で攻撃する魔法使いだったらファイヤーみたいな杖で魔法を使う攻撃っていう感じで攻撃っていう大枠を置いといて人それぞれ違う中身にするっていう感じでうんうんはい

おいどけるんですよ便利分かる分かるなんかてっきり最初の話を聞いてるとなんていうんだろうな役職っていうデー系クラスがあってその中の細かい攻撃部分を定義するやつかと思いきやそうじゃなくてその概念の外側にいる

役職クラスの中に応用できる引っ張ってこれるものがインターフェースなるほどね具体的すぎたかもしれないそこまでいかんとわからなかった具体的なところね具体的なところでしたはい

それだったら何のためにあるとかが分かりやすかったなるほどね一応僕の方からも補足というか実際どういう機能を持っているのかを説明させていただきますねまずクラスと結構セットで使います絶対セットで使いますそうですよねまずそのクラスは普通だったらプロパティとかメソッドとかがあってそれぞれに具体的な実装をしていくじゃないですか逆にインターフェースって

そのメソッドとかは書けるんですけど中身書けないんですよ実装の開けといてねってことなんですねそうそうそうそうこういうメソッドがあって引数はこれを渡して返り値はこれを返ってきますよっていう情報までは書けるんですけど具体的に何の実装してるかは書けないでそのインターフェースをクラスになんかちょっと

PHPだとインプルメントって言ってそれを使ってこのクラス実装しますよみたいな指定ができるんですよそれをやるとインターフェースで指定したメソッド通りに実装してないと

エラー出るようになるんですよそのクラスがじゃああれですねなんか後から別の人が書き足した時にちゃんと元から作ってた仕様にのっとってるかみたいなのが明示的にわかるというかその通りすごその通りなんか大人数で開発しやすい仕組みですねなんかそれもあるそれもあるしあとこれ実は目的としてはですね変更しやすくするためにあるんですよ逆にはいまずどういうことかというとですねはいはい

そのインターフェースを実装してるとするじゃないですかはいはいはい1個のクラスがはいでそのクラスを別のクラスから使うときにまず絶対そのメソッドがあって引数と返り値の情報を絶対保証されてますよねはいなのでそこのインターフェースの部分さえ変わらなければ実装の内容がどんだけ変わったとしてもそのインターフェースを実装したクラスを使ってるクラスに影響を及ぼさなくなるんですよ

引数と返り値変わらないから理論上絶対大丈夫じゃんっていうのでオブジェクト思考の肝になる部分でカプセル化って呼ばれてるんですけど名前だけ聞いたことあるインターフェースを使ってまず抽象化した部分作っておきますとその抽象化したものに対して依存させるようにしますと使うクラスはっていう風にしておけばよく変わりやすい実装の部分がどんだけ変わっても

使用する側には影響を及ぼさないですよねっていうのが結構このインターフェースのまず使うメリットでございますちょっと確認していいですか僕はインターフェースとかは使ったことないんですけどAPIを作ったことあるのでそれで例えるとスワガヤムルっていうAPIの出力を出す設計するものがあるんですけどこれ入れたらAPIからこれ返ってくるよっていう設計書ねただのヤムルファイルなんですけど

それがインターフェースで中身の実装例えば出力を頑張って高速化する処理とか入れてもインターフェース変わんないからそのAPIでやり取りする側は何も気にしなくていいよみたいな考え方ってことですねジャストミートわかりやすいスワガヤムルねインターフェースはスワガですね設計書なんだ設計書に近いインターフェースっていう名前はなんか

言えてみようですねその通りそこが分かってくるとなんでインターフェースなのかが分かってくるなるほどそれに対してアブストラクトクラス最初に言ってたやつだこれはちょっとインターフェースに近いんですけど実装かけますアブストラクトクラスはかけちゃうんですねただ抽象化もできますっていうクラスとインターフェースのちょうど間ぐらいのやつなんですよはいはいはい

さっきじゅんぺいが言ってたようになくても困らないとは思うけどあるともっと便利なところがあって例えばそれぞれの1個のインターフェースがあってそのインターフェースさっきみたいに選手とか魔法使いみたいな感じで複数の実装があるとするじゃないですか複数の実装あるけど例えば全員逃げるだけは同じだよねみたいな

なるほどっていう時にアブストラクトクラスを使うとそっちに共通の実装だけかけるんでより省スペースでというか省エネで拡張できますよねっていうのがアブストラクトですね

なるほどもし逃げるっていうのがインターフェースで書かれてたとしたら戦士も魔法使いもそれぞれのクラス定義でいちいち逃げるのを実装しなきゃいけないしなくていいインターフェースだったらインターフェースだったらしなきゃいけないアブストラクトだったらしなくていいから共通化されてていいよねっていうそういうことそういうことなるほどねそう

インターフェースとかアブストラクトよくデザインパターン聞いたことありますか?聞いたことありますデザインパターンって結構オブジェクト思考のこういう問題は解決しやすいよみたいなパターンがあるんですけど

それでよく使われる感じですねなるほどインターフェースだったらストラテジーパターンっていってインターフェースだけ用意して中身の実装を変えるパターンとかそういう戦略でいくんやでっていうのをインターフェースで定義しとくんやでっていうそうそうそうそう例えばですけどローカルだと

開発環境の時はローカルのPCにファイル保存したいけど本番だとAWSのS3に保存したいよねみたいな時に例えば一個インターフェース作っておいてその詳細の実装をローカルに保存するかAWSに保存するかみたいなことを変えておいて実際にクラス作る時に分岐しておけば実装を気にせずに同じものを使い回せるよねっていうので使ったりとかしますねかっこいいななんか

かっこいいななくてもまあいいっちゃい使いこなせると便利だよねっていう部分なんですかねそうだねまあなんかあんまりこうちょっとねJavaの現場だと分かんないですけどPHPの現場だとあんまり使いこなせる現場はない印象でも今の話だったら共通処理に対して使えそうですけどあんま共通処理って現場だとないんですか

多分だけどPHP特殊だと思うPHPって結構バージョンを追うごとに超進化を遂げててインターフェースとかも多分そんなに古い機能じゃないんですよなのでただPHP自体昔から使われてきたんで多分長年運用してるレガシーなコードほどインターフェースない時代に作られてるんでそれを書き換えれない状態になっちゃってるんだと思う

だからJavaはどうだろうねもしかしたらちゃんと活用できてるのかもしれないそこはね僕Javaの現場入ったことないんで分かんないんですよね

入ったらお伝えしますお願いしますあとアブストラクトだとテンプレートメソッドパターンっていうのがよく使いますかね何ですかそれは処理の呼び出す順番は決まってるんですけど各詳細はちょっと微妙に違うよみたいな時にアブストラクトに呼び出し順だけ決めといて詳細の実装で中の細かいメソッド群は実装していくみたいな

パターンとかでやったりしますね順番を変える呼び出し順を変えると何かいいことあるんですか呼び出し順は変わんない例えばあの呼び出し順は変わんないけど呼び出す先のなんかパスが変わるとかそうそうそうそう細かいなんか例えばだけどじゃあファイルになんか書き込みたいってなった時に

ファイルのタイプによってやること違ったりするとするじゃないですかだけど実際にファイルがあるかどうか探して書き込んで保存するこの3つのステップは同じだよねってなった時とかに使えますねなるほど大枠のステップ同じだけど詳細ちょっと違うみたいな具体的な質問していいですか?はいいやちょっとわかんないこれもう完全に打速なんですけどスクラムで開発することあります?

あんまないんですけどもし僕が思った疑問はアブストラクトクラスを使って何かのさっき言ったテンプレートパターンでしたっけテンプレートメソッドを作るって結構大事な仕事だと思うんですけどユーザーストーリーに落とし込めないなと思って

スクラムだとユーザーが何々できるようになるっていう単位でタスクを切るのでアブストラクトのテンプレート作った時にそういうストーリーに落とし込めないなと思ってどういう単位で開発するのかなとかってちょっと思ったんですけど余計なことかもしれないそれでいうとスクラムは確かにそもそもユーザーストーリーってどっちかっていうとさ

要件とか基本設計らへんのあれになるじゃん内容がそうですねだけど多分今回のこのクラス設計って詳細設計の部分に入ると思うんでストーリーの時は気にしなくていいような気がする最初にそれを作る人がアブストラクトを使ってテンプレートを作ることによって他の人が実装しやすいようにやっといて一個具体的に動くものを作るっていうでアブストラクト作ったりとかね

他の人楽にできると思いますっていうエロいことをするんですねそれはエロいさすがにエロいなるほどエロいことしたいですね

それできたらちょっとセクシーだよねこの人アブストラクト作れるんだみたいなセクシーしかも他の人が実装楽にしてる好きみたいな恋生まれるねエンジニアはだいたい男性多いですけどね

僕は結構分かった気になりました今あ、いいねこれで多分今から読もうとしてるアーキテクチャの本もバッチリですよ絶対出てくると思うアーキテクチャの本出てくるかな出てくるかな出てくると思う僕も分かりましたなんか

補足というか打足的な感じでなんかアブストラクトの関係今回アブストラクトじゃなくてインターフェースを実装したインターフェースみたいなパターンとかもあるじゃないですかインターフェースを実装したインターフェースなんかもうそんなことある?まあでも現場で見てるわけじゃないんで勉強しててそういうのが出てくるタイミングとかがあったんですよ

なるほどねそういうのとかもいいことあるのかなって分かんないなどうだろうな直列でやってるのはほんまに見たことないやん1個のクラスに対して複数のインターフェースを実装してるケースはよく見るけどインターフェースがインターフェースをさらに実装してるのか見たことないし機能的にできるのかなっていうできると思いますそれはできますはい

問題で見たのかな?シルバーとかの資格の問題で見た気がしますねあんまり現実的じゃないですかねどうだろうな、なんか分かりにくくなりそうじゃない?それはあるよね、資格取ったことあります?のりさん言語の言語のないその言語の資格って現場で重視されない知識ももちろん必要とされていてこういうこともできるっていうのまで取られる取られるんだね

黒魔術を覚えさせる あそうそうそう本当にあのルビーで言うと黒魔術って言われるあのこの書き回しでこの動き方すんのっていうのってめちゃめちゃあるんだよねルビーだとでその黒魔術まで問われるのが四角だからまあそのパターンかもしれないねこういう書き方もできてこうするとすごく短く書けるんだけど現場で言うと他の人がわかんないからこういう書き方すんなっていうのはめっちゃあるんだよねあるね

なるほどそれかもしれんそれかもしれん出会ったら教えてくれ出会ったらまたお伝えしますもしかしたら上級エンジニアにしかわからない何かがあるのかもしれないでもそんなんダメだよね大抵の現場ではダメ世の中上級だけじゃないからもちろん上級しかいないところもありますけどねわかりましたエンディングトークいいですかちょい話です1エピソードにもならないちょいエピソードなんですけど

ちょっと前のエピソードで中級エンジニアって何ができたら中級エンジニアなの?みたいな話したじゃないですか順平に聞いてもらったと思うんだけどGoogleのソフトウェアエンジニアリングっていう本を読んでて何冊読んでんの?

今並行して2個を読んでるんですけど会社の臨読会用のソフトウェアアーキテクチャの基礎と読み手っていうGoogleのソフトウェアエンジニアリングGoogleのソフトウェアエンジニアリングはどっちかっていうと読み物だから暇な時に思うぐらいの気持ちなんですけどそこに書いてたフレーズであれこれじゃね?って思ったのがありましてえっと

第1章ソフトウェアエンジニアリングとは何かっていう章があってその中にプログラミングとソフトウェアエンジニアリングの違いっていうのが書かれてる説があったんですけど中級エンジニアイコールソフトウェアエンジニアじゃない初級エンジニアイコールプログラマーじゃないって思ったんですよ役職としてのPGSEってやつですかはい何が違うか

書かれたかというとプログラマーはプログラムを書くことを生業としているとそのプログラムが一体今後何時間動き続けるのかというのを意識しないでプログラミングしている人がプログラマーで今後自分が作り出すものがどれだけ長く運用されるかそしてどうやって機能が広がっていくかというのを込みでソフトウェアの設計開発をしているのがソフトウェアエンジニアだと

みたいなことが書いている方のがありましてなんかのりさんと話した内容を人なんか 人ぐらいずっとこんなことかなーっていう確かにうん確かに確かに設計までやらないとねそうそうそうでてこないから出てこないって しかもこれはの僕が1年目の時に思ってたことと今思っていることのキャップってこれだなぁと思ってここまで込みでいろいろできるようになる ですここまで込めていろいろできるなりには

いろんなことを知っておく必要があるんですってやっぱりはい確かにいろんなことっていうのは言語1個だけじゃなかったりとかというデザインパターンがあるとかいろんな選択肢がある中で一番時間的にも長生きして拡張性のあるものを選択していかなければいけない多分これはのりさんが言ってた多分理想を追い求めて心を折れるのは

なんか、心のヘッドソフトを色々知ったあたりかなと思って。確かにね。色々知れるからこそ、心が折れるんですよ。なるほどね。そう。あ、人には人の道があると。はい。っていうので、ちょっとね、この本読んでてね、これはあの、中級エンジニアへの扉がちょっと詰まってるなというか。おー。うん。

っていう本なので、もし本当に書き出ししたてで読むとちょっとさすがに早すぎる気もするのでちょっと現場に慣れたあたりでこの本に触れると、ちょっと視野が広がっていいのかなっていう気が一生読んでってしましたなるほどね、僕も実はその本audibleで英語版聞いてるんですけど英語版で聞いてるせいで1ミリも入っていない本末転倒であるんだ

これ聞けるようになったら勝ちかなって無理やり聞いてるんですけどめっちゃわかる俺も今年の目標要所一冊ですもんそこじゃあ一緒に頑張っていきましょうオーディングはちょっとハードル高いびっくりしたまじでさすがに無理以上エンディングトークでしたじゃあまた次回というわけでセクシーな大人目指してエロくなりますエロプッシュできるようにエロプ?エロプって言ったらただのエロいプレイですね

エロコミットエロプッシュできるようにエロコミって言ったらエロい漫画だけど頑張りましょうそれではまた次回バイバイ