【本】Effective Java 第3版
LessSweetend0124です。
4月より新しいプロジェクト先になったのですがあることで大変困っています。
項目18 継承よりもコンポジションを選ぶ
１．継承はコードを再利用するための強力な方法ですが、常に再利用するための最善の道具とは限りません。
２．実装が同じプログラマの管理下にある場合、パッケージ内の継承を使うのは安全です。
３．実装継承の場合、カプセル化を破ります。言い換えればサブクラスは適切に機能するために、スーパークラスの実装詳細に依存します。
これは、Effective Java 項目18を引用したものですが、まさにこれに直面しています。スーパークラスに定義されたメソッドを見ながら、サブクラス、つまり業務クラスを作成しなければならないのです。おまけにすべてのレイヤーが密接に依存しているので、パラレル継承に陥っています。（パラレル継承は、新装版 リファクタリングを参照）
そのため開始したのがスーパークラスの理解でした。
処理方式設計なるものがありますが、役割と実装方針が書かれておらずルールがさっぱりわからない状態です。
項目19 継承のために設計および文書化する、でなければ継承を禁止する。
Effective Javaでは下記のような文書を作成しろと書かれています。
１．オーバーライド可能なメソッドの自己利用を文書化する
２．個々のpublicやprotectedのメソッドに対して、各メソッドがどのオーバーライド可能なメソッドをどのような順番で呼び出し、各呼び出しが後の処理にどのように影響するかを文書化したものは示していなければならない。
現在、作成されている実装を見て、クラス図を作成しています。
まず、オーバーライド可能なメソッドは何か？
publicとprotectedの区別。
ただクラス図だけなので、どのような順番で呼び出し、各呼び出しが後の処理にどのように影響するかまでは文書化できていません。
ただクラス図にメモを書き足しこれが呼ばれ、オーバーライドしたメソッドが呼ばれると言ったことは書くようにしています。
まとめ
今回のプロジェクトはJavaではありませんが、継承のよくない点の見本を見ているようでつらいところです。
せめて、インタフェースの実装にして業務クラスのメソッドを統一させるような処理にしたらよかったのに。
ログ処理だけはもう少し調べたいと思います。
Effective Javaは今後読んでアウトプットしたい記事だったので先んじてこの２つを。