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

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to Java class design

Similar to Java class design (20)

Recently uploaded

Recently uploaded (6)

Java class design