回答編集履歴
3
不変オブジェクトらしい
answer
CHANGED
|
@@ -15,5 +15,7 @@
|
|
|
15
15
|
|
|
16
16
|
というところです。
|
|
17
17
|
|
|
18
|
-
ちなみに、本筋と関係ないので、書いていないのだと想像しますが、
|
|
18
|
+
<削除>ちなみに、本筋と関係ないので、書いていないのだと想像しますが、
|
|
19
|
-
コンストラクタで、dateを直接保持するのでなくcloneとか別のオブジェクトとして保持させるはず。
|
|
19
|
+
コンストラクタで、dateを直接保持するのでなくcloneとか別のオブジェクトとして保持させるはず。</削除>
|
|
20
|
+
|
|
21
|
+
クラスは不変でスレッドセーフなら問題ないです。
|
2
DateとLocalDateが、ごっちゃでした。
answer
CHANGED
|
@@ -1,13 +1,13 @@
|
|
|
1
1
|
> しかし記事にある「Ｃ．オブジェクト指向設計らしい改善」のようなクラスだと、+n日したり、日付を特定フォーマット文字列に変換したり、年部分のみ取得したりという、もともと日付に実装されている様々な機能を呼び出せなくなるのではないでしょうか？
|
|
2
2
|
|
|
3
3
|
はい。そのとおりです。
|
|
4
|
-
ただ、そもそも前提としてあるのが、ServiceDateクラスは
|
|
4
|
+
ただ、そもそも前提としてあるのが、ServiceDateクラスはLocalDateクラスじゃないということです。
|
|
5
|
-
日付の演算なんて本来不要なのです。
|
|
5
|
+
日付の演算なんて本来不要(として設計されている)なのです。
|
|
6
6
|
|
|
7
7
|
> LocalDateの持っているメソッドについて、利用したいもの
|
|
8
8
|
|
|
9
9
|
という発想自体が、設計として誤っているというか、必要なメソッド(夏季の判断)以外は公開する必要がないです。
|
|
10
|
-
極論いってしまえば、内部の日付は
|
|
10
|
+
極論いってしまえば、内部の日付はLocalDateでなく文字列でもいいです。
|
|
11
11
|
|
|
12
12
|
元記事にもありますが、一番重要なのは、
|
|
13
13
|
|
1
コンストラクタについて追記
answer
CHANGED
|
@@ -13,4 +13,7 @@
|
|
|
13
13
|
|
|
14
14
|
> データとロジックは同じ場所に置く。
|
|
15
15
|
|
|
16
|
-
というところです。
|
|
16
|
+
というところです。
|
|
17
|
+
|
|
18
|
+
ちなみに、本筋と関係ないので、書いていないのだと想像しますが、
|
|
19
|
+
コンストラクタで、dateを直接保持するのでなくcloneとか別のオブジェクトとして保持させるはず。
|