■ソフトウェア設計とメンテナンス

「分岐を低減するinterface設計と発想の転換」ミノ駆動

engineer-culturefes-2023-minodriven-new-img

2023.05.12 2024.03.05 約2分

この記事は 2023年03月03日開催『エンジニア文化祭2023』出演ミノ駆動氏による登壇をレポートしたものです。

分岐が複雑化して困っていませんか？interface を上手に使うには大幅な発想の転換が必要です。本講演では、架空の防犯システム設計を事例に考えてみます。

Topics
要点1：目的単位で抽象化すること
目的達成手段とinterfaceの関係
防犯システムの設計に応用すると
要点2：作る・使うを、分ける
トピック：目的のバリエーションと機能性
【Q&A】interface不要論
【Q&A】interfaceの変更が難しい
【Q&A】技術力を高めるために最初に実践すべきこと
【Q&A】interface分離原則
【Q&A】abstractについて
【Q&A】interfaceによる抽象化のベストタイミング
【Q&A】拡張可能性の担保

設計なんもわからん#Forkwell文化祭 #Forkwell文化祭_A pic.twitter.com/jFE5NYUKT5

— 御成門プログラマー(Tomotaka Suzuki) (@onarimonprogram) March 3, 2023

ミノ駆動さんが話しているインターフェイスは言語機能ではなくて設計におけるインターフェイスだと思うのでRubyとかの人も参考になると思う#Forkwell文化祭_A

— 鈴木まー (@suzuki_mar) March 3, 2023

具体と抽象の訓練、この本とかよさそう。https://t.co/nSSEAk4x51 #Forkwell文化祭_A

— nabe-yu (@nabe_yu_jp) March 3, 2023

「作る」と「使う」を分離する#Forkwell文化祭 #Forkwell文化祭_A pic.twitter.com/S1U0wk0C1G

— 御成門プログラマー(Tomotaka Suzuki) (@onarimonprogram) March 3, 2023

#Forkwell文化祭_A 作ると使うの混在は「自動車を作りながら走らせるようなもの」
的確な例えだ

— もりこう (@moriko0524) March 3, 2023

大まかな例としては簡単に見えるんだが、実際にはinterfaceとして抽象化できるのは共通の振舞いのみで、実装に必要なデータはクラスごとに微妙に異なったりする。その時にデータをどこに持ってどう渡すのかというのはそれはそれで考えなければいけないと思う。ここをサボると駄目。 #Forkwell文化祭_A

— joker1007 (アルフォートおじさん) (@joker1007) March 3, 2023

「使う」側は振舞いの規約だけを知っていれば良いが、「作る」ためには個別の存在を知っている必要がある。なので知っていなければいけない範囲を限定してコントロールしやすくするために分離した方がいい。古典的にはFactoryパターン、現代的にはDIとかCoCかな。 #Forkwell文化祭_A

— joker1007 (アルフォートおじさん) (@joker1007) March 3, 2023

作ると使うの違い
作る側はFactoryパターンやDIコンテナ等により作る側に全て持たせること
使う側はどのinterfaceが実装されているかに影響されずに目的を達成するために完成品をただ実行するだけのシンプルな構造とすること#Forkwell文化祭_A

— UT@自治体エンジニア (@hidemusiam) March 3, 2023

インターフェイスはオープン・クローズを実現するために使うといいと思う

オープン・クローズが必要なのに直接実装するとメンテナンスがかなりしづらいのと想定外の依存関係が生まれそう#Forkwell文化祭_A

— 鈴木まー (@suzuki_mar) March 3, 2023

Interface切るとこういう目的で使えていいぜという話で「Interfaceはいらないです」は攻めすぎでワロタ#Forkwell文化祭_A

— けっと (@myonyomu) March 3, 2023

コードを追わなくてもいいような設計にするのがいい。
このような設計にしたいですね。#Forkwell文化祭_A

— 山翡翠やませみ (@yamasemi1618) March 3, 2023

インターフェースの話、基本的にはAPIやメソッドの呼出し仕様を公開するという話だと思うし、インターフェースという言語上の仕組みがなくてもドキュメントでできる話だし、これの要否はTwo Pizzaチームの話につながってくる気がする。#Forkwell文化祭 #Forkwell文化祭_A

— Makio Tsukamoto (@tsukamoto) March 3, 2023

ああ、インターフェースを変えることによって、具象クラスが壊れるくらいなら、新しいインターフェースを用意して、古いインターフェースをDeprecatedにすべき、か。
外部公開API的な考え方をしたほうがいいと。#Forkwell文化祭_A

— なつめ (@yukiko_bass) March 3, 2023

インターフェースは心の中に！（笑）#Forkwell文化祭_A

— なたこん (@natacoon) March 3, 2023

設計力を高めるのに大切なのはビジネスの理解。
ドメインエキスパートから話を聞き、自分たちでかみ砕いていく。

整理が大切だけど、結果として落とし込める形を知った上で整理したほうがいいと思うので、その知識をどうすれば効率よく学べるのか気になる。#Forkwell文化祭 #Forkwell文化祭_A

— あおPG📛 (@aoaoaobaba) March 3, 2023

最初から完璧な設計は厳しい。実装を進めて怪しくなったら抽象化すると。#Forkwell文化祭_A

— nabe-yu (@nabe_yu_jp) March 3, 2023

抽象化できないものを共通化しないで！というFBをよくするけど、目的で整理しましょうとすると良さそう
interface設計可能な箇所は機能性向上の可能性を示唆している、という表現はとても納得感があった
ミノ駆動さんの話#Forkwell文化祭 #Forkwell文化祭_A

— げんげん (@gengenmusic0719) March 3, 2023

ミノ駆動さんの講演、とても良かった。

良いコード/悪いコードで学ぶ設計入門に書かれてる内容のう、interface での分岐削減について絞ったものだけど、その分具体的に深掘りしていてよく理解できていた。

#Forkwell文化祭_A

— あおき (@bluewd111) March 3, 2023