オブジェクト指向で設計したクラスのプロパティとメソッドの分離について

Question

質問は以下の2つです。

1.以下のようなPersonクラスを、プロパティだけを定義したクラス、メソッドだけを定義したクラスに
分離することは、クラス設計の考え方としてアリでしょうか。ナシでしょうか。
※プロパティのみ定義したクラスに分けることで、保守性を高める、など
そういったデザインパターンがあるのでしょうか

2.GetFather()メソッドのように、自分のインスタンスとは直接関係の無いデータを提供するメソッドは、
Personクラスの中に定義してはダメでしょうか。(オブジェクト指向に違反しているのでしょうか)

記載内容に不足ありましたら、ご指摘いただけると幸いです。
何卒よろしくおねがいいたしますm(_ _)m

■補足情報
使用している技術は、.NET Frameworkと、WPFです。
MVVMで設計し、ViewのDatagridに、List<Person>を表示することを想定しています。
※Entity FrameworkやDataTableは使いません。

C#
1class Person{
2  // 名前
3  public string FirstName{get; set;}
4  // 苗字
5  public string LastName{get; set;}
6  // 子ども
7  public List<Person> Children{get; set;}
8
9  // コンストラクタ
10  public Person(){
11    this.FirstName = string.Empty;
12    this.LastName  = string.Empty;
13    this.Children  = new List<Person>();
14  }
15  // 氏名を返します
16  public string GetFullName(){
17    string FullName = this.FirstName + this.LastName;
18
19    return FullName;
20  }
21
22  // 引数のpeopleから父親を返します
23  // 見つからない場合はnullを返します
24  public Person GetFather(List<Person> people){
25    // Fatherをnullで初期化します
26    Person Father = null;
27
28    foreach(Person person in people){
29      // personの子どもを確認していきます。
30      foreach(Person child in person.Children){
31        // 子と自分の氏名が一致した場合は、子の親が自分の父親です      
32        if(child.GetFullName() == this.GetFullName()){
33          Father = person;
34          break;
35        }
36      }
37    }
38
39    return Father;
40  }
41}
42     
43

Accepted Answer

> 1.以下のようなPersonクラスを、プロパティだけを定義したクラス、メソッドだけを定義したクラスに
分離することは、クラス設計の考え方としてアリでしょうか。ナシでしょうか。

DTOのような特定のプロパティやメソッドに絞る意味・目的があればありです。
なければなしです。

プロパティだけを定義したクラスは、DTOや自動生成されたクラス以外で基本的に使われないと思います。

> プロパティのみ定義したクラスに分けることで、保守性を高める、など
そういったデザインパターンがあるのでしょうか

ないでしょう。むしろ、アンチパターンかと思います。
これはDDDという設計手法に存在する概念ですが、ドメインモデル貧血症という言葉があります。

[ドメインモデル貧血症](https://bliki-ja.github.io/AnemicDomainModel/)
[「ドメインモデル貧血症」を見かけたので、誤解しないように備忘録](https://hiroronn.hatenablog.jp/entry/20171026/1508975305)

しかし、私はオブジェクト指向を意識したコーディングをするのであれば、たとえDDDという設計手法を用いらないとしてもドメインモデル貧血症にはならないようにすべきと思います。
プロパティのみ定義したクラスが無意味に、目的もなく存在するとオブジェクト指向的に読みにくい・理解しにくいコードが生まれるからです。

オブジェクト指向ではとにかく命名が重要です。プロパティのみ定義したクラスには必要があればメソッドを定義すべきで、命名はそのアプリケーションの機能に関連するべきです。

> 2.GetFather()メソッドのように、自分のインスタンスとは直接関係の無いデータを提供するメソッドは、
Personクラスの中に定義してはダメでしょうか。(オブジェクト指向に違反しているのでしょうか)

thisが書いてあるので、関係がない訳ではないように見えます。
下記条件を満たしているのなら、定義しても良いかと思います。

1. GetFatherメソッドを定義することでそのアプリケーションの1機能を満たすこと
1. 複数人で開発している場合は、このメソッドの命名から中のソースコードを見ずとも戻り値を大体イメージしてもらえること

ちなみに、私ならGetFatherメソッドを使うのではなくChildrenプロパティと同じようにプロパティで定義すると思います
※ところで、Personクラスには性別に相当する状態が定義されていませんが、どのようにしてFatherかMotherか判別するのでしょうか

> DTOやDAOというの考え方が在ると知ったのですが、
実際にそれをPersonクラスに適用するにはどうすればよいか分からず

まず、comet7360さんの目的と選ぼうとしている手段に注目しましょう。

comet7360さんの目的はViewのDatagridに、List<Person>を表示することです。

それに対して、DAOを使うという手段は適切ではありません。
DAOはデータベースにアクセスするためのインターフェースを提供するためのオブジェクトです。
Viewでデータベースにアクセスしてはいけません。
ですから、Viewに表示することが目的であれば、むしろ**DAOを使ってはいけません**。

DTOを使うという手段も適切ではありません。
DTOとは、アプリケーション間で通信を行うのに用いるオブジェクトです。
Viewでアプリケーション間で通信を行ってはいけません。
ですから、Viewに表示することが目的であれば、むしろ**DTOを使ってはいけません**。

よって、PersonクラスへDAO/DTOの考えを適用する必要はありません。

オブジェクト指向ではたくさんのデザインパターンや考え方がありますが、それ等を知るときは名前やどんなものか(WHAT)だけを知るのではなく、なぜ・何のためにそれが生まれたのか(WHY)、その経緯を知りましょう。

経緯を知るとそのデザインパターンや考え方を適用したときにどんな目的を達成できるようになるのかが分かるようになります。

それも分かれば、現在抱えている自身の問題に対してそのデザインパターンや考え方を適用すべきか否かが判断できるようになります。

今回に関しても「Viewにデータを表示したい」という達成すべき目的、「データベースにアクセスしたい/アプリケーション間の通信に使いたい」という達成できる目的が合致していないことに気付くことができ、自己解決できるようになります。

関連した質問