これは良い考えですか?insert
2 つのメソッド (およびupdate
) と 2 つの検証メソッド (validateInsert
および)を持つクラスを作成する代わりに、3validateUpdate
つのクラスを作成します。ProductDB
ProductInsert
ProductUpdate
これはより読みやすく、柔軟で、テストしやすいですか?
これは良い考えですか?insert
2 つのメソッド (およびupdate
) と 2 つの検証メソッド (validateInsert
および)を持つクラスを作成する代わりに、3validateUpdate
つのクラスを作成します。ProductDB
ProductInsert
ProductUpdate
これはより読みやすく、柔軟で、テストしやすいですか?
PaulG の答えは、私が支持していない従来のドメイン オブジェクト パターンに傾いています。個人的には、各プロセス (ProductInsert や ProductUpdate など) ごとに個別のクラスを用意することを好みます。これは、Deposit が BankAccount クラスのメソッドではなく、クラスのインスタンスである単純な銀行の例に見られるものと似ています。実行するルールやアクション、アクション自体の監査/永続化 (たとえば、挿入を追跡するための ProductInsert テーブル) など、より多くのものを含むビジネス プロセスについて考え始めると、ビジネス プロセスが第一級の市民であるべきであることがますます認識されます。それ自体で。
これは、言語に依存しない質問のように思えます。1 つのクラスを作成してそれを Product と呼び、クラス内に適切なメソッドを配置します。個別のオブジェクトを実際にインスタンス化するときに、どのような混乱が生じるかを考えてみてください (静的メソッドがない場合)。
また、具体的な Product クラスを使用すると、オブジェクト固有の情報を格納できます。
元:
Product myProduct = new Product()
myProduct.name = "cinnamon toast crunch"
myProduct.price = 3.99
私の意見では、個別のクラスを使用すると、コードが読みにくく、テストしにくくなります。