Effective java 3版 読書会　５日目

実施日時：2019/1/9　22:00～23:00
対象範囲：項目19～項目20
参加者：yodai、yoridori、やぎた、kassyi
形式：オンライン(discord)
　　　課題本を事前に読み、実業務と照らし合わせて記述内容の
　　　議論をする。

項目19　継承のために雪渓及び文書化する、でなければ継承を禁止する
実装要件をきちんと文書化して残す必要がある。
そうでなければ、継承をするべきでない。
protectedの設計は、publicの設計と同じく注意して設計する必要が有る。
P97からのソースについて、サブクラスをインスタンス化すると、暗黙のスーパークラスのコンストラクタの呼び出しでスーパークラスのメソッドが呼ばれる。
そのため、最初のoverrideMeの結果がNullになる。
継承のための文書化や設計が出来ない場合、アッパークラスはヘルパークラスを使うようにする

項目20　抽象クラスよりもインターフェースを選ぶ
ミックスイン：１クラスに複数インターフェースを書けるので、強力な型の定義が出来る。
そのため、複数の振る舞いを持つ型を定義できる。

骨格実装：インターフェースと抽象クラスが混ざったものではなく、
　　　　　抽象クラスと考えた方が良い
　　　　　テンプレートメソッドパターンが骨格実装
テンプレートメソッドパターンを例にすると
　骨格実装：AbstractClass
　具象実装：ConcreteClass
テンプレートメソッドパターン：
https://qiita.com/shoheiyokoyama/items/c2ce16b4f492cd014d50

骨格実装クラスとは、抽象クラスにメソッドを置いてそれにインターフェースを付ける形になるのではないか。
P105最後、インターフェースの制約というのが良く分からない
サブクラスでは、インターフェースのメソッド実装を強制できない事なのか？
その場合、スーパークラスで抽象メソッドを定義させる必要があることか？
骨格実装クラスを使用する場合、テンプレートメソッドパターンで大丈夫な模様

骨格実装について、インターフェースの制約について
// 骨格
// defaultメソッドでもできるけど・・・
public interface InterfaceTest {
public void method();
public void doSomething();
}

public abstract class AbstractTest implements InterfaceTest {
// インターフェースに対する制約
// インターフェースだとインスタンス変数は持てない・・・とか？
int i = 0;
@Override
public void method() {
// ほねのロジック
this.i = 10;
doSomething();
}
}

// 具象クラス
public class Concrete extends AbstractTest {
@Override
public void doSomething() {
System.out.println(this.i);
}
}

public class TestMain {
public static void main(String[] args) {
InterfaceTest test = new Concrete();
test.method();
}
}
なのでしょうか・・・
インターフェースの制約は・・・

協力：Tech Baton
https://tech-baton.studio.design/