c - あるオブジェクトが別のオブジェクトを変更する必要がある場合の OOP のベストプラクティス

Question

(これは C に似た環境です) car と bodyShop の 2 つのインスタンスオブジェクトがあるとします。車には、カラー iVar と対応するアクセサーがあります。bodyShop には、車のオブジェクトを取り込んでその色を変更する「paintCar」という名前のメソッドがあります。

実装に関しては、実際に bodyShop で車のオブジェクトの色を変更できるようにするには、2 つの方法があります。

「&」演算子を使用して、車へのポインターを渡します。次に、bodyShop は、色を変更する必要がある何らかのメソッドを実行するように車に指示するか、車のアクセサーを直接使用することができます。
car オブジェクトを値で渡し、同じようなことを行って色を変更し、メソッドが新しい色の car オブジェクトを返すようにします。次に、元の車のオブジェクトを新しい車のオブジェクトに割り当てます。

オプション 1 の方が簡単に思えますが、OOP のベストプラクティスに沿っているかどうか疑問に思っています。一般的に「最大OOP」の場合、「&」演算子は良いですか、それとも悪いですか? または、このスーパー OOPer を作成するためのより良いオプションを完全に見逃しているのかもしれません。お知らせ下さい：）

score 5 · Accepted Answer

オプション 1 が推奨されます。

bodyShop は、色を変更する必要がある何らかのメソッドを実行するように車に指示するか、車のアクセサーを直接使用することができます。

さらに良いことに... IPaintable インターフェイスを作成します。Car に IPaintable を実装させます。BodyShop が Car ではなく IPaintable に依存するようにします。これの利点は次のとおりです。

BodyShop は IPaintable を実装するあらゆるもの (車、ボート、飛行機、スクーター) をペイントできるようになりました。
BodyShop は Car と密結合していません。
BodyShop はよりテストしやすいデザインになっています。

score 3 · Accepted Answer

bodyShop の責任は車のオブジェクトを変更することだと思いますので、#1 が正しい方法のように思えます。「&」演算子が必要な言語を使用したことがありません。通常、私の bodyShop オブジェクトは car.setColor(newColor) を呼び出します。この方法では、永続性の問題を含め、元の車の残りの属性について心配する必要はありません。そのままにしておくだけです。

score 2 · Accepted Answer

OOP のベストプラクティスに関心があるため、オプション 2 で得られるパフォーマンスヒットは無視する必要があります。注意すべき唯一のことは、いずれかのオプションを実行すると 2 つのクラス間の結合が不必要に増加すること、カプセル化に違反すること、ID が保持されることです。 .

これを考えると、オプション 2 はあまり望ましくありません。なぜなら、他のどのオブジェクトが元の車への参照を保持しているか、さらに悪いことに車を含んでいるかを判断できないからです。つまり、システム内の 2 つのオブジェクトが車の状態について異なる考えを持つ可能性があるため、同一性制約に違反します。システム全体の一貫性が失われるリスクがあります。

もちろん、特定の環境ではこれを避けることができますが、避けるのがベストプラクティスであることは間違いありません。

最後に、bodyShop オブジェクトには状態がありますか。行動とアイデンティティ？必要最小限しか説明していないことは承知していますが、bodyShop は実際にはオブジェクトではない可能性があります。

ファンクショナル v OO アプローチ

興味深いことに、オプション 2 は関数型プログラミング環境でのアプローチに近いものです。状態の変更は許可されていないため、色が変更された場合に新しい車を作成することが唯一のアプローチになります。それはあなたが示唆しているものではありませんが、近いです。

これは完全にやり過ぎのように聞こえるかもしれませんが、コードと並列処理の正確性を証明する上で、いくつかの興味深い意味があります。

score 1 · Accepted Answer

この「Cライクな環境」が何を意味するのかわかりません。Cでは、これが必要です：

int paintCar(const bodyShop_t *bs, car_t *car);

車が指す内容を変更するところ。C の大きな構造体の場合、値ではなく常にポインターを関数に渡す必要があります。したがって、解決策 1 を使用します (「&」が C 演算子を意味する場合)。

score 1 · Accepted Answer

オプション1が私にとって勝ちます。& 演算子は、多くの OO 言語 (Java、Python など) で暗黙的です。その言語では「値渡し」を頻繁に使用しません。プリミティブ型のみがその方法で渡されます。

オプション 2 には複数の問題があります。車のコレクションがあり、それを認識していない機能によって、塗装のために車が bodyShop に送られ、見返りに新しい車を受け取り、車のコレクションが更新されない可能性があります。見る？そして、よりイデオロギー的な観点から言えば、現実世界で変更するたびに新しいオブジェクトを作成する必要はありません。なぜ仮想オブジェクトでそうする必要があるのでしょうか? これは直感に反するだけなので、混乱を招きます。:-)

score 0 · Accepted Answer

それは、ボディショップの方法が失敗して、車が不確定な状態のままになる可能性があるかどうかにかかっています。その場合、車のコピー、または車の関連するすべての属性のコピーを操作することをお勧めします。次に、操作が成功した場合にのみ、それらの値を車にコピーします。そのため、ボディショップ方式で新しい車を古い車に割り当てることになります。これを正しく行うことは、C++ での例外の安全性のために必要であり、厄介なことになる可能性があります。

変更時に新しいオブジェクトを返すという他のパターンを使用することも可能であり、望ましい場合もあります。これは、元に戻す/やり直し、バックトラック検索を必要とする対話型システム、およびオブジェクトのシステムが時間の経過とともにどのように進化するかをモデル化することを含むあらゆるものに役立ちます。

score 0 · Accepted Answer

私も最初の 1 に同意します。これがベストプラクティスとは言えません。なぜなら、他の人の心にどのようなベストプラクティスがあるのかよくわからないからです。仕事のために働く。私はまた、hunspell win api や、私が使用しなければならなかった他の c-ish api で採用されたこのアプローチを見てきました。そうそう、私はスコットに同意します。

http://hunspell.sourceforge.net/

// 他の人のコードに興味がある場合に備えて

score 0 · Accepted Answer

他のオプションに加えて、オプション 1 により、paintCar メソッドは、車の色が正常に変更されたか、または問題があったかを示す完了コードを返すことができます。

c - あるオブジェクトが別のオブジェクトを変更する必要がある場合の OOP のベスト プラクティス

8 に答える 8

ファンクショナル v OO アプローチ

Related

Reference

c - あるオブジェクトが別のオブジェクトを変更する必要がある場合の OOP のベストプラクティス