FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

HogeManagerに関して調べてみた

プログラム書いててイケてない命名みたいなのあるじゃないですか 色々あると思うのですが今回はその中の一つにManagerについてのお話をしようかと思います。

基本的にManagerとかUtilとかの名前使ったら負けを連呼している私なのですが、ある日 「あ、これimaizumiさんが嫌いなやつだ」と隣の席から声をかけられ、なんだろな?と聞いてみると。 なんとうんちゃらManagerクラスがあったそうです。海外で動いてるプロダクトのコードで。

うんちゃらManagerさんは国際的なやつだったのか!とこの時びっくりしたのですが(和製英語じゃないけど日本でよく使われるパターンなのかと勝手に思ってました)それと同時に なんでこんなにManagerという言葉が使われるのだろうか?という疑問が浮かび色々調べてみたというのが今回の記事になります。

軽くググるとダメな命名パターンとしてよく出ててきて、嗚呼そういえば昔、viewにバインドするための情報を持ってくる処理を置いてある各画面のhogeMangerとか、DbManagerとかいう名前で全てのSQLの処理が書かれたすっげえのとかあったなぁ...とか色々と昔を思いだしながら見ててました。(多分上記のDbManagerのせいで私はManagerという言葉が嫌いになったんだと思います)

そして調べていくとどうやら「プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集」という本にManagerというパターンがあり こいつが大本になって色々になったのかなぁとかいう考えに至りました。

上記の本にあるManagerのお仕事はざっくり言うと、HogeManagerのHogeに該当するクラスのインスタンスに関する一括管理(生成、破棄、検索等)。ということでした。 HogeクラスではHogeが注力したい処理を行い、インスタンスの管理というHogeの本質ではない部分をHogeManagerが担当するという役割分担ができる。 というのがこの本におけるManagerのお仕事でした。インスタンスのキャッシング機構みたいな感じですかね。

このパターンにおけるManagerに、えいやーっとHogeクラスが行うべきである処理を入れれば私の嫌いなManagerクラスに早変わりできるので、そういう不幸な事件がいろんな所で起きて、それどころか本来の仕事であるインスタンスの管理の処理がなくなり、Hogeクラスに関する様々な処理が置かれる場所。みたいなよくわからないことになったのかなぁと妄想しております。というか本にも誤用するとカプセル化が損なわれるってありますね。

今後はダメなManagerを見かけた際にはManagerとかやめろ!と言うだけではなく、こんなにボロボロになっちまって...可哀想に...みたいな目で見てあげる必要があるのかもしれないと思うようになりました。