回答編集履歴
3
文章の修正
answer
CHANGED
|
@@ -51,6 +51,10 @@
|
|
|
51
51
|
|
|
52
52
|
よって、PersonクラスへDAO/DTOの考えを適用する必要はありません。
|
|
53
53
|
|
|
54
|
-
オブジェクト指向ではたくさんのデザインパターンや考え方がありますが、それ等を知るときは名前やどんなものか(WHAT)だけを知るのではなくなぜそれが生まれたのか(WHY)、その
|
|
54
|
+
オブジェクト指向ではたくさんのデザインパターンや考え方がありますが、それ等を知るときは名前やどんなものか(WHAT)だけを知るのではなく、なぜ・何のためにそれが生まれたのか(WHY)、その経緯を知りましょう。
|
|
55
55
|
|
|
56
|
+
経緯を知るとそのデザインパターンや考え方を適用したときにどんな目的を達成できるようになるのかが分かるようになります。
|
|
57
|
+
|
|
58
|
+
それも分かれば、現在抱えている自身の問題に対してそのデザインパターンや考え方を適用すべきか否かが判断できるようになります。
|
|
59
|
+
|
|
56
|
-
|
|
60
|
+
今回に関しても「Viewにデータを表示したい」という達成すべき目的、「データベースにアクセスしたい/アプリケーション間の通信に使いたい」という達成できる目的が合致していないことに気付くことができ、自己解決できるようになります。
|
2
文章の修正
answer
CHANGED
|
@@ -4,16 +4,19 @@
|
|
|
4
4
|
DTOのような特定のプロパティやメソッドに絞る意味・目的があればありです。
|
|
5
5
|
なければなしです。
|
|
6
6
|
|
|
7
|
+
プロパティだけを定義したクラスは、DTOや自動生成されたクラス以外で基本的に使われないと思います。
|
|
8
|
+
|
|
7
9
|
> プロパティのみ定義したクラスに分けることで、保守性を高める、など
|
|
8
10
|
そういったデザインパターンがあるのでしょうか
|
|
9
11
|
|
|
12
|
+
ないでしょう。むしろ、アンチパターンかと思います。
|
|
10
|
-
|
|
13
|
+
これはDDDという設計手法に存在する概念ですが、ドメインモデル貧血症という言葉があります。
|
|
11
14
|
|
|
12
15
|
[ドメインモデル貧血症](https://bliki-ja.github.io/AnemicDomainModel/)
|
|
13
16
|
[「ドメインモデル貧血症」を見かけたので、誤解しないように備忘録](https://hiroronn.hatenablog.jp/entry/20171026/1508975305)
|
|
14
17
|
|
|
15
|
-
しかし、私は
|
|
18
|
+
しかし、私はオブジェクト指向を意識したコーディングをするのであれば、たとえDDDという設計手法を用いらないとしてもドメインモデル貧血症にはならないようにすべきと思います。
|
|
16
|
-
プロパティのみ定義したクラスが無意味に、目的もなく存在すると読みにくい・理解しにくいコードが生まれるからです。
|
|
19
|
+
プロパティのみ定義したクラスが無意味に、目的もなく存在するとオブジェクト指向的に読みにくい・理解しにくいコードが生まれるからです。
|
|
17
20
|
|
|
18
21
|
オブジェクト指向ではとにかく命名が重要です。プロパティのみ定義したクラスには必要があればメソッドを定義すべきで、命名はそのアプリケーションの機能に関連するべきです。
|
|
19
22
|
|
1
誤字とプチ補足
answer
CHANGED
|
@@ -12,7 +12,9 @@
|
|
|
12
12
|
[ドメインモデル貧血症](https://bliki-ja.github.io/AnemicDomainModel/)
|
|
13
13
|
[「ドメインモデル貧血症」を見かけたので、誤解しないように備忘録](https://hiroronn.hatenablog.jp/entry/20171026/1508975305)
|
|
14
14
|
|
|
15
|
+
しかし、私はDDDでなくともこのパターンにはならないようにすべきと思います。
|
|
15
|
-
プロパティのみ定義したクラスが無意味に、目的もなく存在すると読みにくい・理解し
|
|
16
|
+
プロパティのみ定義したクラスが無意味に、目的もなく存在すると読みにくい・理解しにくいコードが生まれるからです。
|
|
17
|
+
|
|
16
18
|
オブジェクト指向ではとにかく命名が重要です。プロパティのみ定義したクラスには必要があればメソッドを定義すべきで、命名はそのアプリケーションの機能に関連するべきです。
|
|
17
19
|
|
|
18
20
|
> 2.GetFather()メソッドのように、自分のインスタンスとは直接関係の無いデータを提供するメソッドは、
|
|
@@ -24,7 +26,8 @@
|
|
|
24
26
|
1. GetFatherメソッドを定義することでそのアプリケーションの1機能を満たすこと
|
|
25
27
|
1. 複数人で開発している場合は、このメソッドの命名から中のソースコードを見ずとも戻り値を大体イメージしてもらえること
|
|
26
28
|
|
|
27
|
-
ちなみに、私ならGetFatherメソッドを使うのではなくChildrenプロパティ
|
|
29
|
+
ちなみに、私ならGetFatherメソッドを使うのではなくChildrenプロパティと同じようにプロパティで定義すると思います
|
|
30
|
+
※ところで、Personクラスには性別に相当する状態が定義されていませんが、どのようにしてFatherかMotherか判別するのでしょうか
|
|
28
31
|
|
|
29
32
|
> DTOやDAOというの考え方が在ると知ったのですが、
|
|
30
33
|
実際にそれをPersonクラスに適用するにはどうすればよいか分からず
|