標高3000メートルから先は、異世界だった。そして僕らはそこにいた。

絶対、絶対にこれ以上、登りたくない。もう散々だ。
午後８時、雨嵐吹き荒れる山荘、標高3000m近くで僕はそう思った。

話は入山１日目に巻き戻る。

入山１日目。

僕は登山を完全に舐めていた。

ハイキングみたいなものだと完全に勘違いしていた。楽しく森林浴しながらお散歩。
お花畑の頭の中で僕がスキップしていた。

冷静に考えれば、
山専用のカッパを買ったりゴツい山靴を買ったりしている時点で、
疑問に思うべきだったと思う。

入山２日目。

入山前に買ったものが全部必要なものだとわかったのは、
最初ハイキングコースだった道が徐々に岩だらけになったり、
雨が降って来て予想以上に山が寒いと知ってからだった。

そこからは先は酷かった。

雨で視界が悪い。

今自分がどれくらいの高さにいるのかわからない。

わからないのに、
切り立つ崖のような壁(僕にはそう見える)を登らなくてはならない。
手を離したら確実に死ぬ鎖(僕にはそう見える)を掴んでさらに高度を上げなくてはならない。

眼鏡が雨で曇って何も見えず、
見えるものは目の前の岩、
信じられるのも目の前の岩しかなくて、
いつこの崖が終わるかもわからない、
いつここから落ちて死ぬかもわからない、
死ぬ死ぬ死ぬ、
そう思いながら必死に登ってようやく小屋の屋根が見えた。

僕はものすごく安堵した。
そこが穂高山荘だった。
助かった、とも思った。

全然助かってなどいなかった。

雨で視界が悪い中、山荘の向こうに薄っすらと見えたのは岩。岩。岩。
岩が積み重なって塊を作っていた。
それはただの絶壁だった。
3000m近くにある山荘よりも標高が上だった。
上の方はぼんやりしていて全然見えなかった。

そう。山荘のすぐ近くには「奥穂高岳」があった。
そして明日は、
あの絶壁を登って、
3190mの奥穂高の山頂に登らなければならなかった。

入山３日目。

本来なら今日、奥穂高山頂に登る予定だったが天候のため先延ばしになった。

その日１日、穂高山荘は嵐に巻き込まれたのだ。

風と雨。

標高が高くなると、風は気まぐれを通り越してやけくそのようにその風向きを変える。

風向きが変わると雨の向きも変わる。

雨が窓を打つ。
その一瞬後に屋根を打つ。
今度は反対側の窓を打ってすぐまた屋根を打つ。

山頂付近の自然の変化はしりとりじゃない。
一つ前の状態が全く違う状態に変わるのだ。

 
雲。

３メートル先は何も見えない。昼間なのに。
視界がほぼ白なので本当に昼間なのかも分からない。
これは霧？
これは霧なんかじゃない。
雲だ。
穂高山荘は雲に完全に包まれてしまっていた。
そしてその中で嵐が吹き荒れている。

まるで竜の巣が晴れる前のラピュタのようだった。

山荘の中から外を見る。
僕が覗いている窓から３m離れたところを雲が駆け抜けていく。
雲がすぐそばを駆け抜ける。

見たことない、恐ろしい光景だった。

僕が今知っている世界は山荘の中と外。
外はただただ乳白色と灰色の中間の色に満たされていて、
何一つ物が存在しないように見える。

この山荘は本当に地面に接しているのだろうか？
いつのまにか風に飛ばされて空を舞っているのではないだろうか？

それくらい、何も見えなかった。
ただただ怖かった。

明日は山頂まで登らなければならない。あの絶壁を登って。

僕は完全に死刑執行前の囚人だった。

なんでこんなに辛いのに、人は山に登るのか。
わからなくなって、その日は山荘にあった本「山の天気」を読んでいた。

その日の夜は眠れなかった。

絶対、絶対にこれ以上、登りたくない。もう散々だ。
午後８時、雨嵐吹き荒れる山荘、標高3000m近くで僕はそう思った。

「明日は登頂だ。３時には起きるぞ」
その言葉が僕には死刑宣告に聞こえた。

そして入山４日目。

今日、僕は死ぬかもしれない。

明日山頂にたどり着かず、僕だけ死ぬんだ。
3000メートル転がって、その途中で死ぬんだ。

そんな未来しか見えなかった。

終わり来る未来を想像し尽くし、ただひたすらに憂う。
眠れなかった。そのままついに３時が来た。

一緒に山を登っている友人を起こす。
彼はすぐ起きた。

起きてすぐ、彼は言った。

「星が」

目線は窓。僕はつられて窓を見た。

そこには星座が見えた。

違う。そこに星座が「居た」。

オリオン座。それがオリオン座であることが一瞬でわかった。
星は本当に何万光年も離れていたのだろうか。
ゼロ距離のような、圧倒的な存在感を放つその星座がそこに「居た」。
星々をつなぐ線が見えた、気がした。

夏の夜明け前だった。
上半身を起こしてすぐ覗けるくらい近い窓から、オリオン座は僕らを見ていた。
僕らが起きるずっと前から、オリオン座は僕らを見ていたのだ。

僕は思わず身を乗り出した。
そして呟いた。

「天の河？」

本当に、天の河だった。

天頂に、薄いミルクを夜空にこぼしたような跡。 
目を凝らすとそれがいくつもの星で構成されていることが分かった。
教科書でしか見たことがない天の河が本当に、本当にあった。
嘘のようだった。本当に嘘かもしれなかった。

でも。

「僕は今、初めて銀河を見ている」

そう思った。

 
昨日、一歩先も見えないような嵐があった。
そして今日、そのあと気味が悪いくらい晴れた。
今にも落ちて来そうな近くに星があって、銀河まで見えて。

もう、この世の終わりかもしれない。そう僕は思った。

僕らはそのまま、無言で支度した。

みな、何を天秤にかけているのだろう。

登頂と命だろうか。
僕は登頂したことがないから比べるものがない。
僕にとって登頂は質量ゼロだ。

だから「命じゃない側」に天秤が傾くことなんてありえない。
みんな頭がおかしい。

なぜ、人は山に登るのか。
まだ僕にはわからなかった。

――でも、登ったらその答えがもしかしたら分かるかもしれなかった。
星空を見て、そう思った。 

すべての支度が整い、外に出る。
僕は一番近くの岩に、軍手をつけた手をかけた。

そこから先のことはあまり覚えていない。

岩。
つかんで体を上げる。

ありえないくらいの高度に自分がいることがわかった。
でも下をみない。

岩。
つかんで体を上げる。

岩。
岩。
鎖。
はしご。

永遠とも続くような「登る」という作業。

岩。
手をかける。
体を上げる。

そして、

僕は

それを

見た。

金色に輝く雲海が目の前に広がっていた。
足元から雲が湧き上がって来ていた。
360度の大展望だった。
地平線がどこまでも広がり、円く見えた。
地球の一部をコンパスで切り取ったらこんな感じなのだろうと思った。

これらの言葉が

圧倒的に

圧倒的に

無意味だった。

ただただ目の前には世界があった。
そして、それを表現することができる言葉は、この世界になかった。

それほどの光景が目の前に広がっていた。知らずに口が開いていた。

雲海は比喩なんかじゃない。

本当に雲の海があって、山という島が点々とあって。
海だって風で波がおきる、だから雲海だって風で波がおきるのだ。
雲は波のように刻一刻と姿を変えていく、
それに呼応して山は見え隠れしその姿を変える。

信じられなかった。

こんな場所が、まだ世界にあったなんて。

なぜ山に登るのか。
命と何を天秤にかけたのか。

その瞬間、それらの答えがありえない質量となって腑に落ちた。

僕はこれを見に来たのか。
皆これを見に来ていたのか。

この感情を、一生忘れたくないと、僕は思った。

死神が予備校にいた。彼はりんごばかり食べていた。

予備校にいた、死神の話。

僕が通っていた予備校には死神がいた。

その死神は毎日りんごばかり食べていた。

みんな知ってると思うけど、死神はりんごしか食べないんだ。

死神は昼休みになると、予備校の地下にあるリフレッシュルームに降りてくる。

そしてハンカチから一つのりんごを取り出し、両手で大事そうにもって、まるかじりする。

「死神が、毎日昼休みにりんごをまるかじりしている」

僕はそれをいつも、不思議そうに見ていた。

なんでりんごなんだろう。

ずっと不思議だった。

でもりんごをまるかじりする彼は、死神のくせになんだか神々しく見えて、

少し離れたところからそっと見るくらいしかできなかった。

神々しく見えるのには理由があった。実は彼にはもう一つ名があったのだ。

ザビエル。

それは明らかに彼の髪型に由来していた。

彼は御年５０歳。

予備校には再受験組が割りといたので珍しいことではない。しかし、

「ザビエルという死神が、毎日昼休みにりんごをまるかじりしている」

こうなってくると一気に珍しくなってくる。

時がたってセンター試験前。

そんな彼は、みながそろそろセンター試験に向けてエンジンに火を入れ始める９月、

予備校からいなくなった。

ここで僕はようやくわかった。

そうか。本当は、彼は人間だったんだ。

知恵の実（りんご）を食べてしまったせいで、

楽園（予備校）を追い出されてしまったんだね。

いつも人間は、禁忌を犯して追放される。

僕もいつか、大学に合格するという禁忌を犯して予備校を追放されるのだろう。

そんなことを思って、僕は禁忌を犯すべくセンター試験の勉強に没頭した。

「ザビエルという死神が、毎日昼休みにりんごを食べていたが、センター試験を目前にして消えた」

これで話は終わったはずだった。

でも真相は全然違った。

後ほど僕は友人から聞いた。

死神は、りんごを食べたから楽園追放されたわけではなかった。

別の禁忌を犯したのだ。

死神は婚活をしていた。

後から聞いた話だ。死神は受験のために予備校にきていたのではなかった。

予備校で婚活をしていたらしい。

予備校で婚活。新しい。

彼はめぼしい女性がいると突然近づき、こう言った。

「友達からどうですか？」

どうですか？、と言われましても。

こんなことを繰り返しているうちに、いろんな生徒から被害届がだされ、

ついには楽園を追放されてしまったらしい。

うちの予備校は３つ目の楽園だった。

彼は他の予備校でも同じことを繰り返していた。

そのたびに楽園を追い出され、予備校を転々として、

うちの予備校にたどり着いたようだった。うちは３つ目の楽園だった。

結局、この楽園には見切りをつけ、次の楽園を目指したのだろう。

「ザビエルという死神が、

　毎日昼休みにりんごをまるかじりしていたけど実は婚活もしていて、

　ついには追い出されてしまったけど、次の楽園に移動しただけだった」

盛り沢山すぎやしないか。

きっと

今でも彼は、生涯の伴侶をもとめて次の楽園を目指している。

僕は、彼が幸せになってくれたらいいなと思っている。

予備校は牢獄だった〜浪人時代予備校にいた「７浪さん」の話〜

僕は大学に入るまで、３年かかった

３年。長かった。

受験勉強を始めたのが高３の夏。

それなりに勉強をしたのだが結局志望校には入れなかった。

結局僕が入ったのは予備校。そこで１年、そして２年といた。

よく「浪人時代は本当に苦しかった」と言っている人がいて、

「１浪でもつらい、２浪なんて頭がおかしくなる」なんて感想をくれたりするが、

僕は予備校生活が楽しかった。

そう。予備校には本当に色んな人がいた。アメリカもびっくりの人種のサラダボウルだ。

聞こえが良いが、悪くいうとただの魔窟だった。

七浪さん

僕が通っていた予備校には「リフレッシュルーム」と呼ばれているところがあり、

自販機があって、4人座れるでかい丸テーブルがいくつもあって、謎のカウンターがあった。

そこは予備校生が唯一くつろげるオアシス的場所だった。

毎日、大量の英単語・数式・いつ使うかわからない物理法則・その他諸々を詰め込みまくって、

脳が消化不良を起こしてゲロを吐いている、そんな生活を送っているのだ。

死刑囚だって最後はタバコを吸わせてもらえる、

だから予備校生だってリフレッシュしたっていいはずだ。

そんなリフレッシュルームの雰囲気を完全に破壊していたのが

「七浪さん」だった。

七浪さんとその取り巻き

坊主。目にはサングラス。壁を蹴ったら突き刺さりそうなほど先が尖っている靴。

手首には高そうな時計。そして意外に低い身長。

彼はいつも肩を怒らせて歩いているので謎にデカく見えた。

彼の朝は遅い。少し日が傾き始めた15時頃、リフレッシュルームに現れる。

七浪「う〜〜〜〜〜〜〜〜〜〜〜〜〜す」

取り巻き達「お勤めご苦労さまッス！！」

ここは獄中か？

獄中ヒエラルキー

脱獄モノ映画でみたことある。

長くいるやつほど偉いという獄中ヒエラルキーが、そこに存在していた。

僕は気づいてしまった。

予備校は入学ではない。投獄なのだ。

彼はもう７年も勤めている。懲役何年かしらないがきっともうシャバには戻れないだろう。

３浪や４浪はまだ社会復帰できる可能性が残っている。

僕みたいな１浪はお話にならない。まだ社会に片足を突っ込んでいるただの軽犯罪者だ。

もちろん、素行が悪ければ刑期はもっと伸びる可能性がある。ここではそういうルールなのだ。

彼は勝ち組だった

そんな彼は、リフレッシュルームでいつもポーカーをやっていた。

また彼は既婚だった。子供もいた。

そしてレクサスに乗ってた。

資金はどこから出てるんだと思ったが、親が金持ちらしい。

…酒、女、ギャンブル。

これらすべてが満ち満ちた医学部受験生が、確かに僕の身近に存在していた。

彼はいわゆる「勝ち組」だった。

七浪さんは消えた

七浪さんはセンター試験に近づくに連れ見かけなくなった。

きっと、レクサスを乗り回しているのだろう。

そして時が流れた

センター試験を命からがらこえて、二次試験で頭が真っ白になり、

３点の差で入学を逃した僕はめでたく２浪目に突入した。

授業が終わり、僕はリフレッシュルームにいった。

新入りはどんな面構えをしているのか見るために。

長い予備校生活で、僕も完全な「投獄ヒエラルキー」の一員になってしまっていたのだ。

フレッシュな面構えを見ながら、

「生きの良いのが入ってきた…俺達のシゴキにどれだけ耐えられるか見ものだな」

なんてうそぶいていると、全然フレッシュじゃないやつがいた。

そいつは、もちろん坊主だった。

命名変更

八浪さんだった。

……こうして彼の名前はincrementされていく。

今もどこかで、静かにincrementされているのかもしれない。

OSSから設計について学ぶ〜クラスの依存方向について〜

要約

僕が間違ってました。すみませんでした。

いきさつ

「Mapを使ったアプリケーションで、Mapの上にMarkerを立てたい」

という要件を満たすために、leafletというOSSを使うことにした。

• リポジトリ

github.com

• 公式サイト

leafletjs.com

インターフェース（ライブラリの使い方）を予想してみた

OSSを使うときに、

こんな感じのインターフェースじゃないかなって予想してみた。

僕「MapがMarkerを持ってるから、こうだろ」

僕「だから、インターフェースはこんな感じだろ」

const map: Map = new Map();
const marker: Marker = new Marker();
map.addMarker(marker);

僕「で、実装はこんな感じだろ」

class Map
{
    private markers: Array<Marker>;
    constructor() {
      this.markers = [];
    }
    addMarker(marker: Marker) {
        this.markers.push(marker)
    }
}

class Marker
{
    constructor() {     
    }
}

僕「うーむ。実に自然な発想だぞ。」

実際のインターフェース

const map: Map = new Map();
const marker: Marker = new Marker();
marker.addTo(map);

僕「え…？」

class Map
{
    constructor() {
    }
}

class Marker
{
    private map: Map
    constructor() {
    }
    addTo(map: Map) {
        this.map = map;
    }
}

僕「え…？え...？」

Mapクラス「もしかして」

Markerクラス「わたしたち」

僕「（依存方向が）いれかわってる〜〜〜〜！？」

他のOSSもみてみた

google map JavaScript API、mapboxGL, mapboxJSなどもみてみたが、

皆同じようなインターフェースだった。

つまり、

MapがMarkerに依存しているのではなく、

MarkerがMapに依存していた。

どうしてこんな設計なのか考えてみた

こっちのほうが変更に強いからだった。

変更に強いとは

例えば、MapにMarkerじゃなくてPopupも追加しようと思ったら、

僕が考えた実装方法だったらこうなる。

※　理解を簡単にするため、ソースコードは極限まで単純化しています

class Map
{
    private markers: Array<Marker>;
    private popups: Array<Popup>;
    constructor() {
        this.markers = [];
        this.popups = []; // 追加
    }
    addMarker(marker: Marker) {
        this.markers.push(marker)
    }
    // 追加
    addPopup(popup: Popup) {
       this.popups.push(popup)
    }
}

// 追加
class Popup {
    constructor() {        
    }
}

つまり、Popupの機能を追加しようとしたときに、

Mapの方も修正が必要になってくる。

さらにOverlay（地図上に何かを覆い隠す）を機能として追加してみると、、、

いい感じに「やな感じ」がしてきましたね笑

やな感じの正体

新たな機能を追加するたびに、Mapの方にも修正が発生してしまっているというのが、

やな感じの正体です。

これは「開放・閉鎖の法則」に違反しています。

開放/閉鎖原則に沿ったソフトウェアは、既存のソースコードを変更せずに機能修正や機能追加を行うことができる。 そのため、品質検査を再実行する必要がない。(wiki)

また、MapとMarkerだけ使いたいときもあるはずです。

そのときも、MapはPopupやOverlayのことまで知っている必要がある、というのもおかしな話ですね。

依存関係を逆転してみる

class Map
{
    constructor() {
    }
}

// 追加
class Popup
{
    private map: Map
    constructor() {
    }
    addTo(map: Map) {
        this.map = map;
    }
}

既存のコードに手を加えずに、機能を追加することができます。

すごい。すごいね。

どんなときに応用できるか

たとえば、ペイントのようなアプリをつくるとしましょう。

機能をボンボコ追加しても、修正をしても他のクラスには影響がでません。

素敵ですね。

まとめ

依存関係を逆転して考えると、

その後の機能追加時のコストに大きな差が出てきそうです。

そんなことを、今回知りました。

ただ、今回本当に単純化しているので、実際はもうちょっと複雑なはず。

注意したいです。

本当にオブジェクト指向を使う必要があるのか?

タイトルについて

すみません、煽りました。

いきさつ

オブジェクト指向で設計した時と、

オブジェクト指向を使わなかった時について、

「単純にコード量だけで」比較してみます。

その上で、オブジェクト指向の利点について再度考えてみます。

つくるもの

• 1秒間に1, 数字がカウントアップされる
• カウントアップされるたびに、2で割ったあまりと3で割ったあまりが表示される

コード

NOTオブジェクト指向でかく

const view1Input = document.getElementById("view1Input");
const view2Input = document.getElementById("view2Input");
const view3Input = document.getElementById("view3Input");

var count = 0;
const countUp = () => {
  count++;
  view1Input.value = count % 2;
  view2Input.value = count % 3;
  view3Input.value = count;
};
setInterval(countUp, 1000);

オブジェクト指向で設計して書く

• input要素の書き換え…Viewクラス
• カウンター値保持...Modelクラス
• 処理開始...Mainクラス

という簡単な責務で考えます。 そしてとりあえずobserverパターンで実装します。

すると。

class ViewModCounter {
  constructor(el, model) {
    this.inputEl = el;
    this.model = model;
    this.mod = 1;
  }
  setMod(num) {
    this.mod = num;
  }
  render() {
    this.inputEl.value = this.model.count % this.mod;
  }
}

class ViewCounter {
  constructor(el, model) {
    this.inputEl = el;
    // viewはmodelに依存している
    this.model = model;
  }
  render() {
    this.inputEl.value = this.model.count;
  }
}

class Model {
  constructor(count) {
    this.count = count;
    this.listeners = [];
  }
  setCount(count) {
    this.count = count;
    this.notify();
  }
  addListener(listener) {
    this.listeners.push(listener);
  }
  notify() {
    this.listeners.forEach((listener, index, listeners) => {
      listener.render();
    });
  }
}

class Main {
  constructor() {
    this.model = new Model(1);

    const view1Input = document.getElementById("view1Input");
    const view2Input = document.getElementById("view2Input");
    const view3Input = document.getElementById("view3Input");

    let view1 = new ViewModCounter(view1Input, this.model);
    view1.setMod(2);
    let view2 = new ViewModCounter(view2Input, this.model);
    view2.setMod(3);
    let viewCounter = new ViewCounter(view3Input, this.model);

    this.model.addListener(view1);
    this.model.addListener(view2);
    this.model.addListener(viewCounter);
  }
  run() {
    const model = this.model;
    let sec = 0;
    setInterval(() => {
      sec++;
      model.setCount(sec);
    }, 1000);
  }
}

const main = new Main();
main.run();

めっちゃ増えた

記述量だけみると、オブジェクト指向で設計するほうが大変です。

※ もちろん要件によっては記述量が逆転することもありえます

じゃあいつオブジェクト指向設計を使うのか

個人的には、

• 要件が複雑になった時
• 扱うモノが増えた時

この時、オブジェクト指向設計じゃないとかなり苦しむな、と感じています。 あとは保守のときですね。きちんと設計しないと一つの修正がいろんなところに飛んだりします。

注意

オブジェクト指向設計とはクラス化することではありません。

あくまでも、オブジェクト指向は手段で、

目的は「実装時にいかに楽に、そして保守時にいかに楽になれるか」というところにあります。

それを意識せずにただただクラス化するだけだと、

逆に辛くなることだって起こりえます。

（辛くなったことがある）

そこらへんの話がこの本にかいてあります（もっかい読みたい）

https://www.amazon.co.jp/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E8%A8%AD%E8%A8%88%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-Ruby%E3%81%A7%E3%82%8F%E3%81%8B%E3%82%8B-%E9%80%B2%E5%8C%96%E3%81%97%E3%81%A4%E3%81%A5%E3%81%91%E3%82%8B%E6%9F%94%E8%BB%9F%E3%81%AA%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E8%82%B2%E3%81%A6%E6%96%B9-Sandi-Metz/dp/477418361X

DDDのリポジトリについてちょっとしらべた

いきさつ

昔書いていたアプリケーションがあまりにあまりなので、

（モデルの責務がいたるところに染み出している）

DDD使って書き換えられないか検討するために勉強を始めた（１日目）

Repositoryからやっていきます

Repositoryについて

エンティティの永続化を担当する。

あと、エンティティの検索を担当する。

使われているところ＆メリット

主にServiceクラスで使用されている。

ただし、Serviceクラスが依存しているのはRepositoryクラスそのものではなく、

Repositoryのinterfaceに依存している。

<?php
class UserService {
    private $_userRepository;
    public function __constructor(IUserRepository $userRepository) {
        $this->_userRepository = $userRepository;
    }
} 

なので、もし別のリポジトリを使うことになってもServiceクラスを書き換える必要はない。

つまり、ORMを別のものに替えたり、もっと簡易なクエリビルダ的なものにしたりすることができる。

感想

そもそも今までActiveRecordパターンを使ったフレームワーク（Rails, FuelPHPのORM）での開発がほとんどで、

永続化したり検索したりする部分も"Model"でやっていたので新鮮。

ただ、まだちゃんとしたメリットまではわかっていない。

これから勉強していく。

JavaScriptのgetter, setterについて復習してみた

getter, setterとは

オブジェクトに値を代入したり、

参照したりする時に呼ばれる関数のこと。

書き方

set {プロパティ名}(value) {
  // 処理
}
get {プロパティ名}() {
  // 処理
}

のように書く

実例

var obj = {
    set value(val) {
        this._value = val + 1;
    },
    get value() {
        return 'getterからは' + this._value + 'を返す' 
    }
}
obj.value = 1; // setterが呼ばれる
console.log(obj.value); // getterからは2を返す　←getterが呼ばれている

用途

値をセットしたり、値を参照したりする時、

決まった処理をする際に便利。