最初にいっておくが、中身のないペラッペラなラッパーが嫌いという意味ではない。むしろ好きだ。音楽のラップに濃さを求めていない。
プログラミングの話である。
プログラミングにおけるラッパーとは、関数をラップして（包んで）使いやすくした関数を指す。サランラップの「ラップ」と同じ語源だ。
例えばSwiftUIでは、角丸の長方形に対して枠線を引くのに一手間かかる。
角丸の半径が16の長方形は `RoundedRectangle(cornerRadius: 16)` で表現できる。
しかし枠線を引くと一気に冗長となる。
RoundedRectangle(cornerRadius: 16).overlay { RoundedRectangle(cornerRadius: 16).stroke(.blue, lineWidth: 1) }}
毎回書くのは手間だ。
そこで `RoundedRectangle(cornerRadius: 16).stroke(.blue, lineWidth: 1, cornerRadius: 16)` と書けるラッパーを用意したとしよう。
短くなるので、読みやすくなったように思える。実際このラッパーを実装した人にとっては読みやすい。
他の人にとってはどうだ？
実は読みづらい。なぜなら `stroke(.blue, lineWidth: 1, cornerRadius: 16)` という関数を見たことがないからだ。オレオレラッパーなのでググってもヒットしない。なまじ標準APIに似ているので余計に混乱を生む。定義へ飛ぶことでやっと理解できるが、標準APIのみで構成されていたら定義へ飛ぶ必要もない。
それ以上に困るのが、統一の崩壊から来る保守のしづらさだ。
他の人、特に新しくプロジェクトに参加した人は、薄いラッパーがあることに気づくのが難しい。技術力のある人ほど標準APIに慣れているため、角丸の長方形に枠線を引くときは `overlay { RoundedRectangle(cornerRadius: 16).stroke(.blue, lineWidth: 1) }}` と書くだろう。
するとプロジェクト内に、薄いラッパーを使っているパターンと、使っていないパターンが生まれてしまう。一度統一が崩れると立て直すのは困難で、どちらを使うのが正しいか誰にもわからなくなる。
だから私は、標準APIを短く書けるようにしただけの「薄いラッパー」が嫌いだ。ラッパーを用意するなら「濃いラッパー」にしよう。
濃いラッパー、つまりデメリットを上回るほどのメリットを持つラッパーについて、ここでは言及しない。
メリットを書くとラッパーを作りたくなるだろ？ それはこのポエムの意図ではない。他の記事で確認してくれ。
ところで、巷では「Bling‐Bang‐Bang‐Born」というラップがめちゃくちゃ流行っている。YouTubeは脅威の5,000万再生を突破している。
え？ Creepy Nutsはどっちだって？
お前らが作っているどんなうっすいラッパーよりも濃いに決まってるだろ。