Java class design

Java再入門
市岡岳彦
2020/6/3

© 2020 SG Corporation 2
なんとなくで書いているコードをもうちょっとなんとかしたい。
Java再入門

Javaの古くからある機能を一度振り返っておこう。
Java再入門

サンプルコード
https://www.sgnet.co.jp/edu/2020050701_java.zip
Java再入門

◍ スコープ再考
◍ 抽象クラスと抽象メソッド
◍ 制御構造再考
◍ オブジェクトのライフサイクル
◍ 疎結合としてのサービス
目次

Javaのスコープはpublic,private,protectedだよね。
ん？なんか忘れてないか。
スコープ再考

 アクセス修飾子がないメソッド
スコープ再考
int foo() …

 なぜ、Javaのデフォルトスコープがパッケージなのか？
 パッケージを小さなライブラリと考える。
 パッケージ内のクラスが協働して小さな問題を解決する。
スコープ再考

 なぜ、Javaのデフォルトスコープがパッケージなのか？
 パッケージ外からは見えないけど、中からは見える。
 1クラス中のprivateメソッドが多くなってきたら、パッケージプ
ライベートなクラスを作るべきサイン。
 テスト容易性という副産物も。
スコープ再考

問題１
 ファクトリメソッドでオブジェクトを構築した後に値を変更した
いけど、外部からはアクセスさせたくない。
スコープ再考

問題１解答例の概要
従業員管理
 従業員はチームに所属する。
 従業員は複数チームに所属してもいい。
 チームは固定とする。
 従業員にどのチームに所属しているかを問い合わせるインター
フェースがある。
 ある従業員を後からチームに追加したいが、勝手に個々の従業員
オブジェクトにチームを追加されるのも困る。
スコープ再考

問題１解答例の概要
 クラス
 Book 管理簿
 Employee 従業員
 Team チーム
スコープ再考サンプルコード：1_scope

問題１解答編
 パブリック
 😄後からチームを追加することができる。
 😓管理簿内の従業員を外から変更できてしまう。
スコープ再考
public final class Employee {
private final EnumSet<Team> teams;
…
public boolean addTeam(Team team) {
return teams.add(team);
}
サンプルコード：1_scope/1_1

問題１解答編
 防御的コピー
 😄後からチームを追加しても、管理簿内の従業員は変わらない。
 😓逆に、管理簿に反映されていない！という誤解を生む。
→インターフェースがデザインの動機を表していない。
スコープ再考
public final class Book {
private final Map<Integer, Employee> employees =
…
public void add(Employee employee) {
employees.put(employee.getID(),
Employee.create(employee.getID(),
employee.getTeams()));

問題１解答編
 パッケージプライベート
 😄チーム追加は必ず管理簿を通して行うことが明確になる。
 😓パッケージプライベートにしている意図を分かっていないと、
改修時にパブリックにしがち。
スコープ再考
public final class Employee {
public boolean addTeam(Team team) {
…
public boolean addEmployeeTeam(int id, Team team) {
…
employee.addTeam(team);

 スコープでメソッドの意図を伝える one more step
 公開APIと拡張ポイントが一緒になっている…
スコープ再考
public abstract int foo();

 スコープでメソッドの意図を伝える one more step
 公開APIと拡張ポイントを明示する。
 オーバーライド側はこれ以上継承されたくなければ、finalにする。
スコープ再考
public final int foo() {
return fooImpl();
}
protected abstract int fooImpl();

 スコープでクラスの意図を伝える one more step
 クラス自体は公開したいが、継承はパッケージ内のみとしたい…
スコープ再考
public class Foo {
…
}

 スコープでクラスの意図を伝える one more step
 継承をパッケージ内のみに許可する。
 コンストラクタをパッケージプライベートにすることによって、
実質的finalにする。
スコープ再考
public class Foo {
Foo() {
…
}
…
}

 補足：コンストラクタチェーン
 コンストラクタが呼び出されたとき何が起きるか？
 コンストラクタ内で明示的にsuperを呼び出さない場合は、暗黙
的にスーパークラスの引数なしのコンストラクタが呼び出される。
 このとき、スーパークラスのコンストラクタにアクセス不可能だ
と、コンパイル時にエラーになる。
 明示的にsuperを呼び出した場合も同じ。
スコープ再考

まとめ
 パッケージを小さなライブラリと考える
 パッケージ内のクラスが協働して小さな問題を解決する
 修飾子でクラスデザインの意図を伝える
 メソッドのオーバーライド可能性に注意する
スコープ再考

 抽象クラスと抽象メソッドをどう使うかは悩みどころ。
 ふるまいを一般化する場合は、基本的にはインターフェースを選
択するけど、抽象クラスはどういうときに使うか。
abstract…?
抽象クラスと抽象メソッド

 protectedメソッドを呼ぶpublicメソッドでメソッド間の関係性を
保証する。
 例）java.util.AbstractList, java.util.AbstractSequentialList
 どのような実装であれ、リストとして期待される動作を保証する。

問題２
 多態性は持たせたいが、自由に継承はさせたくない。
 関係のあるメソッド間の契約を保証したい。

問題２解答例の概要
給与計算
 基本給と手当がある。
 給与は基本給＋手当とする。
 手当は単価×時間とするが、計算式が異なる可能性がある。
 手当の計算式が異なっても、給与＝基本給＋手当は保証する。
抽象クラスと抽象メソッドサンプルコード：2_abstract

問題２解答例の概要
 クラス
 Salary 給与
抽象クラスと抽象メソッドサンプルコード：2_abstract

問題２解答編
 パブリックコンストラクタ
 😄わかりやすい。
 😓勝手に継承される。
public class Salary {
public Salary(int base, int wage) {
サンプルコード：2_abstract/2_1

問題２解答編
 パッケージプライベートコンストラクタ
 😄継承をパッケージ内のみにとどめる。
 😓オーバーライドするポイントが分からない。
public class Salary {
public Salary(int base, int wage) {
…
public static Salary create(int base, int wage) {
return new Salary(base, wage);
}

問題２解答編
 abstractメソッド
 😄オーバーライドするポイントが分かる。
 😓意図したオーバーライドポイント以外もオーバーライドできて
しまう。
public abstract class Salary {
public abstract int getBase();
…
public abstract int getWage(int hour);
サンプルコード：2_abstract/なし

問題２解答編
 finalメソッド
 😄オーバーライド不可なポイントを守ることにより、メソッド間
の契約を保証できる。
public abstract class Salary {
public final int getBase() {
return getBaseImpl();
}
protected abstract int getBaseImpl();
…
public final int total(int hour) {
return getBase() + getWage(hour);
}

問題２いったんまとめ
 abstractメソッドは最小限にする。publicメソッドはabstractメ
ソッド同士の関係性を定義する。
 拡張性を公開しないのであれば、公開するべきではない。
 公開ポイントと拡張ポイントは区別する。

問題２解答編
 公開クラスと拡張クラスを分ける。
 😄拡張ポイントを分割・明示できる。
public final class Salary {
private final SalaryImpl salaryImpl;
Salary(int base, int wage, SalaryImpl salaryImpl) {
…
this.salaryImpl = salaryImpl;
static interface SalaryImpl {

問題２解答編
 拡張クラスを公開する。
 😄拡張ポイントのみを別個に公開できる。
public final class Salary {
private final SalaryImpl salaryImpl;
Salary(int base, int wage, SalaryImpl salaryImpl) {
…
this.salaryImpl = salaryImpl;
public interface SalaryImpl {

「疎結合としてのサービス」
で、もうちょっとやります。

まとめ
 抽象クラスは継承クラスを容易に作成するためのヘルパー
 公開メソッドは抽象メソッド同士の関係性を定義する
 公開メソッドはオーバーライド不可とする

Javaの制御構造はもちろんわかってるよ。
ifとかforとか…
制御構造再考

問題３
 単位処理数ごとのバッチ処理、コントロールブレイクをどう実現
するか。
 例）
 1000件ごと（バッチ）
 何かグループ化の条件が変わった場合（コントロールブレイク）
制御構造再考

問題３解答編
 そのままループ
 😄シンプルな解決策
 😓外側のループと内側のループでiを共有しているので分かりにく
い。
制御構造再考
for (int i = 0; i < employees.size(); i += 1000) {
for (int id : employees.subList(i,
Math.min(i + 1000, employees.size()))) {
for (int i = 0; i < employees.size();) {
for (int from = i; !isBreakIndex(employees, from, i); i++) {
サンプルコード：3_control/3_1

問題３解答編
 そのままループその２（バッチ）
 😄外側と内側のループを分けた。
制御構造再考
for (int i = 0, n = 0; i < employees.size(); i += n) {
n = batchLoopSub(employees, i);
…
private int batchLoopSub(List<Employee> employees,
int fromIndex) {
int count =
Math.min(fromIndex + 1000, employees.size());
for (int id : employees.subList(fromIndex, count)) {
…
return count - fromIndex;

問題３解答編
 そのままループその２（コントロールブレイク）
 😄外側と内側のループを分けた。
制御構造再考
for (int i = 0, n = 0; i < employees.size(); i += n) {
n = controlBreakLoopSub(employees, i);
…
private int controlBreakLoopSub(List<Employee> employees,
int fromIndex) {
int i = fromIndex;
for (; !isBreakIndex(employees, fromIndex, i); i++) {
…
return i - fromIndex;

問題３解答編
なんか似てないか、これ
制御構造再考

問題３解答編
 そのままループその２
 😕ここ以外同じだな…
制御構造再考
int count =
Math.min(fromIndex + 1000, employees.size());
for (int id : employees.subList(fromIndex, count)) {
int i = fromIndex;
for (; !isBreakIndex(employees, fromIndex, i); i++) {

問題３解答編
 そのままループその３
 バッチのループ継続条件をメソッド化
 😳同じ構造になった！
制御構造再考
int i = fromIndex;
for (; !isBatchIndex(employees, fromIndex, i); i++) {
private boolean isBatchIndex(List<Employee> employees,
int from, int index) {
return index == Math.min(from + 1000, employees.size());
}

問題３解答編
同じ構造のものはまとめよう
制御構造再考

問題３解答編
 ループ用クラス
制御構造再考
public final class Loop<E> {
@FunctionalInterface
public static interface ListBreak<E> {
boolean test(List<E> list, int from, int index);
}
private final ListBreak<E> listBreak;
public Loop(ListBreak<E> listBreak) {
this.listBreak = listBreak;
}

問題３解答編
 ループ用クラス続き
制御構造再考
…
public void loop(List<E> list) {
for (int i = 0, n = 0; i < list.size(); i += n) {
n = loopSub(list, i);
…
private int loopSub(List<E> list, int fromIndex) {
int i = fromIndex;
for (; !listBreak.test(list, fromIndex, i); i++) {
…
return i - fromIndex;
…

問題３解答編
 ループ用クラス呼び出し側
 😄バッチとコントロールブレイクでループを共通化できた。
 😓ループの中身である処理本体は同じことしかできない。
制御構造再考
Loop<Employee> batch =
new Loop<>(Main::batchBreakIndex);
batch.loop(employees);
Loop<Employee> control =
new Loop<>(Main::controlBreakIndex);
control.loop(employees);

問題３解答編
 ビューのリストに変形する
制御構造再考
public final class Loop<E> {
…
public List<List<E>> listView(List<E> list) {
List<List<E>> view = new ArrayList<>();
for (int i = 0, n = 0; i < list.size(); i += n) {
n = loopSub(list, i);
view.add(list.subList(i, i + n));
}
return view;
}

問題３解答編
 ビューのリストに変形する呼び出し側
 😄ループの処理本体を外に出せた。
 😄呼び出し側は一般的な拡張for文のみで対応できる。
 😓一時的ではあるが、リストの生成が必要になる。
制御構造再考
new Loop<>(Main::batchBreakIndex);
for (List<Employee> list : batch.listView(employees)) {
for (Employee e : list) {

問題３解答編
 ビューを返すイテレータを作る
制御構造再考
public final class Loop<E> implements Iterable<List<E>> {
…
private final List<E> list;
public Loop(List<E> list, ListBreak<E> listBreak) {
…
}
@Override public Iterator<List<E>> iterator() {
return new Iterator<List<E>>() {
…
}
}

問題３解答編
 ビューを返すイテレータを作る呼び出し側
 😄ブレイク条件のみを定義すれば、後はイテレータがやってくれ
る。
 😓初見ではわかりづらい。
制御構造再考
new Loop<>(employees, Main::batchBreakIndex);
for (List<Employee> list : batch) {
for (Employee e : list) {

問題３解答編
せっかくなので、ブレイク条件も一般化しよう
制御構造再考

問題３解答編 one more step
 バッチブレイク条件
制御構造再考
static <E> ListBreak<E> batchBreakIndex(int size) {
return (list, from, index) ->
index == Math.min(from + size, list.size());
}
new Loop<>(employees, batchBreakIndex(1000));

問題３解答編 one more step
 コントロールブレイク条件
制御構造再考
static <E> ListBreak<E> controlBreakIndex(
BiFunction<E, E, Boolean> test) {
return (list, from, index) -> {
if (index == list.size()) return true;
if (index == from) return false;
return !test.apply(list.get(index - 1), list.get(index));
};
}
Loop<Employee> control = new Loop<>(employees,
controlBreakIndex((a, b) -> Objects.equals(a, b)));

 問題がデータ構造であるのなら、データ構造をプログラミングす
る。
 ビューとコピーを区別する。コピーが必要であればコピーする。
 問題が制御構造であるのなら、制御構造をプログラミングする。
 コピーが必要なければ、ビューで対応する。
 使う側は動作をプログラミングしなくてもいい。
 宣言型プログラミング
制御構造再考

 とは言え、そのプロジェクトで頻出のイディオムであるという場
合に使うべき。
 素直にループを書いたほうがシンプルな解決策であることには変
わりはない。
 簡明さは失われてしまった。
制御構造再考

 補足：ラムダ式・メソッド参照
 Java8以降、メソッド参照とラムダ式が使えるようになった。
 オーバーライド用のメソッドを１つだけ持つインターフェースを
実装する手間を減らす。
 これにより、ラッパークラスを作らなくても、シグネチャが合致
するメソッドをそのまま渡すことができる。
制御構造再考
public interface Runnable {
void run();
}

 補足：ラムダ式・メソッド参照
制御構造再考
public static void main(String ... args) {
ExecutorService service = Executors.newSingleThreadExecutor();
// 無名クラス
service.execute(new Runnable() {
public void run() { print(); }
});
// メソッド参照
service.execute(Main::print);
// ラムダ式
service.execute(() -> print());
service.shutdown();
}
private static void print() {
System.out.println("run.");
}

まとめ
 問題がデータ構造であるのなら、データ構造をプログラミングす
る
 問題が制御構造であるのなら、制御構造をプログラミングする
 再利用性と簡明さはトレードオフ（の場合がある）
制御構造再考

オブジェクトにはcloseとかfreeとかないよね…
オブジェクトのライフサイクル

 Javaは明示的にメモリ領域を管理しない。
 オブジェクトのライフサイクルを気にしなくていいということで
はない。

問題４
 登録されたイベントリスナーをイベント発生時に呼び出す。
 リスナーが途中でいなくなっても、登録された側で保持している
と、GCで回収されない。

問題４解答例の概要
従業員管理
 管理簿に従業員の追加を依頼する。
 追加依頼は非同期に終了する。
 追加完了時にリスナーにコールバックがかかる。
オブジェクトのライフサイクルサンプルコード：4_lifecycle

問題４解答例の概要
 クラス
 Book 管理簿
オブジェクトのライフサイクルサンプルコード：4_lifecycle

問題４解答編
 リスナーの登録のみをする
public static interface Listener {
void action(Employee employee);
}
private final Map<Listener, Object> listeners =
new ConcurrentHashMap<>();
public void addListener(Listener listener) {
listeners.put(listener, new Object());
}
サンプルコード：4_lifecycle/4_1

問題４解答編
 リスナーの登録のみをする続き
public void addAsync(Employee employee) {
addService.execute(new Runnable() {
@Override public void run() {
add(employee);
actionAddEvent(employee);
}
});
}

問題４解答編
 リスナーの登録のみをする続き
 😓リスナーがいなくなっても、オブジェクトがGCで回収されない。
private void actionAddEvent(Employee employee) {
for (Listener l : listeners.keySet()) {
l.action(employee);
}
}

問題４解答編
 削除APIも公開する
 😄削除メソッドが呼ばれれば、GCで回収される。
 😓公開APIだと、削除メソッドが呼ばれる保証がない。
public void removeListener(Listener listener) {
listeners.remove(listener);
}

問題４解答編
 弱い参照
 マップ内のリスナーを弱い参照(WeakReference)で保持する。
private final Map<WeakReference<Listener>, Object>
listeners = new ConcurrentHashMap<>();
public void addListener(Listener listener) {
listeners.put(new WeakReference<>(listener),
new Object());
}

問題４解答編
 弱い参照続き
private void actionAddEvent(Employee employee) {
for (Iterator<WeakReference<Listener>> itr =
listeners.keySet().iterator(); itr.hasNext(); ) {
Listener l = itr.next().get();
if (l == null) {
itr.remove();
continue;
}
l.action(employee);
}
}

問題４解答編
 弱い参照
 😄通常の参照が0件になれば、GCで回収される。
 😄オブジェクトのライフサイクルを気にしていないことを明示で
きる。
 😓API仕様で、弱い参照をしていることを明示しておく必要があ
る。

 ブロードキャストする側はオブジェクトのライフサイクルを気に
しない。
 登録と登録解除を提供してもいいけど、ユーザーが登録解除を呼
ぶ保証はない！
 オブジェクトのライフサイクルを気にしていないということを明
示する。

 オブジェクト生成 one more step
 派生型が絡むと多少厄介…

 リストをコピーするメソッドのデザインとして、２通りが考えら
れる。
アウトパラメーターとする
戻り値とする
<E> void copyList(List<E> dest, List<E> src)
<E> List<E> copyList(List<E> src)

 アウトパラメーター
 呼び出し元がコピー先リストを生成する
 リストの具象クラスを呼び出し元が決めたい場合
 呼び出し先は実行時クラスが何かを気にしていない
 メソッドがアルゴリズムを表している場合はこのパターン
<E> void copyList(List<E> dest, List<E> src)

 戻り値
 呼び出し先がコピー先リストを生成する
 リストの具象クラスを呼び出し先が決めたい場合
 呼び出し元は実行時クラスが何かを気にしていない
 メソッドがファクトリーを表している場合はこのパターン
<E> List<E> copyList(List<E> src)

まとめ
 オブジェクトのライフサイクルを気にしなくていいということで
はない
 オブジェクトの生成消滅に対する責務をどこが担っているかを表
現する
 メソッドがアルゴリムなのか、ファクトリーなのかでも責務が変
わってくる

突然ですが、MySQLに接続しよう…
疎結合としてのサービス

 JDBCドライバ（というかコネクション）を取得する例
 😳“jdbc:mysql://〜”を渡すとMySQLのドライバが取得できる！
Connection conn = DriverManager.getConnection(
"jdbc:mysql://localhost:3306/testdb",
"user", "pass");

JDBCドライバのような機構はどのように実現されているのか？

問題５
 状態を保存したいが、保存先をプロパティファイル、XML、DB等
で切り替えたい。

問題５解答例の概要
従業員管理
 従業員管理簿を外部に保存する。
 外部保存の実装は継承で拡張できる。
疎結合としてのサービスサンプルコード：5_service

問題５解答例の概要
 クラス
 Book 管理簿
 BookHelper 管理簿と保存機能の橋渡し
 Persistance 保存機能
疎結合としてのサービスサンプルコード：5_service

問題５解答編
 ファクトリメソッドで文字列から作成
public abstract class Persistance {
public static Persistance create(String persist) throws
IOException {
switch (persist) {
case "xml":
return new XMLPersistance();
case "db":
return new DBPersistance();
default:
throw new IOException("No suitable provider found for ”
+ persist);
…
サンプルコード：5_service/5_1

問題５解答編
 ファクトリメソッドで文字列から作成
 😄難しい仕組みがいらない。
 😓コンパイル時に実装クラスが必要。

問題５解答編
 リフレクションで実現
 😄仕組みがまあまあ簡潔。
 😓インスタンス生成するクラスが公開サービスなのかが不明確。
 😓パッケージ名とサービス名が直接結びついてしまう。
public abstract class Persistance {
public static Persistance create(String persist) throws … {
return
Class.forName(persist).asSubclass(Persistance.class).
getDeclaredConstructor().newInstance();
}

問題５解答編
 サービスで実現
public interface PersistanceService {
boolean acceptName(String name);
void read(BookHelper book) throws IOException;
void write(BookHelper book) throws IOException;
}

問題５解答編
 サービスで実現続き
 😄仕組みがまあまあ簡潔。
 😓インスタンス生成するクラスが公開サービスなのかが不明確。
 😓パッケージ名とサービス名が直接結びついてしまう。
private final PersistanceService service;
public static Book createPersistance(String persist) throws
IOException {
PersistanceService found = findPersistanceService(persist);
if (found == null) {
throw new IOException("No suitable provider found for "
+ persist);
}
return new Book(found);
}

問題５解答編
private static PersistanceService findPersistanceService(
String persist) {
for (PersistanceService service :
ServiceLoader.load(PersistanceService.class)) {
if (service.acceptName(persist)) return service;
}
return null;
}

問題５解答編
 😄サービスとして公開していることを明示できる。
 😄パッケージ名とサービス名を間接的な結びつきにできる。
 😓若干、仕組みが面倒。
公開するサービスプロバイダー名を記載した
META-
INF/services/jp.co.sgnet.hrp.skillup202001.hr.spi.PersistanceService
を配置
jp.co.sgnet.hrp.skillup202001.hr.spi.XMLPersistanceServiceProvider

 APIとSPI
 API : Application Programming Interface
 SPI : Service Provider Interface
 APIとSPIのクラス階層は分けておく。
 API側の実装クラスが構築時にSPIのオブジェクトをもらって、中
にオブジェクトとして持つ形式。
 APIそのものが継承されることを前提としていることは少ないは
ず。

 補足： Java9のモジュール機構
 Java9以降、アクセス修飾子とは別にjarの外側に公開する／しな
いを制御することができるようになった。

 module-info.javaにクラスの公開／非公開を記載する。
module local.api {
exports local.api;
uses local.api.MyService;
}
公開側： local.apiパッケージ
module local.app {
requires local.api;
uses local.api.MyService;
}
利用側： local.appパッケージ
module local.provider {
requires local.api;
provides local.api.MyService with
local.provider.MyServiceProvider1;
}
実装側： local.providerパッケージ

private static PersistanceService findPersistanceService(
String persist) {
for (PersistanceService service :
ServiceLoader.load(PersistanceService.class)) {
if (service.acceptName(persist)) return service;
}
return null;
}

まとめ
 APIとSPIは分けておく
 APIは継承を前提としない
 SPIは継承を前提とする

◍ Effective Java 第３版
Joshua Bloch (著), 柴田芳樹 (翻訳)
丸善出版
◍ APIデザインの極意 Java/NetBeansアーキテクト探究ノート
Jaroslav Tulach (著), 柴田芳樹 (翻訳)
インプレス
参考文献

◍ SGソフトウェア開発ブログ
https://blog.sgnet.co.jp
◍ SlideShare公開資料
https://www.slideshare.net/t_ichioka_sg/
こちらもどうぞ

顧客と社員に信頼されるエス・ジー

Java class design

More Related Content

What's hot

Similar to Java class design

Java class design