it-swarm-ja.com

オブジェクトまたは値をパラメーターとして関数に渡す

私はJEE標準を使用しています。次のレイヤーがあります:JPA(Eclipse Link)、Data Access、Business Logic、およびJSF(Primefaces)。 PrimefacesはMVCデザインパターンを使用しているため、プレゼンテーション層にはManagedBeans(コントローラー)が含まれています。

ユーザーリクエストからオブジェクトを作成する場合、ManagedBeanでオブジェクトを作成し、それをオブジェクト全体としてロジックに渡すか、そのオブジェクトの属性をロジックに渡す必要があります。

public void businessLogicMethod(String clientAttributeA, int clientAttributeB...)

または

public void businessLogicMethod(Client client)

私は本当に決心することができません。機能的には、どちらのオプションも同じです...しかし、一方から他方へのソフトウェア品質の利点はありますか?コントローラまたはモデルでそれを構築するレイヤー設計の理由はありますか?他に理由はありますか?

上の図にある利点の1つは、配置図のサービスにサービスインターフェイスで宣言されたパラメーターがあるため、図にはさらに多くの情報があることです。

3
AFP_555

しかし、一方から他方へのソフトウェア品質の利点はありますか?

プログラミングは複雑であるため、私たちはプログラミングをより管理しやすく、保守しやすいものにするよう努めています。

そのためのツールの1つは、抽象化です。関連する詳細を抽象化し、利点をもたらす詳細の実装を非表示にできれば、考慮できるルールや問題が少なくなり、問題なく機能するためです。

いくつかの概念を取り、それらを1つの抽象化にまとめることができるときはいつでも、あなたは利点を得ています。

したがって、string、int、およびパッケージ化をクラスClientとして使用することは、クライアント(しゃれは意図されていません)、多くの場合、エラーの懸念や機会が少ない、より優れたソフトウェアを作成するのに役立つ抽象化です。

2つの別々のパラメーターに関する1つの問題は、誰かがclientA文字列をclientBintと混同する可能性があることです。一緒にバンドルされている、それは起こり得ない。

表示しているコードのもう1つの問題は、プリミティブデータ型が高値の型チェックとして提供されていないため、他の文字列値をclientAの文字列と混同する可能性があることです。発生しない新しい抽象化(新しいクラス、独自のタイプ)のように一緒にバンドルされます。

エラーが発生しにくい高品質の抽象化を提供するという概念は、保守可能なコードを作成する上で中心的な役割を果たします。

上の図にある利点の1つは、配置図のサービスにサービスインターフェイスで宣言されたパラメーターがあるため、図にはさらに多くの情報があることです。

これは実際には私たちが望んでいることに反しています。将来の変更が可能な限り最小のコード表面を混乱させるように、実装の詳細を非表示にします。

コントローラまたはモデルでそれを構築するレイヤー設計の理由はありますか?

さまざまな属性をすべて備えている最も早い実用的な瞬間に、抽象化(ここではClient)を構築する必要があります。その後、(単一の)抽象化がこれらの属性の最良のパッケージ化になります。

4
Erik Eidt