質問: この記事で、if条件を判定するメソッドをクラスのメソッドにするという改善方針が示されています。 https://devtab.jp/entry/internal/27 しかし記事にある「C.オブジェクト指向設計らしい改善」のようなクラスだと、+n日したり、日付を特定フォーマット文字列に変換したり、年部分のみ取得したりという、もともと日付に実装されている様々な機能を呼び出せなくなるのではないでしょうか? 対策としてすぐ思いつくのは以下手段ですが、もっと良い手があるのでしょうか? 1. this.dateをpublicなメンバとして公開する 2. LocalDateの持っているメソッドについて、利用したいもの全のラッパメソッドを書く 3. 移譲ではなくLocalDateを継承したクラスを定義する (こうすべきなら、記事はなぜ移譲を使った書き方になっている?)
回答: 言語が何か書いていないですが、たぶんJavaっぽいのでJavaなのでしょう。`LocalDate`は、たぶんJavaのjava.time.LocalDateの事なのだと思います。これらを前提として話します。 さて、Javaの`LocalDate`はfinalクラスです。そのため、継承したサブクラスを作ることができません。また、Javaの委譲は(lombokの@Delegateでも使わない限り)一つ一つメソッドを定義する必要があります。これは極めて面倒です。ということで、2.と3.は現実的ではありません。 最後の1.ですが、Javaにはプロパティという概念が無い(C#とかと比べると理解できます)ため、フィールドをそのまま公開することは悪手であると考えられています。これは将来の拡張や変更において、クラス内の実装を変えられなくなるからです。これは、よくある上書きされてしまうと言った問題とは**別の問題**です(LocalDateは不変オブジェクトであり、コードでは`final`になっているので、上書きや変更される心配はありません)。現実的なのはgetterのようなもの(`getDate()`というメソッド名である必要は全くありませんが、そう付けてはいけないというわけでもありません)をメソッドとして追加することぐらいです。ということで、1.もあまり良い方法とは言えません。 ということで、1.2.3.ともにあまり良くない手法か、現実的では無いと言えるかと思います。 記事の内容についてですが、私的な見解を述べておきます。 記事のコードでの条件文の中の論理式をメソッドにすること自体については悪いことでは無いと思います。ただ、何でもかんでもメソッドにしろというのは極論過ぎます。メソッドにするかどうかは、**それ自体がまとまりとして意味があるのか**が重要と考えています。 例えば、 ``` if (date.isNotSummer() && Locale.JAPAN.equals(locale)) ... ``` という感じだったらどうでしょうか?isJapaneseNotSummer(夏じゃない日本!)みたいなメソッドをまた作るのでしょうか?その場合のレシーバはどうなるのでしょうか?date?locale?となってしまい、ルールを守ることに私には意味が見いだせません。コードは極論ではかけません。バランスこそがいいコードだと思っています。 次に、果たしてLocalDateを委譲するServiceDateで実装するのが良いかどうかです。プログラミング全体を見ていないので確定したことは良いかもしれませんが、私はまずい雰囲気が漂っていると思います。実装すべきなのは、「この日は夏であると決めているクラス」にだと思います。SUMMER_STARTとSUMMER_ENDというのがでていますが、わたしはこの二つが定義されているクラスにstaticで実装するほうがいいと思っています。なぜなら、夏とは何かを決めているのはその場所であり、そこに「この日は夏なのか」と問い合わせればいいからです。責任は誰が取るかというのが設計において最も重要なことです。 記事は、完全に間違ったことを言っているわけでは無いのですが、例もよくありませんし、極論過ぎるところが見られます。JavaなのにJavaの標準のスタイル(Sunが書いたJavaのスタイルガイド)では無いと言うことも、なんか、Java知っているの?という雰囲気を醸し出しています。インデントが揃っていないところとかもありますし。 私の経験上、第三者がコメントでツッコミできない技術ブログの8割は内容が怪しいです。このような記事は、眉唾物として、あまり信用しないことをお勧めします。