📚

「Software Design 2021年3月号」を読んだ

2021/02/27に公開

Software Design 2021年3月号を読んだ

ということで、Software Design 2021年3月号|技術評論社の「【第1特集】Javaでもう一度学び直すオブジェクト指向プログラミング 第1章 オブジェクト指向への再入門」のサマリ(と少しの感想的なもの)。

大きなプログラム作るときは、何らかの手法に則ってプログラムを整理しないとわけがわからなくなる。

この辺が同じチームでうまいことできてなくてややこしいことになっていることもあるんじゃないかな。
手続き型プログラミングが混ざったりするのは、よくあることだけど。

オブジェクト指向プログラミングのクラスは、手続き型プログラミングのモジュールより再利用しやすい。

オブジェクト指向プログラミングは規模が大きくなることがあるから、なんとなく冗長に見えるのを嫌って、手続き型プログラミングっぽくなっちゃうのかな。

オブジェクト指向プログラミングは大きく複雑なものを分割して記述するときに向いている。

オブジェクト指向プログラミングではカプセル化のような制約を設けることで、クラスの責務を明確にする。

これもなかなかうまいことできてなくて、いろんな責務が混ざりがち。

ポリモーフィズムは似て非なるクラスを同一のものとして扱える性質。オブジェクト指向プログラミングではインターフェースを利用してポリモーフィズムを実現する。

インターフェースはクラスに実装するメソッドの名前、戻り値の型、引数の型を列挙するもので中身は実装しない。

ポリモーフィズムは継承でも実現できる。継承はあるクラスからそのクラスの一部を変えた別のクラスを作成できる性質。

インターフェースか継承か、それぞれどういうときに使うか、というのをチームで話し合っておくとよさそう。

フレームワークは自分が作ったプログラムを呼び出す位置づけ。フレームワークが提供する抽象クラスを継承したクラスやインターフェースを実装したクラスを作成することでフレームワークから呼び出せるようになる。

フレームワークは活かしたいな。依存しすぎて思考停止にならないようにしつつ…。


参考

Discussion