最近、コード レビューがありました。メソッドとの間で複数のタイプのデータを返す/渡すことができるように、クラスの 1 つが使用されました。クラスが持っていた唯一のメソッドはゲッター/セッターでした。チームのメンバーの 1 人 (私はその意見を尊重します) は、そのようなクラスを持つことは悪い習慣である (そしてあまり OOP ではない) と言いました。何故ですか ?
6 に答える
クラスは「データ構造」(つまり、機能を持たないデータの格納に焦点を当てる) または「機能指向」(つまり、最小限の状態を格納しながら特定のアクションを実行することに焦点を当てる) のいずれかであるという議論があります。その議論に従うなら (これは理にかなっていますが、常に簡単であるとは限りません)、必ずしも間違っているわけではありません。
実際、Bean とエンティティ Bean は本質的には、つまりゲッターとセッターを備えたデータ コンテナーであると主張する人もいるでしょう。
複数のパラメータを持つメソッドを避けるべきであり、代わりに getter と setter を持つ単一のオブジェクトとして渡す必要があると主張している特定の情報源 (たとえば、本「clean code」) を見てきました。これはまた、順序が問題にならない名前付きパラメーターの「smalltalk モデル」に近いものです。
ですから、適切に使用すれば、あなたのデザインは理にかなっていると思います。
ここには 2 つの別個の問題があることに注意してください。
「構造体のような」クラスは賢明ですか?
メソッドから複数の値を返すクラスを作成することは賢明ですか?
構造体のようなクラス
オブジェクト クラスは、ほとんどの場合、実世界のオブジェクトのクラスを表す必要があります。受動的で構造体のような Java Bean (すべてのゲッターとセッター)は、現実世界のものを表す場合があります。
ただし、現実世界のほとんどのものには、ルール、制約、動作、およびそれらが関与する基本的な動詞があります。構造体のようなクラスが現実世界のものとうまく一致することはめったになく、通常は技術的なものです。そのため、理想的な OO 設計とは言えません。
メソッドからの複数のリターン
Python にはこれがありますが、Java にはありません。複数の戻り値は、それ自体OO の質問ではありません。それは、言語の制限を乗り越える問題です。
複数の戻り値は、オブジェクトの状態が変化したことを意味する場合があります。おそらく、1 つのメソッドが状態を変更し、getter の一部のグループがこの状態の変更に起因する値を返します。
正直なところ、それは私にはうまく聞こえます。査読者はどのような代替案を提案しましたか?
OOP の「ベスト プラクティス」に従っていれば問題ありませんが、実用的になり、実際に仕事を成し遂げる必要があります。
このような値オブジェクトの使用 (OO は「構造体」を意味します) は、場合によっては完全に正当なアプローチです。
一般に、クラスを操作するために必要な知識をクラス自体に分離する必要があります。このようなクラスがある場合、複数の場所で使用されているため、それらの両方の場所で機能の一部を引き継ぐことができます。または、単一の場所にあり、内部クラスにする必要があります。複数の方法で使用されているが、まったく異なる方法で使用されている場合、共有機能がない場合、それを単一のクラスにすることは誤解を招き、共有機能が存在しないことを示します。
ただし、これらの一般的な規則が適用される場合と適用されない場合には、特定の理由があることが多いため、クラスが何を表現するかによって異なります。
彼は「あまりOOPではない」を悪い習慣と混同している可能性があると思います。彼は、それぞれが必要な 1 つの値を返すいくつかのメソッドを提供することを期待していたと思います (新しいクラスでそれらを使用する必要があるため、それほど悪くはありません)。
この場合、おそらく getter/setter を使用するべきではないことに注意してください。データを公開するだけです。いいえ、これは「あまりOOPではない」ですが、正しい方法です。
Josh Bloch がここでこれについての洞察を提供しているかもしれません。