【EffectiveJava[22]】

＜第 4 章 クラスとインタフェース＞
項目22： 非staticのメンバークラスよりstaticのメンバークラスを選ぶ

■著書からの要点抜粋
・エンクロージングインスタンスへアクセスする必要がないメンバークラスを
　宣言するのであれば、その宣言にstatic修飾子を常につけて、
　非staticのメンバークラスではなく、staticのメンバークラスにしてください。

■所感
ここはほとんど理解できず。。。orz

Effective Java プログラミング言語ガイド

【EffectiveJava[21]】

＜第 4 章 クラスとインタフェース＞
項目21： 戦略を表現するために関数オブジェクトを使用する

■著書からの要点抜粋
・javaの標準クラスではComparatorが該当する

■所感
戦略を定義するインタフェースと戦略を具象化するための具体的クラス。
Comparatorの仕組みって今考えてもよくできているけど、
それを自分自身が理解して、提供できるのはいつになるやら。
ここはもうちょっと理解を深めたい。

Effective Java プログラミング言語ガイド

父との思い出

今週のお題「父との思い出」

ふと思ったので書いてみることに。
父は子供のころ、本当にいろんなところ（でもわりと近場。県外でも隣ｗｗ）に
連れて行ってくれた。
でも、そのときのことはあまり覚えておらず。。

一番思い出深いのは昨年一緒に富士山に登りに行ったことですね。

といっても、この富士山登山がだいぶ冴えなくて。。
何が冴えないかというと、天候が悪くて頂上まで行けずじまい。。
加えて、自分はそもそも８．５合目くらいで高山病になりグロッキーｗｗ
天候が良くても上には行けない体調に。。
（いや実際しんどかった、、何度か吐いたし。。。。。。。）
ちなみに父親はぴんぴんしてました、５９歳なのに。

でも、そのときに父親がいろいろと心配してくれて、
自分に合せて行動したり、山小屋で毛布をかけてくれたりと
そういった親としての愛情を感じられたことが一番の思い出でした。

いつか再挑戦したいものですが、
まずは高山病克服が先ですね。
誰か高山病のよい克服法を教えてください。。。

【EffectiveJava[20]】

＜第 4 章 クラスとインタフェース＞
項目20： タグ付クラス（※）よりクラス階層を選ぶ

※タグ付クラス
は、インスタンスが２つ以上の特性を持っていて、
その特性を示すためのフィールド（タグフィールド）を持つクラス

■著書からの要点抜粋
・タグ付クラスは、冗長で、誤りやすく、非効率です。
・タグ付クラスは、クラス階層の面白味のない模倣に過ぎません。

■所感
タグ付クラスって若干追いつめられているときに作ったかもしれない。。
本人的には既存のクラスに＋＠の発想を加えて汎用的にした気になるかもしれないが、
実際はオブジェクト指向から逸脱してるにすぎないよのねぇ。
Javaならそこはサブクラス化すべきですよね。

Effective Java プログラミング言語ガイド

【EffectiveJava[19]】

＜第 4 章 クラスとインタフェース＞
項目19： 型を定義するためだけにインタフェースを使用する。

■著書からの要点抜粋
・定数インタフェースパターンは、インタフェースの下手な使い方です。
・定数ユーティリティクラスはインスタンス化を防ぐべき。
・インタフェースは型を定義するためだけに使用するべき。
　定数を提供するために使用すべきではない。

■所感
定数ユーティリティクラスなんかは現場で良く見るテクニック。本当に。
定数インタフェースってどうだろとか考えたりもしたけど、
インタフェースを境界として考えると、
役割を持ったクラスのほうが定数を持つクラスと考えたほうがしっくりくる。

Effective Java プログラミング言語ガイド

【EffectiveJava[18]】

＜第 4 章 クラスとインタフェース＞
項目18： 抽象クラスよりインタフェースを選ぶ

■著書からの要点抜粋
・既存のクラスを、新たなインタフェースを実装するように変更することは容易にできます。
・インタフェースは、階層を持たない型フレームワークを構築することを可能にしています。
・インタフェースを発展させるよりは、抽象クラスを発展させるほうが、はるかに容易です。
・一旦、インタフェースがリリースされて広く実装されたら、
　インタフェースを変更することはほとんど不可能です。

■所感
最近になってインタフェースの有用性がわかってきた。気がする。
はじめは抽象クラスのほうが概念的にわかりやすかったのだけど、
インタフェースがとても扱いやすい、わかりやすいものと知ると好ましい。
しかし、最後の一文はまさにその通りなので。。
publicなインタフェースを作成するには注意しなければならない。本当に。

Effective Java プログラミング言語ガイド

【EffectiveJava[17]】

＜第 4 章 クラスとインタフェース＞
項目17： 継承のために設計および文書化する、でなければ継承を禁止する

■著書からの要点抜粋
・クラスはオーバーライド可能なメソッドの自己利用（self-use）を文書化しなければなりません。
・クラスは、賢く選択されたprotectedのメソッドの形で、
　クラス内部の動作へのフックを提供しなければならないかもしれません。
・継承のためにクラスを設計することは、そのクラスにかなりの制限を課すことが明らかです。
・この問題に対する最善の解決策は、
　安全にサブクラス化されるための設計と
　文書化をされていないクラスでのサブクラス化の禁止です。

■所感
項目16から繋がるイメージ。
中で何をしているか、内部的に自己メソッドを呼び出しているか明記していなければ
継承するな。ラッパを使用しろ。というのが主旨だろうか。

Effective Java プログラミング言語ガイド