オブジェクト指向について　その２

投稿日：2016年6月1日更新日：2022年7月17日

前回のエントリーのように、データとロジックを一体で考えるのは、処理状の有効性のみならず、よりユーザー側に近い処理をかくということにもつながります。

日付の問題に関してもintやshortよりはLocalDateのほうが、LocalDateよりもDateofBirthのほうが人間が直接扱うには適しています。技術者の視点としてはDateofBirthのようにソフトウェアを利用する人たちの関心ごとを直接表現できるクラスを発見し、実装することなのです。

Contents

1 ドメインオブジェクト
2 パッケージ宣言
3 コレクション型の副作用
- 3.1 ファーストコレクションがない思想のプログラム
- 3.2 ファーストコレクションを反映したプログラム

ドメインオブジェクト

誕生日のようにソフトウェアを利用する人たちの関心ごとに直接対応するオブジェクトを「ドメインオブジェクト」と呼びます。

オブジェクト指向のプログラミングではこのドメインオブジェクトの発見と実装が主な課題です。ドメインオブジェクトは利用者の関心ごとに直接対応するため、クラス名なども利用者のことばで語られるようになります。

このため、機能の修正や拡張の対象となる箇所がクラス名から簡単にかつ正確に特定できます。また利用者の関心後の単位にデータとロジックを整理したドメインオブジェクトは変更の副作用を減らします。

パッケージ宣言

またクラス以外にも変更の対処個所を特定したり、影響範囲を狭くコントロールする仕組みがパッケージ宣言です。

コレクション型の副作用

コレクション型のデータはソフトウェア変更を難しくする原因になりがちです。

コレクションの操作はループ処理が多く、バグが混入しやすい、というデメリットがあります。

そのため、コレクションを扱うときにはコレクション型のインスタンス変数と、そのコレクション型を操作するロジックを一か所に集めた独自のクラスを作るのがオブジェクト指向らしいやり方です。

ファーストコレクションがない思想のプログラム

class Contact {
    List mailAddressList;
    List phoneList;
}

class Contact {

List mailAddressList;

List phoneList;

}

ファーストコレクションを反映したプログラム

class Contact {
    MailAddresses mailAddresses;
    Phones phones;
}
 
class MailAddresses {
    private List mailAddresses;
}
 
class Phones {
    private List phones;
}

class Contact {

MailAddresses mailAddresses;

Phones phones;

}

class MailAddresses {

private List mailAddresses;

}

class Phones {

private List phones;

}

こうすることで変更の影響範囲をせまく限定することができます。

オブジェクト指向について その２