読者です 読者をやめる 読者になる 読者になる

アラタナエンジニアブログ

aratana Engineer's Blog

オブジェクト「思考」できてますか?

DDD(ドメイン駆動設計) オブジェクト指向

この記事はアラタナアドベントカレンダー4日目の記事です。


f:id:kimesawa:20161202085600j:plain

3日目は桑畑プロによる、マニアック言語Elmの記事でした。

今日のお話はメジャーなオブジェクト指向のお話です。

2016年現在では、javaやらrubyやらphpやら何かしらオブジェクト指向の機能を備えた言語を使って開発しているチームがほとんどでしょう。
今更オブジェクト指向?学ぶことなんてないよ。。。。なんて、思う方も多いと思います。

でも、本当にオブジェクト指向で設計ってできてますか?

2016年の年の瀬に、あらためてオブジェクト指向で開発するって本当はどういうことなのかを考えてみましょう。

まず、機能分割で考える

たとえば、
f:id:kimesawa:20161205011951p:plain

車を運転するという機能を考えるとこんな感じですよね。

実際、機能分割で設計を考える際も、恐らくユースケースや、ユーザーストーリーまたは、エクセルで機能一覧とか作ってそのような設計をするかと思いますし、それが自然でしょう。

詳細設計書などで機能詳細や処理の順番やフローを記載することも多いと思います。

オブジェクト指向で考えるということ

オブジェクト指向で考えると場合、機能分割で考えることとは全く別の視点・発想が必要です。

先ほどの車の運転で考えると、、、

f:id:kimesawa:20161205023159p:plain

つまり、
機能ではなく、部品役割を考えることが基本になります。

この発想で設計できるようになるには、ある種のブレイクスルーが必要になるかもしれません。

オブジェクト指向の機能を備えた言語で設計していても、機能分割な設計もできてしまいますし、恐らく多くのチームがいまだに、そのような設計をしているのではないでしょうか。
ブレイクスルーを経てオブジェクト指向設計ができれば、もっと保守性もあがり、変更しやすく、バグも出にくい設計ができるようになります。

オブジェクト指向だと何が嬉しいか

【役割まで考えられる】

例えば、会議で何か行うことが決定されたとき、普通なら誰が何をするまで決めませんか?
何をするかだけ、、、つまり機能を決めるだけでは先にすすむのは困難です。

誰が何をするまで決めて、物事が進みますし、整理がしやすいのです。

設計で考えれば前者が機能分割による設計、後者がオブジェクト指向設計です。

役割まで決めることで、設計がしやすく、整理が付きやすいものになります。

【小さく考えられる】

心理学用語で「マジックナンバー7」というものがあります。
人間が一度に覚えられるのは「7±2」個までという意味です。

1000行を超えるようなソースコードを読んで、最後まで通読したところで最初の方って忘れてしまいませんか?
適切に設計されたオブジェクト指向のクラスならそんなことは起こりません。
一つ一つのクラスは小さくなるはずなので、読みやすいコードになるはずです。

クラスが多くなってしまうのでは?という疑問も出てくると思いますが、そこはパッケージの出番です。

パッケージ内のクラス数を少なくすることで、整理することが可能です。

【処理の順番の定義を遅らせられる】

処理の順番というのは設計上とても重要なものです。

最初の車の運転する機能ですが、

2. ハンドブレーキを下げる
3. ギアをドライブにする

これって当たり前ですが、逆でもいいんです。

しかし、機能分割による設計ではその順番を決めなければ実装ができません。

オブジェクト指向による設計でも最終的には処理の順番を決める必要はありますが、それは最後の最後でいいのです。
決まっていなくても役割さえ決めれば実装を進めることができるからです。

この時間差はソフトウェア設計にとって、とても大きいものです。
実装が進むに連れてはっきりすることもありますし、重要な決定をできるだけ遅らせることもできます。


ぜひ、正しいオブジェクト「思考」を身につけて、オブジェクト指向の恩恵を受けてもらいたいと思います。
今後、どのように、オブジェクト「思考」を身につけていくかということも書いていきたいと思っています。


f:id:kimesawa:20161202085600j:plain

次回のアドベントカレンダーは人事のルーキー、伊知地パイセンです。弊社のインターンのお話です。